Jaki jest domyślny protokół bezpieczeństwa do komunikacji z serwerami, które obsługują do TLS 1.2? Będzie .NETdomyślnie wybierać najwyższej protokół zabezpieczeń obsługiwane po stronie serwera, czy muszę jawnie dodać poniższy wiersz kodu:

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

Czy istnieje sposób na zmianę tego ustawienia domyślnego oprócz zmiany kodu?

Wreszcie, obsługuje .NET 4.0tylko do TLS 1.0? tj. muszę zaktualizować projekty klienta do 4.5, aby je obsługiwać TLS 1.2.

Moją motywacją jest usunięcie obsługi SSLv3po stronie klienta, nawet jeśli serwer ją obsługuje (mam już skrypt PowerShell, aby wyłączyć to w rejestrze komputera) i obsługę najwyższego protokołu TLS obsługiwanego przez serwer.

Aktualizacja: Patrząc na ServicePointManagerklasę .NET 4.0nie widzę wyliczonych wartości dla TLS 1.0i 1.1. W obu .NET 4.0/4.5przypadkach wartością domyślną jest SecurityProtocolType.Tls|SecurityProtocolType.Ssl3. Mamy nadzieję, że to ustawienie domyślne nie ulegnie awarii przez wyłączenie SSLv3w rejestrze.

Zdecydowałem jednak, że muszę zaktualizować wszystkie aplikacje .NET 4.5i i tak jawnie dodać je SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;do kodu ładowania wszystkich aplikacji.

Spowoduje to wysłanie żądań wychodzących do różnych aplikacji i usług, aby nie obniżać poziomu SSLv3i należy wybrać najwyższy poziom TLS.

Czy to podejście wydaje się rozsądne czy nadmierne? Mam wiele aplikacji do zaktualizowania i chcę je w przyszłości sprawdzić, ponieważ słyszę, że TLS 1.0niektórzy dostawcy mogą nawet w najbliższej przyszłości stracić ważność.

Czy jako klient wysyłający żądania wychodzące do interfejsów API wyłączenie protokołu SSL3 w rejestrze ma nawet wpływ na środowisko .NET? Domyślnie TLS 1.1 i 1.2 nie są włączone, czy musimy włączyć to przez rejestr? RE http://support.microsoft.com/kb/245030 .

Po krótkiej analizie uważam, że ustawienia rejestru nie będą miały wpływu, ponieważ dotyczą IIS (podklucz serwera) i przeglądarek (podklucz klienta).

Przepraszamy, ten post zamienił się w wiele pytań, a następnie w odpowiedzi „być może”.

Niektórzy pozostawiający komentarze zauważyli, że ustawienie System.Net.ServicePointManager.SecurityProtocolokreślonych wartości oznacza, że ​​aplikacja nie będzie mogła korzystać z przyszłych wersji TLS, które mogą stać się wartościami domyślnymi w przyszłych aktualizacjach platformy .NET. Zamiast określać stałą listę protokołów, możesz zamiast tego włączać lub wyłączać protokoły, które znasz i na których Ci zależy, pozostawiając inne takie, jakie są.

Aby włączyć TLS 1.1 i 1.2 bez wpływu na inne protokoły:

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

Zauważ, że |=możesz włączyć te flagi bez wyłączania innych.

Aby wyłączyć SSL3 bez wpływu na inne protokoły:

System.Net.ServicePointManager.SecurityProtocol &= ~SecurityProtocolType.Ssl3;

Domyślnie System.Net.ServicePointManager.SecurityProtocolw obu .NET 4.0/4.5jest SecurityProtocolType.Tls|SecurityProtocolType.Ssl3.

.NET 4.0obsługuje do TLS 1.0chwili .NET 4.5obsługuje doTLS 1.2

Jednak kierowanie na aplikacje .NET 4.0może nadal obsługiwać, nawet TLS 1.2jeśli .NET 4.5jest zainstalowane w tym samym środowisku. .NET 4.5instaluje się na górze .NET 4.0, zastępując System.dll.

Zweryfikowałem to, obserwując poprawny protokół bezpieczeństwa ustawiony w ruchu fiddler4zi ręcznie ustawiając wyliczone wartości w .NET 4.0projekcie:

ServicePointManager.SecurityProtocol = (SecurityProtocolType)192 |
(SecurityProtocolType)768 | (SecurityProtocolType)3072;

Odniesienie:

namespace System.Net
{
    [System.Flags]
    public enum SecurityProtocolType
    {
       Ssl3 = 48,
       Tls = 192,
       Tls11 = 768,
       Tls12 = 3072,
    }
}

