Wyłączyć rezerwę SSL i używać tylko TLS dla połączeń wychodzących w .NET? (Łagodzenie skutków Pudla)

Próbuję złagodzić naszą lukę w ataku Poodle SSL 3.0 Fallback . Nasi administratorzy już zaczęli wyłączać SSL na rzecz TLS dla połączeń przychodzących do naszych serwerów. Poradziliśmy również naszemu zespołowi, aby wyłączył SSL w swoich przeglądarkach internetowych. Patrzę teraz na naszą bazę kodu .NET, która inicjuje połączenia HTTPS z różnymi usługami za pośrednictwem System.Net.HttpWebRequest . Uważam, że te połączenia mogą być podatne na atak MITM, jeśli pozwolą na powrót z TLS do SSL. Oto, co do tej pory ustaliłem. Czy ktoś mógłby to sprawdzić dwukrotnie, aby potwierdzić, że mam rację? Ta luka jest zupełnie nowa, więc nie widziałem jeszcze żadnych wskazówek od firmy Microsoft, jak ją złagodzić w .NET:

1. Dozwolone protokoły dla klasy System.Net.Security.SslStream, która stanowi podstawę bezpiecznej komunikacji w .NET, są ustawiane globalnie dla każdej domeny AppDomain za pośrednictwem System.Net.ServicePointManager.SecurityProtocol właściwości .

2. Domyślną wartością tej właściwości w .NET 4.5 jest Ssl3 | Tls(chociaż nie mogę znaleźć dokumentacji, która by to potwierdzała). SecurityProtocolType to wyliczenie z atrybutem Flags, więc jest to bitowe LUB z tych dwóch wartości. Możesz to sprawdzić w swoim środowisku za pomocą tego wiersza kodu:

   Console.WriteLine (System.Net.ServicePointManager.SecurityProtocol.ToString ());

3. Należy to zmienić na sprawiedliwe Tls, a możeTls12 przed zainicjowaniem jakichkolwiek połączeń w aplikacji:

   System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls;

4. Ważne: ponieważ właściwość obsługuje wiele flag bitowych, zakładam, że SslStream nie będzie automatycznie wracać do innych nieokreślonych protokołów podczas uzgadniania. W przeciwnym razie jaki byłby sens obsługi wielu flag?

Aktualizacja TLS 1.0 w porównaniu z 1.1 / 1.2:

Według eksperta Google ds. Bezpieczeństwa Adama Langleya, protokół TLS 1.0 okazał się później podatny na działanie POODLE, jeśli nie został prawidłowo zaimplementowany , dlatego należy rozważyć przejście wyłącznie na TLS 1.2.

Aktualizacja dla .NET Framework 4.7 i nowszych:

Jak wspomniał prof Von Lemongargle poniżej, począwszy od wersji 4.7 .NET Framework, nie ma potrzeby używania tego hacka, ponieważ domyślne ustawienie pozwoli systemowi operacyjnemu wybrać najbezpieczniejszą wersję protokołu TLS. Aby uzyskać więcej informacji, zobacz Najważniejsze wskazówki dotyczące zabezpieczeń warstwy transportu (TLS) w programie .NET Framework .

Robimy to samo. Aby obsługiwać tylko protokoły TLS 1.2 i żadnych protokołów SSL, możesz to zrobić:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

SecurityProtocolType.Tls to tylko protokół TLS 1.0, a nie wszystkie wersje TLS.

Na marginesie: jeśli chcesz sprawdzić, czy Twoja witryna nie zezwala na połączenia SSL, możesz to zrobić tutaj (nie sądzę, aby miało to wpływ na powyższe ustawienie, musieliśmy edytować rejestr, aby zmusić IIS do korzystania z TLS dla połączeń przychodzących): https://www.ssllabs.com/ssltest/index.html

Aby wyłączyć SSL 2.0 i 3.0 w IIS, zobacz tę stronę: https://www.sslshopper.com/article-how-to-disable-ssl-2.0-in-iis-7.html

Odpowiedź @Eddie Loeffen wydaje się być najpopularniejszą odpowiedzią na to pytanie, ale ma ona złe długoterminowe skutki. Jeśli przejrzysz stronę z dokumentacją dotyczącą System.Net.ServicePointManager.SecurityProtocol tutaj sekcja uwag sugeruje, że faza negocjacji powinna po prostu rozwiązać ten problem (a wymuszenie protokołu jest złą praktyką, ponieważ w przyszłości TLS 1.2 również zostanie naruszony). Jednak nie szukalibyśmy tej odpowiedzi, gdyby tak było.

Z badań wynika, że ​​protokół negocjacyjny ALPN jest wymagany, aby dostać się do TLS1.2 w fazie negocjacji. Wzięliśmy to za punkt wyjścia i wypróbowaliśmy nowsze wersje frameworka .Net, aby zobaczyć, gdzie zaczyna się wsparcie. Okazało się, że .Net 4.5.2 nie obsługuje negocjacji z TLS 1.2, ale .Net 4.6 obsługuje.

Tak więc, mimo że wymuszenie TLS1.2 wykona zadanie teraz, zalecam zamiast tego aktualizację do .Net 4.6. Ponieważ jest to kwestia PCI DSS w czerwcu 2016 r., Okno jest krótkie, ale nowa struktura jest lepszą odpowiedzią.

