Disabilitare il fallback SSL e utilizzare solo TLS per le connessioni in uscita in .NET? (Attenuazione del barboncino)

Sto cercando di mitigare la nostra vulnerabilità all'attacco di fallback Poodle SSL 3.0 . I nostri amministratori hanno già iniziato a disabilitare SSL a favore di TLS per le connessioni in entrata ai nostri server. E abbiamo anche consigliato al nostro team di disabilitare SSL nei loro browser web. Sto ora esaminando la nostra base di codice .NET, che avvia connessioni HTTPS con vari servizi tramite System.Net.HttpWebRequest . Credo che queste connessioni potrebbero essere vulnerabili a un attacco MITM se consentissero il fallback da TLS a SSL. Ecco cosa ho determinato finora. Qualcuno potrebbe ricontrollare questo per verificare che ho ragione? Questa vulnerabilità è nuova di zecca, quindi devo ancora vedere alcuna guida da Microsoft su come mitigarla in .NET:

1. I protocolli consentiti per la classe System.Net.Security.SslStream, che è alla base della comunicazione sicura in .NET, vengono impostati globalmente per ogni AppDomain tramite la proprietà System.Net.ServicePointManager.SecurityProtocol .

2. Il valore predefinito di questa proprietà in .NET 4.5 è Ssl3 | Tls(anche se non riesco a trovare la documentazione per eseguire il backup). SecurityProtocolType è un'enumerazione con l'attributo Flags, quindi è un OR bit per bit di questi due valori. Puoi verificarlo nel tuo ambiente con questa riga di codice:

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

3. Questo dovrebbe essere cambiato solo Tls, o forse Tls12, prima di avviare qualsiasi connessione nella tua app:

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

4. Importante: poiché la proprietà supporta più flag bit per bit, presumo che SslStream non eseguirà automaticamente il fallback su altri protocolli non specificati durante l'handshake. Altrimenti, quale sarebbe il punto di supportare più flag?

Aggiornamento su TLS 1.0 vs 1.1 / 1.2:

Secondo l'esperto di sicurezza di Google Adam Langley, TLS 1.0 è stato successivamente ritenuto vulnerabile a POODLE se non implementato correttamente , quindi dovresti considerare di passare esclusivamente a TLS 1.2.

Aggiornamento per .NET Framework 4.7 e versioni successive:

Come accennato di seguito dal Prof Von Lemongargle , a partire dalla versione 4.7 di .NET Framework, non è necessario utilizzare questo hack poiché l'impostazione predefinita consentirà al sistema operativo di scegliere la versione del protocollo TLS più sicura. Per ulteriori informazioni, vedere le procedure consigliate per Transport Layer Security (TLS) con .NET Framework .

Stiamo facendo la stessa cosa. Per supportare solo TLS 1.2 e nessun protocollo SSL, puoi farlo:

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

SecurityProtocolType.Tls è solo TLS 1.0, non tutte le versioni TLS.

