Teraz, gdy stwierdzono, że SSL 3 jest podatny na atak POODLE :
Które wersje SSL / TLS są używane przez System.Net.WebRequest podczas łączenia się z dowolnym adresem Uri https?
Używam WebRequest do łączenia się z kilkoma API stron trzecich. Jeden z nich powiedział teraz, że zablokuje każde żądanie korzystające z SSL 3. Ale WebRequest jest częścią struktury .Net core (używającej 4.5), więc nie jest oczywiste, jakiej wersji używa.
Odpowiedzi:
Podczas korzystania z System.Net.WebRequest aplikacja będzie negocjować z serwerem w celu określenia najwyższej wersji TLS obsługiwanej zarówno przez aplikację, jak i serwer, i będzie z niej korzystać. Więcej informacji o tym, jak to działa, można znaleźć tutaj:
http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake
Jeśli serwer nie obsługuje TLS, powróci do SSL, dlatego może potencjalnie wrócić do SSL3. Wszystkie wersje obsługiwane przez .NET 4.5 można zobaczyć tutaj:
http://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.110).aspx
Aby zapobiec podatności aplikacji na działanie POODLE, możesz wyłączyć SSL3 na komputerze, na którym działa aplikacja, postępując zgodnie z poniższym wyjaśnieniem:
/server/637207/on-iis-how-do-i-patch-the-ssl-3-0-poodle-vulnerability-cve-2014-3566
SecurityProtocolType.Tls(a zatem TLS 1.0) w .net framework 3.5 lub niższym
TLSbyło to coś, co faktycznie zostanie zaimplementowane na poziomie systemu operacyjnego / maszyny? Czy to nie jest miejsce, w którym występuje rzeczywisty ruch HTTP? Dlatego nie wydaje mi się, aby próba nakazania Twojemu kodowi używania określonego protokołu TLS, który jest naprawdę określony przez system operacyjny, nie ma sensu.
To jest ważne pytanie. Protokół SSL 3 (1996) został nieodwracalnie złamany przez atak Poodle opublikowany w 2014 roku. IETF opublikował informację „NIE WOLNO używać SSLv3” . Przeglądarki internetowe to rezygnują. Mozilla Firefox i Google Chrome już to zrobiły.
Dwa doskonałe narzędzia do sprawdzania obsługi protokołów w przeglądarkach to test klienta SSL Lab i https://www.howsmyssl.com/ . Ten ostatni nie wymaga Javascript, więc możesz go wypróbować z HttpClient .NET :
// set proxy if you need to
// WebRequest.DefaultWebProxy = new WebProxy("http://localhost:3128");
File.WriteAllText("howsmyssl-httpclient.html", new HttpClient().GetStringAsync("https://www.howsmyssl.com").Result);
// alternative using WebClient for older framework versions
// new WebClient().DownloadFile("https://www.howsmyssl.com/", "howsmyssl-webclient.html");
Rezultat jest potępiający:
Twój klient używa protokołu TLS 1.0, który jest bardzo stary, prawdopodobnie podatny na atak BEAST i nie ma najlepszych dostępnych zestawów szyfrów. Dodatki, takie jak AES-GCM i SHA256 zastępujące MD5-SHA-1, są niedostępne dla klienta TLS 1.0, a także dla wielu innych nowoczesnych zestawów szyfrów.
To dotyczy. Jest porównywalny do Internet Explorera 7 z 2006 roku.
Aby dokładnie wymienić protokoły obsługiwane przez klienta HTTP, możesz wypróbować poniższe serwery testowe dla poszczególnych wersji:
var test_servers = new Dictionary<string, string>();
test_servers["SSL 2"] = "https://www.ssllabs.com:10200";
test_servers["SSL 3"] = "https://www.ssllabs.com:10300";
test_servers["TLS 1.0"] = "https://www.ssllabs.com:10301";
test_servers["TLS 1.1"] = "https://www.ssllabs.com:10302";
test_servers["TLS 1.2"] = "https://www.ssllabs.com:10303";
var supported = new Func<string, bool>(url =>
{
try { return new HttpClient().GetAsync(url).Result.IsSuccessStatusCode; }
catch { return false; }
});
var supported_protocols = test_servers.Where(server => supported(server.Value));
Console.WriteLine(string.Join(", ", supported_protocols.Select(x => x.Key)));
Używam .NET Framework 4.6.2. Odkryłem, że HttpClient obsługuje tylko SSL 3 i TLS 1.0. To dotyczy. Jest to porównywalne z przeglądarką Internet Explorer 7 z 2006 roku.
Aktualizacja: Okazuje się, że HttpClient obsługuje TLS 1.1 i 1.2, ale musisz je włączyć ręcznie pod adresem System.Net.ServicePointManager.SecurityProtocol. Zobacz https://stackoverflow.com/a/26392698/284795
Nie wiem, dlaczego po wyjęciu z pudełka używa złych protokołów. Wydaje się, że to zły wybór konfiguracji, równoznaczny z poważnym błędem bezpieczeństwa (założę się, że wiele aplikacji nie zmienia ustawień domyślnych). Jak możemy to zgłosić?
Tam też umieściłem odpowiedź, ale artykuł @Colonel Panic dotyczy aktualizacji sugeruje wymuszenie TLS 1.2. W przyszłości, gdy protokół TLS 1.2 zostanie naruszony lub po prostu zastąpiony, utknięcie kodu w TLS 1.2 zostanie uznane za wadę. Negocjacja z TLS1.2 jest domyślnie włączona w .Net 4.6. Jeśli masz możliwość uaktualnienia źródła do .Net 4.6, bardzo polecam zmianę wymuszania TLS 1.2.
Jeśli wymuszasz TLS 1.2, zdecydowanie rozważ pozostawienie jakiegoś rodzaju menu nawigacyjnego, które usunie tę siłę, jeśli wykonasz aktualizację do struktury 4.6 lub nowszej.