UPDATE: Pracując na podstawie komentarzy, zbudowałem to:

ServicePointManager.SecurityProtocol = 0;    
foreach (SecurityProtocolType protocol in SecurityProtocolType.GetValues(typeof(SecurityProtocolType)))
    {
        switch (protocol)
        {
            case SecurityProtocolType.Ssl3:
            case SecurityProtocolType.Tls:
            case SecurityProtocolType.Tls11:
                break;
            default:
                ServicePointManager.SecurityProtocol |= protocol;
            break;
        }
    }

Aby zweryfikować koncepcję, zdecydowałem się połączyć SSL3 i TLS1.2 i uruchomiłem kod skierowany na serwer, który obsługuje tylko TLS 1.0 i TLS 1.2 (1.1 jest wyłączony). Z protokołami or'd wydaje się, że łączy się dobrze. Jeśli zmienię na SSL3 i TLS 1.1, połączenie nie powiodło się. Moja walidacja używa HttpWebRequest z System.Net i po prostu wywołuje GetResponse (). Na przykład próbowałem tego i nie udało mi się:

        HttpWebRequest request = WebRequest.Create("https://www.contoso.com/my/web/resource") as HttpWebRequest;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls11;
        request.GetResponse();

podczas gdy to działało:

        HttpWebRequest request = WebRequest.Create("https://www.contoso.com/my/web/resource") as HttpWebRequest;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12;
        request.GetResponse();

Ma to przewagę nad wymuszeniem TLS 1.2, ponieważ jeśli struktura .Net zostanie zaktualizowana, tak aby w Enum było więcej wpisów, będą one obsługiwane przez kod bez zmian. Ma tę wadę w stosunku do samego używania .Net 4.6, ponieważ 4.6 używa ALPN i powinien obsługiwać nowe protokoły, jeśli nie określono żadnych ograniczeń.

Edycja 29.04.2019 - Microsoft opublikował ten artykuł w październiku ubiegłego roku. Zawiera całkiem dobre streszczenie ich zaleceń, jak należy to zrobić w różnych wersjach frameworka .net.

@watson

W formularzach okien jest dostępny, na górze klasy należy umieścić

  static void Main(string[] args)
    {
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
       //other stuff here
    }

ponieważ okna są jednowątkowe, to wszystko, czego potrzebujesz, w przypadku, gdy jest to usługa, musisz umieścić ją tuż nad wywołaniem usługi (ponieważ nie wiadomo, w którym wątku będziesz).

using System.Security.Principal 

jest również potrzebne.

Jeśli jesteś ciekawy, które protokoły obsługuje .NET, możesz wypróbować HttpClient na https://www.howsmyssl.com/

// 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.

Jak wyjaśnia Eddie powyżej, możesz ręcznie włączyć lepsze protokoły:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11; 

Nie wiem, dlaczego po wyjęciu z pudełka używa złych protokołów. Wydaje się, że to kiepski 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ć?

Musiałem rzucić liczbę całkowitą, aby obejść fakt, że nadal używam .NET 4.0

System.Net.ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
/* Note the property type  
   [System.Flags]
   public enum SecurityProtocolType
   {
     Ssl3 = 48,
     Tls = 192,
     Tls11 = 768,
     Tls12 = 3072,
   } 
*/

Odkryłem, że najprostszym rozwiązaniem jest dodanie dwóch wpisów rejestru w następujący sposób (uruchom to w wierszu polecenia z uprawnieniami administratora):

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:32

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:64

Wydaje się, że wpisy te wpływają na sposób, w jaki środowisko .NET CLR wybiera protokół podczas nawiązywania bezpiecznego połączenia jako klient.

Więcej informacji na temat tego wpisu rejestru można znaleźć tutaj:

https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/2960358#suggested-actions

Jest to nie tylko prostsze, ale zakładając, że działa w Twoim przypadku, znacznie bardziej niezawodne niż rozwiązanie oparte na kodzie, które wymaga od programistów śledzenia protokołu i rozwoju oraz aktualizowania całego odpowiedniego kodu. Miejmy nadzieję, że podobne zmiany w środowisku można wprowadzić dla protokołu TLS 1.3 i nowszych, o ile .NET pozostanie na tyle głupi, aby nie wybierać automatycznie najwyższego dostępnego protokołu.

UWAGA : Mimo że, zgodnie z powyższym artykułem, ma to tylko wyłączyć RC4 i nie można by pomyśleć, że zmieni to, czy klient .NET może używać TLS1.2 +, czy nie, z jakiegoś powodu ma to efekt.

UWAGA : Jak zauważył @Jordan Rieger w komentarzach, nie jest to rozwiązanie dla POODLE, ponieważ nie wyłącza starszych protokołów a - pozwala jedynie klientowi pracować z nowszymi protokołami, np. Gdy załatany serwer wyłączył starszy protokoły. Jednak w przypadku ataku MITM, oczywiście zagrożony serwer zaoferuje klientowi starszy protokół, z którego klient będzie wtedy chętnie korzystał.

TODO : Spróbuj wyłączyć używanie TLS1.0 i TLS1.1 po stronie klienta z tymi wpisami rejestru, jednak nie wiem, czy biblioteki klienta http .NET przestrzegają tych ustawień, czy nie:

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-10

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-11