Jeśli spróbujesz włamać się do środowiska z .NET 4.0zainstalowanym TYLKO , otrzymasz wyjątek:

Nieobsługiwany wyjątek: System.NotSupportedException: Żądany protokół zabezpieczeń nie jest obsługiwany. w System.Net.ServicePointManager.set_SecurityProtocol (SecurityProtocolType v alue)

Jednak nie poleciłbym tego „hacka”, ponieważ przyszła łatka itp. Może go złamać. *

Dlatego zdecydowałem, że najlepszą drogą do usunięcia wsparcia SSLv3jest:

1. Uaktualnij wszystkie aplikacje do .NET 4.5

2. Dodaj następujący kod do kodu boostrapping, aby zastąpić domyślny i przyszły dowód:

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

* Ktoś mnie poprawi, jeśli ten hack jest nieprawidłowy, ale wstępne testy widzę, że działa

Możesz zastąpić domyślne zachowanie w następującym rejestrze:

Key  : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 
Value: SchUseStrongCrypto
Type: REG_DWORD
Data : 1

i

Key  : HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319
Value: SchUseStrongCrypto
Type: REG_DWORD
Data : 1

Aby uzyskać szczegółowe informacje, zobacz wdrożenieServicePointManager .

Utwórz plik tekstowy z .regrozszerzeniem i następującą zawartością:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Lub pobierz go z następującego źródła:

https://tls1test.salesforce.com/s/NET40-Enable-TLS-1_2.reg

Kliknij dwukrotnie, aby zainstalować ...

Przekonałem się, że kiedy podam tylko TLS 1.2, nadal będzie negocjować do 1.1. System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Podałem to w metodzie uruchamiania Global.asax dla mojej aplikacji sieci web .net 4.5.

Poniższy kod będzie:

• drukuj włączone protokoły
• wydrukuj dostępne protokoły
• włącz TLS1.2, jeśli platforma go obsługuje i jeśli nie jest włączony, na początek
• wyłącz SSL3, jeśli jest włączony
• wydrukuj wynik końcowy

Stałe:

• 48 to SSL3
• 192 to TLS1
• 768 to TLS1.1
• 3072 to TLS1.2

Nie wpłynie to na inne protokoły. To sprawia, że ​​jest to zgodne z przyszłymi protokołami (Tls 1.3 itp.).

Kod

// print initial status
    Console.WriteLine("Runtime: " + System.Diagnostics.FileVersionInfo.GetVersionInfo(typeof(int).Assembly.Location).ProductVersion);
    Console.WriteLine("Enabled protocols:   " + ServicePointManager.SecurityProtocol);
    Console.WriteLine("Available protocols: ");
    Boolean platformSupportsTls12 = false;
    foreach (SecurityProtocolType protocol in Enum.GetValues(typeof(SecurityProtocolType))) {                
        Console.WriteLine(protocol.GetHashCode());
        if (protocol.GetHashCode() == 3072){
            platformSupportsTls12 = true;
        }
    }
    Console.WriteLine("Is Tls12 enabled: " + ServicePointManager.SecurityProtocol.HasFlag((SecurityProtocolType)3072));    


// enable Tls12, if possible
    if (!ServicePointManager.SecurityProtocol.HasFlag((SecurityProtocolType)3072)){
        if (platformSupportsTls12){
            Console.WriteLine("Platform supports Tls12, but it is not enabled. Enabling it now.");
            ServicePointManager.SecurityProtocol |= (SecurityProtocolType)3072;
        } else {
            Console.WriteLine("Platform does not supports Tls12.");
        }
    }

// disable ssl3
   if (ServicePointManager.SecurityProtocol.HasFlag(SecurityProtocolType.Ssl3)) { 
      Console.WriteLine("Ssl3SSL3 is enabled. Disabling it now.");
      // disable SSL3. Has no negative impact if SSL3 is already disabled. The enclosing "if" if just for illustration.
      System.Net.ServicePointManager.SecurityProtocol &= ~SecurityProtocolType.Ssl3;                      
   }
    Console.WriteLine("Enabled protocols:   " + ServicePointManager.SecurityProtocol);

Wynik

Runtime: 4.7.2114.0
Enabled protocols:   Ssl3, Tls
Available protocols: 
0
48
192
768
3072
Is Tls12 enabled: False
Platform supports Tls12, but it is not enabled. Enabling it now.
Ssl3 is enabled. Disabling it now.
Enabled protocols:   Tls, Tls12

