Qual è il protocollo di sicurezza predefinito per la comunicazione con server che supportano fino a TLS 1.2? Per .NETimpostazione predefinita, sceglierò il protocollo di sicurezza più elevato supportato sul lato server o devo aggiungere esplicitamente questa riga di codice:

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

C'è un modo per cambiare questo valore predefinito, oltre a una modifica del codice?

Infine, .NET 4.0supporta solo fino a TLS 1.0? cioè devo aggiornare i progetti client a 4.5 per supportare TLS 1.2.

La mia motivazione è quella di rimuovere il supporto SSLv3sul lato client anche se il server lo supporta (ho già uno script PowerShell per disabilitarlo nel registro macchina) e per supportare il protocollo TLS più alto supportato dal server.

Aggiornamento: guardando la ServicePointManagerclasse in .NET 4.0non vedo valori enumerati per TLS 1.0e 1.1. In entrambi .NET 4.0/4.5, il valore predefinito è SecurityProtocolType.Tls|SecurityProtocolType.Ssl3. Si spera che questo valore predefinito non si interrompa disabilitando SSLv3nel registro.

Tuttavia, ho deciso che devo aggiornare tutte le app .NET 4.5e aggiungere esplicitamente SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;comunque a tutto il codice di bootstrap di tutte le applicazioni.

Ciò renderà richieste in uscita a varie API e servizi per non effettuare il downgrade SSLv3e dovrebbe selezionare il livello più alto di TLS.

Questo approccio sembra ragionevole o eccessivo? Ho molte applicazioni da aggiornare e voglio provarle in futuro poiché ho sentito che TLS 1.0potrebbero essere deprecate nel prossimo futuro da alcuni provider.

Come client che effettua richieste in uscita alle API, la disabilitazione di SSL3 nel registro ha anche un effetto nel framework .NET? Vedo per impostazione predefinita, TLS 1.1 e 1.2 non sono abilitati, dobbiamo abilitarlo tramite il registro? RE http://support.microsoft.com/kb/245030 .

Dopo un po 'di indagine, credo che le impostazioni del registro non avranno alcun effetto poiché si applicano a IIS (sottochiave del server) e ai browser (sottochiave del client).

Spiacente, questo post si è trasformato in più domande, seguite da risposte "forse".

Alcuni di coloro che hanno lasciato commenti hanno notato che l'impostazione System.Net.ServicePointManager.SecurityProtocolsu valori specifici significa che la tua app non sarà in grado di sfruttare le future versioni TLS che potrebbero diventare i valori predefiniti nei futuri aggiornamenti di .NET. Invece di specificare un elenco fisso di protocolli, puoi invece attivare o disattivare i protocolli che conosci e a cui tieni, lasciando tutti gli altri come sono.

Per attivare TLS 1.1 e 1.2 senza influire su altri protocolli:

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

Notare l'uso di |=per attivare queste bandiere senza spegnerne altre.

Per disattivare SSL3 senza influire su altri protocolli:

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

L'impostazione predefinita System.Net.ServicePointManager.SecurityProtocolin entrambi .NET 4.0/4.5è SecurityProtocolType.Tls|SecurityProtocolType.Ssl3.

.NET 4.0supporta fino a TLS 1.0mentre .NET 4.5supporta fino aTLS 1.2

Tuttavia, il targeting di un'applicazione .NET 4.0può ancora supportare fino a TLS 1.2quando .NET 4.5è installato nello stesso ambiente. .NET 4.5si installa sopra .NET 4.0, sostituendo System.dll.

Ho verificato questo osservando il protocollo di sicurezza corretto impostato nel traffico fiddler4e impostando manualmente i valori enumerati in un .NET 4.0progetto:

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

Riferimento:

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

Se provi l'hacking in un ambiente con SOLO .NET 4.0installato, otterrai l'eccezione:

Eccezione non gestita: System.NotSupportedException: il protocollo di sicurezza richiesto non è supportato. su System.Net.ServicePointManager.set_SecurityProtocol (SecurityProtocolType v alue)

Tuttavia, non consiglierei questo "hack" poiché una patch futura, ecc. Potrebbe romperlo. *

Pertanto, ho deciso che il percorso migliore per rimuovere il supporto SSLv3è quello di:

1. Aggiorna tutte le applicazioni a .NET 4.5

2. Aggiungi quanto segue al codice boostrapping per sovrascrivere l'impostazione predefinita e la prova futura:

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

* Qualcuno mi corregga se questo trucco è sbagliato, ma i test iniziali vedo che funziona

È possibile ignorare il comportamento predefinito nel seguente registro:

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

e

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

Per i dettagli, consultare l' implementazione diServicePointManager .

Creare un file di testo con .regun'estensione e il seguente contenuto:

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

O scaricalo dalla seguente fonte:

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

Fare doppio clic per installare ...

Ho scoperto che quando specifico solo TLS 1.2, sarà comunque negoziato con 1.1. System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Ho specificato questo nel metodo di avvio Global.asax per la mia app Web .net 4.5.

Il seguente codice sarà:

• protocolli di stampa abilitati
• stampa i protocolli disponibili
• abilitare TLS1.2 se la piattaforma lo supporta e se non è abilitato per iniziare
• disabilitare SSL3 se è abilitato
• stampa il risultato finale

costanti:

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

Altri protocolli non saranno interessati. Questo lo rende compatibile con i protocolli futuri (Tls1.3, ecc.).

Codice

// 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);

Produzione

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