A fianco: se vuoi controllare che il tuo sito non consenta connessioni SSL, puoi farlo qui (non credo che questo sarà influenzato dall'impostazione di cui sopra, abbiamo dovuto modificare il registro per forzare IIS a utilizzare TLS per le connessioni in entrata): https://www.ssllabs.com/ssltest/index.html

Per disabilitare SSL 2.0 e 3.0 in IIS, vedere questa pagina: https://www.sslshopper.com/article-how-to-disable-ssl-2.0-in-iis-7.html

La risposta di @Eddie Loeffen sembra essere la risposta più popolare a questa domanda, ma ha alcuni effetti negativi a lungo termine. Se si esamina la pagina della documentazione per System.Net.ServicePointManager.SecurityProtocol qui, la sezione dei commenti implica che la fase di negoziazione dovrebbe solo risolvere questo problema (e forzare il protocollo è una cattiva pratica perché in futuro anche TLS 1.2 sarà compromesso). Tuttavia, non cercheremmo questa risposta se lo facesse.

Dalla ricerca, sembra che il protocollo di negoziazione ALPN sia necessario per arrivare a TLS1.2 nella fase di negoziazione. Lo abbiamo preso come punto di partenza e abbiamo provato le versioni più recenti del framework .Net per vedere da dove inizia il supporto. Abbiamo scoperto che .Net 4.5.2 non supporta la negoziazione a TLS 1.2, ma .Net 4.6 lo fa.

Quindi, anche se la forzatura di TLS1.2 porterà a termine il lavoro ora, ti consiglio invece di eseguire l'aggiornamento a .Net 4.6. Poiché si tratta di un problema PCI DSS per giugno 2016, la finestra è breve, ma il nuovo framework è una risposta migliore.

AGGIORNAMENTO: Lavorando dai commenti, ho creato questo:

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

Per convalidare il concetto, ho combinato SSL3 e TLS1.2 e ho eseguito il codice indirizzato a un server che supporta solo TLS 1.0 e TLS 1.2 (1.1 è disabilitato). Con i protocolli or'd, sembra connettersi bene. Se cambio a SSL3 e TLS 1.1, non è riuscito a connettersi. La mia convalida utilizza HttpWebRequest da System.Net e chiama solo GetResponse (). Ad esempio, ho provato questo e ho fallito:

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

mentre questo ha funzionato:

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

Questo ha un vantaggio rispetto alla forzatura di TLS 1.2 in quanto, se il framework .Net viene aggiornato in modo che ci siano più voci in Enum, saranno supportate dal codice così com'è. Ha uno svantaggio rispetto al solo utilizzo di .Net 4.6 in quanto 4.6 utilizza ALPN e dovrebbe supportare nuovi protocolli se non viene specificata alcuna restrizione.

Modifica 29/4/2019 - Microsoft ha pubblicato questo articolo lo scorso ottobre. Ha una buona sinossi della loro raccomandazione su come questo dovrebbe essere fatto nelle varie versioni di .net framework.

@watson

Su Windows Form è disponibile, all'inizio della classe put

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

poiché Windows è a thread singolo, è tutto ciò di cui hai bisogno, nel caso in cui sia un servizio devi metterlo proprio sopra la chiamata al servizio (poiché non si può dire su quale thread ti troverai).

using System.Security.Principal 

è anche necessario.

Se sei curioso di sapere quali protocolli .NET supporta, puoi provare HttpClient su 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");

Il risultato è schiacciante:

Il tuo client utilizza TLS 1.0, che è molto vecchio, probabilmente suscettibile all'attacco BEAST, e non dispone delle migliori suite di cifratura disponibili. Aggiunte come AES-GCM e SHA256 per sostituire MD5-SHA-1 non sono disponibili per un client TLS 1.0 così come per molte suite di cifratura più moderne.

Come spiega Eddie sopra, puoi abilitare manualmente protocolli migliori:

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

Non so perché utilizzi protocolli sbagliati fuori dagli schemi. Sembra una scelta di configurazione scadente, equivalente a un grave bug di sicurezza (scommetto che molte applicazioni non cambiano l'impostazione predefinita). Come segnalarlo?

Ho dovuto lanciare l'equivalente intero per aggirare il fatto che sto ancora utilizzando .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,
   } 
*/

Ho trovato che la soluzione più semplice è aggiungere due voci di registro come segue (eseguilo in un prompt dei comandi con privilegi di amministratore):

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

Queste voci sembrano influenzare il modo in cui .NET CLR sceglie un protocollo quando effettua una connessione sicura come client.

Ulteriori informazioni su questa voce di registro sono disponibili qui:

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

Non solo è più semplice, ma supponendo che funzioni per il tuo caso, molto più robusto di una soluzione basata su codice, che richiede agli sviluppatori di monitorare il protocollo e lo sviluppo e aggiornare tutto il loro codice pertinente. Si spera che modifiche all'ambiente simili possano essere apportate per TLS 1.3 e versioni successive, a condizione che .NET rimanga abbastanza stupido da non scegliere automaticamente il protocollo più alto disponibile.

NOTA : anche se, secondo l'articolo sopra, questo dovrebbe solo disabilitare RC4 e non si penserebbe che questo cambierebbe se il client .NET è autorizzato a utilizzare TLS1.2 + o meno, per qualche motivo lo ha effetto.

NOTA : come notato da @Jordan Rieger nei commenti, questa non è una soluzione per POODLE, poiché non disabilita i protocolli meno recenti a: consente semplicemente al client di lavorare con i protocolli più recenti, ad esempio quando un server con patch ha disabilitato il vecchio protocolli. Tuttavia, con un attacco MITM, ovviamente un server compromesso offrirà al client un protocollo precedente, che il client utilizzerà quindi felicemente.

TODO : Prova a disabilitare l'uso lato client di TLS1.0 e TLS1.1 con queste voci di registro, tuttavia non so se le librerie client HTTP .NET rispettano queste impostazioni o meno:

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