Mam problem, gdy mój klient zaktualizował TLS z 1.0 do 1.2. Moja aplikacja korzysta z .NET Framework 3.5 i działa na serwerze. Naprawiłem to w ten sposób:

1. Napraw program

Przed wywołaniem HttpWebRequest.GetResponse () dodaj następujące polecenie:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolTypeExtensions.Tls11 | SecurityProtocolTypeExtensions.Tls12;

Rozszerza 2 biblioteki DLL, dodając 2 nowe klasy: System.Net i System.Security.Authentication

    namespace System.Net
    {
        using System.Security.Authentication;
        public static class SecurityProtocolTypeExtensions
        {
            public const SecurityProtocolType Tls12 = (SecurityProtocolType)SslProtocolsExtensions.Tls12;
            public const SecurityProtocolType Tls11 = (SecurityProtocolType)SslProtocolsExtensions.Tls11;
            public const SecurityProtocolType SystemDefault = (SecurityProtocolType)0;
        }
    } 

    namespace System.Security.Authentication
    {
        public static class SslProtocolsExtensions
        {
            public const SslProtocols Tls12 = (SslProtocols)0x00000C00;
            public const SslProtocols Tls11 = (SslProtocols)0x00000300;
        }
    } 

2. Zaktualizuj pakiet Microsoft

Pobierz pakiet:

• W systemie Windows 2008 R2: Windows6.1-kb3154518-x64.msu
• W systemie Windows 2012 R2: Windows8.1-kb3154520-x64.msu

Aby pobrać partię i więcej szczegółów, możesz zobaczyć tutaj:

https://support.microsoft.com/en-us/help/3154518/support-for-tls-system-default-versions-included-in-the-.net-framework-3.5.1-on-windows-7 -sp1-and-server-2008-r2-sp1

Mechanizm zmiany rejestru zadziałał dla mnie po walce. Właściwie moja aplikacja działała w wersji 32-bitowej. Musiałem więc zmienić wartość pod ścieżką.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319

Typem wartości musi być DWORD, a wartość powyżej 0. Lepsze użycie 1.

Korzystam z .NET 4.5.2 i nie byłem zadowolony z żadnej z tych odpowiedzi. Ponieważ rozmawiam z systemem obsługującym TLS 1.2 i widzę, że wszystkie SSL3, TLS 1.0 i TLS 1.1 są zepsute i niebezpieczne w użyciu, nie chcę włączać tych protokołów. W .NET 4.5.2 protokoły SSL3 i TLS 1.0 są domyślnie włączone, co widzę w kodzie poprzez sprawdzenieServicePointManager.SecurityProtocol . W .NET 4.7 jest nowySystemDefaulttryb protokołu, który wyraźnie przekazuje wybór protokołu systemowi operacyjnemu, w którym moim zdaniem poleganie na rejestrze lub innych ustawieniach konfiguracji systemu byłoby odpowiednie. Nie wydaje się to jednak obsługiwane w .NET 4.5.2. W interesie pisania kodu kompatybilnego z systemem, który będzie podejmował właściwe decyzje, nawet jeśli TLS 1.2 zostanie nieuchronnie zepsuty w przyszłości lub gdy uaktualnię do .NET 4.7+ i przekażę większą odpowiedzialność za wybór odpowiedniego protokołu do systemu operacyjnego , Przyjąłem następujący kod:

SecurityProtocolType securityProtocols = ServicePointManager.SecurityProtocol;
if (securityProtocols.HasFlag(SecurityProtocolType.Ssl3) || securityProtocols.HasFlag(SecurityProtocolType.Tls) || securityProtocols.HasFlag(SecurityProtocolType.Tls11))
{
    securityProtocols &= ~(SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11);
    if (securityProtocols == 0)
    {
        securityProtocols |= SecurityProtocolType.Tls12;
    }
    ServicePointManager.SecurityProtocol = securityProtocols;
}

Ten kod wykryje, gdy włączony zostanie znany niezabezpieczony protokół, iw takim przypadku usuniemy te niebezpieczne protokoły. Jeśli nie pozostaną żadne inne jawne protokoły, wymusimy włączenie TLS 1.2, jako jedynego znanego bezpiecznego protokołu obsługiwanego przez .NET w tym momencie. Ten kod jest zgodny z poprzednimi wersjami, ponieważ weźmie pod uwagę nowe typy protokołów, o których nie wie, że zostaną dodane w przyszłości, a także będzie dobrze grał z nowymSystemDefaultstan w .NET 4.7, co oznacza, że ​​nie będę musiał ponownie odwiedzać tego kodu w przyszłości. Zdecydowanie zalecam przyjęcie takiego podejścia, zamiast bezwarunkowego kodowania jakichkolwiek stanów protokołu bezpieczeństwa bezwarunkowo, w przeciwnym razie będziesz musiał ponownie skompilować i zastąpić klienta nową wersją w celu uaktualnienia do nowego protokołu bezpieczeństwa, gdy TLS 1.2 jest nieuchronnie zepsuty, lub bardziej prawdopodobne, że będziesz musiał pozostawić istniejące niepewne protokoły włączone na lata na serwerze, co czyni Twoją organizację celem ataków.