Ho riscontrato il problema quando il mio cliente ha aggiornato TLS da 1.0 a 1.2. La mia applicazione utilizza .net framework 3.5 ed è in esecuzione sul server. Quindi l'ho risolto in questo modo:

1. Risolvi il programma

Prima di chiamare HttpWebRequest.GetResponse () aggiungere questo comando:

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

Estende 2 DLL aggiungendo 2 nuove classi: System.Net e 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. Aggiorna batch Microsoft

Scarica batch:

• Per Windows 2008 R2: windows6.1-kb3154518-x64.msu
• Per Windows 2012 R2: windows8.1-kb3154520-x64.msu

Per il download batch e maggiori dettagli puoi vedere qui:

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-e-server-2008-r2-sp1

Il meccanismo di modifica del registro ha funzionato per me dopo una lotta. In realtà la mia applicazione funzionava a 32 bit. Quindi ho dovuto cambiare il valore sotto il percorso.

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

Il tipo di valore deve essere DWORD e un valore superiore a 0. Utilizzare meglio 1.

Sono in esecuzione con .NET 4.5.2 e non ero contento di nessuna di queste risposte. Dato che sto parlando con un sistema che supporta TLS 1.2 e visto che SSL3, TLS 1.0 e TLS 1.1 sono tutti rotti e non sicuri per l'uso, non voglio abilitare questi protocolli. In .NET 4.5.2, i protocolli SSL3 e TLS 1.0 sono entrambi abilitati per impostazione predefinita, che posso vedere nel codice controllando ServicePointManager.SecurityProtocol. Sotto .NET 4.7, c'è il nuovoSystemDefaultmodalità di protocollo che passa esplicitamente la selezione del protocollo al sistema operativo, dove credo sia opportuno basarsi sul registro o su altre impostazioni di configurazione del sistema. Tuttavia, ciò non sembra essere supportato in .NET 4.5.2. Nell'interesse di scrivere un codice compatibile con i forward, questo continuerà a prendere le giuste decisioni anche quando TLS 1.2 verrà inevitabilmente rotto in futuro, o quando eseguirò l'aggiornamento a .NET 4.7+ e consegnerò più responsabilità per la selezione di un protocollo appropriato al sistema operativo , Ho adottato il seguente codice:

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;
}

Questo codice rileverà quando è abilitato un protocollo non sicuro noto e, in questo caso, rimuoveremo questi protocolli non sicuri. Se non rimangono altri protocolli espliciti, forzeremo quindi l'abilitazione di TLS 1.2, come l'unico protocollo sicuro noto supportato da .NET in questo momento. Questo codice è compatibile in avanti, poiché prenderà in considerazione nuovi tipi di protocollo che non sa di essere aggiunto in futuro e giocherà anche con il nuovoSystemDefaultstato in .NET 4.7, il che significa che non dovrò visitare nuovamente questo codice in futuro. Consiglio vivamente di adottare un approccio come questo, anziché codificare incondizionatamente qualsiasi particolare protocollo di sicurezza in modo incondizionato, altrimenti dovrai ricompilare e sostituire il tuo client con una nuova versione per aggiornare a un nuovo protocollo di sicurezza quando TLS 1.2 è inevitabilmente rotto, o più probabilmente dovrai lasciare i protocolli non sicuri esistenti per anni sul tuo server, rendendo la tua organizzazione un bersaglio per gli attacchi.

Microsoft ha recentemente pubblicato le migliori pratiche al riguardo. https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls

Sommario

Target .Net Framework 4.7, rimuovi qualsiasi codice che imposta SecurityProtocol, quindi il sistema operativo ti garantirà di utilizzare la soluzione più sicura.

NB: Sarà inoltre necessario assicurarsi che l'ultima versione di TLS sia supportata e abilitata sul proprio sistema operativo.

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

Per ulteriori informazioni e quadri precedenti, fare riferimento al collegamento MS.

Per completezza, ecco uno script Powershell che imposta le suddette chiavi di registro:

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"

Un'alternativa alla codifica hardwareServicePointManager.SecurityProtocol o alla chiave esplicita SchUseStrongCrypto come menzionato sopra:
puoi dire a .NET di utilizzare le impostazioni SCHANNEL predefinite con la chiave SystemDefaultTlsVersions,
ad esempio:

[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

La soluzione MIGLIORE a questo problema sembra essere l'aggiornamento a .NET 4.6 o versione successiva, che sceglierà automaticamente protocolli forti e cifre forti.

Se non è possibile eseguire l'aggiornamento a .NET 4.6, il consiglio di impostazione

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

E usando le impostazioni del registro:

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

Risultati nell'uso di qualcosa di diverso da TLS 1.0 e una cifra forte.

Nel mio test, solo l'impostazione nel nodo Wow6432 ha fatto la differenza, anche se la mia applicazione di test è stata creata per qualsiasi CPU.

Secondo le migliori pratiche di Transport Layer Security (TLS) con .NET Framework : Per garantire che le applicazioni .NET Framework rimangano sicure, la versione TLS non deve essere codificata. Invece imposta le chiavi di registro: SystemDefaultTlsVersions e 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

Se è possibile utilizzare .NET 4.7.1 o versioni successive, utilizzerà TLS 1.2 come protocollo minimo in base alle funzionalità del sistema operativo. Come da raccomandazione 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.

Per chiave: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft.NETFramework \ v4.0.30319 Valore: SchUseStrongCrypto

Devi impostare il valore su 1.