Firma Microsoft opublikowała ostatnio najlepsze praktyki dotyczące tego. https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls

Podsumowanie

Celuj w .Net Framework 4.7, usuń dowolny kod ustawiający SecurityProtocol, dzięki czemu system operacyjny zapewni korzystanie z najbardziej bezpiecznego rozwiązania.

Uwaga: Należy również upewnić się, że najnowsza wersja TLS jest obsługiwana i włączona w systemie operacyjnym.

OS                          TLS 1.2 support

Windows 10                  \_ Supported, and enabled by default.
Windows Server 2016         /   
Windows 8.1                 \_ Supported, and enabled by default.
Windows Server 2012 R2      /
Windows 8.0                 \_ Supported, and enabled by default.
Windows Server 2012         /
Windows 7 SP1               \_ Supported, but not enabled by default*.
Windows Server 2008 R2 SP1  /
Windows Server 2008         -  Support for TLS 1.2 and TLS 1.1 requires an update. See Update to add support for TLS 1.1 and TLS 1.2 in Windows Server 2008 SP2.
Windows Vista               -  Not supported.

* To enable TLS1.2 via the registry see https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-12 

    Path: HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS1.2\Server

        Property: Enabled
        Type: REG_DWORD
        Value: 1

        Property: DisabledByDefault 
        Type: REG_DWORD
        Value: 0

    Path: HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS1.2\Client

        Property: Enabled
        Type: REG_DWORD
        Value: 1

        Property: DisabledByDefault 
        Type: REG_DWORD
        Value: 0

Aby uzyskać więcej informacji i starszych struktur, zapoznaj się z linkiem MS.

Dla kompletności, oto skrypt Powershell, który ustawia wyżej wymienione klucze rejestru:

new-itemproperty -path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -name "SchUseStrongCrypto" -Value 1 -PropertyType "DWord";
new-itemproperty -path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -name "SchUseStrongCrypto" -Value 1 -PropertyType "DWord"

Alternatywa dla twardego kodu ServicePointManager.SecurityProtocollub jawnego klucza SchUseStrongCrypto , jak wspomniano powyżej:
Możesz .NET może używać domyślnych ustawień SCHANNEL z kluczem SystemDefaultTlsVersions,
np .:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001

Najlepszym rozwiązaniem tego problemu wydaje się być uaktualnienie do wersji .NET 4.6 lub nowszej, która automatycznie wybierze silne protokoły, a także silne szyfry.

Jeśli nie możesz zaktualizować do wersji .NET 4.6, porada dotycząca ustawienia

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

I używając ustawień rejestru:

HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft.NETFramework \ v4.0.30319 - SchUseStrongCrypto = DWORD z 1 HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft.NETFramework \ v4.0.30319 - SchUseStrongCrypto = DWORD z 1

Skutkuje użyciem czegoś innego niż TLS 1.0 i silnego szyfru.

W moich testach tylko ustawienie w Wow6432Node robiło różnicę, mimo że moja aplikacja testowa została zbudowana dla dowolnego procesora.

Zgodnie z najlepszymi praktykami Transport Layer Security (TLS) z .NET Framework : Aby zapewnić bezpieczeństwo aplikacji .NET Framework, wersja TLS nie powinna być zakodowana na stałe. Zamiast tego ustaw klucze rejestru: SystemDefaultTlsVersions i SchUseStrongCrypto :

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

Jeśli możesz korzystać z .NET 4.7.1 lub nowszej wersji, użyje TLS 1.2 jako minimalnego protokołu opartego na możliwościach systemu operacyjnego. Zgodnie z zaleceniami Microsoft:

To ensure .NET Framework applications remain secure, the TLS version should not be hardcoded. .NET Framework applications should use the TLS version the operating system (OS) supports.

Dla klucza: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft.NETFramework \ v4.0.30319 Wartość: SchUseStrongCrypto

Musisz ustawić wartość na 1.