Risoluzione del problema TLS 1.0, seconda edizione

Questo documento presenta le indicazioni più recenti sull'identificazione e la rimozione rapida delle dipendenze del protocollo TLS (Transport Layer Security) versione 1.0 nel software basato su sistemi operativi Microsoft, seguendo i dettagli sulle modifiche del prodotto e sulle nuove funzionalità offerte da Microsoft per proteggere i propri clienti e servizi online. Deve essere usato come punto di partenza per la creazione di un piano di migrazione a un ambiente di rete TLS 1.2+. Sebbene le soluzioni descritte qui possano essere utili per rimuovere l'utilizzo di TLS 1.0 nei sistemi operativi non Microsoft o nelle librerie di crittografia, non sono incentrate su questo documento.

TLS 1.0 è un protocollo di sicurezza definito prima nel 1999 per stabilire canali di crittografia su reti computer. Microsoft ha supportato questo protocollo a partire da Windows XP/Server 2003. Anche se non è più il protocollo di sicurezza predefinito usato dai sistemi operativi moderni, TLS 1.0 è ancora supportato per la compatibilità con le versioni precedenti. L'evoluzione dei requisiti normativi e le nuove vulnerabilità di sicurezza in TLS 1.0 offrono alle aziende l'incentivo a disabilitare completamente TLS 1.0.

Microsoft consiglia ai clienti di affrontare questo problema rimuovendo le dipendenze TLS 1.0 negli ambienti e disabilitando TLS 1.0 a livello di sistema operativo, laddove possibile. Dato il periodo di tempo in cui TLS 1.0 è stato supportato dal settore software, è consigliabile che qualsiasi piano di deprecazione TLS 1.0 includa quanto segue:

• Analisi del codice per trovare/correggere istanze hardcoded di protocolli di sicurezza TLS 1.0 o versioni precedenti.

• Analisi degli endpoint di rete e analisi del traffico per identificare i sistemi operativi che usano protocolli TLS 1.0 o precedenti.

• Test di regressione completi tramite l'intero stack di applicazioni con TLS 1.0 disabilitato.

• Migrazione di sistemi operativi legacy e librerie/framework di sviluppo alle versioni in grado di negoziare TLS 1.2 per impostazione predefinita.

• Test di compatibilità tra sistemi operativi usati dall'azienda per identificare eventuali problemi di supporto di TLS 1.2.

• Coordinamento con i propri partner commerciali e clienti per notificare loro il passaggio alla deprecazione di TLS 1.0.

• Informazioni sui client che potrebbero non essere più in grado di connettersi ai server dopo che TLS 1.0 è disabilitato.

L'obiettivo di questo documento è fornire raccomandazioni che consentono di rimuovere i blocchi tecnici per disabilitare TLS 1.0, aumentando allo stesso tempo la visibilità dell'impatto di questa modifica ai propri clienti. Il completamento di tali indagini può contribuire a ridurre l'impatto aziendale della prossima vulnerabilità di sicurezza in TLS 1.0. Ai fini di questo documento, i riferimenti alla deprecazione di TLS 1.0 includono anche TLS 1.1.

Gli sviluppatori di software aziendali hanno una necessità strategica di adottare soluzioni più sicure e agili future (altrimenti note come Crypto Agility) per gestire i futuri compromessi dei protocolli di sicurezza. Anche se questo documento propone soluzioni agili per l'eliminazione dell'hardcoding TLS, le soluzioni Crypto Agility più ampie esulano dall'ambito di questo documento.

Stato corrente dell'implementazione tls 1.0 di Microsoft

L'implementazione di TLS 1.0 di Microsoft è priva di vulnerabilità di sicurezza note. A causa del potenziale per attacchi di downgrade del protocollo futuri e altre vulnerabilità TLS 1.0 non specifiche dell'implementazione di Microsoft, è consigliabile rimuovere le dipendenze da tutti i protocolli di sicurezza precedenti a TLS 1.2 (TLS 1.1/1.0/ SSLv3/SSLv2).

Nella pianificazione di questa migrazione a TLS 1.2+, gli sviluppatori e gli amministratori di sistema devono essere consapevoli del potenziale per il codificare in modo rigido la versione del protocollo nelle applicazioni sviluppate dai dipendenti e dai partner. L'hardcoding in questo caso indica che la versione di TLS è fissata a una versione obsoleta e meno sicura rispetto a quelle più recenti. Le versioni TLS più recenti della versione hardcoded non possono essere usate senza modificare il programma in questione. Questa classe di problema non può essere risolta senza modifiche al codice sorgente e distribuzione degli aggiornamenti software. Il hardcoding della versione del protocollo era comune in passato per scopi di test e supporto, poiché molti browser e sistemi operativi diversi avevano diversi livelli di supporto TLS.

Versioni supportate di TLS in Windows

Molti sistemi operativi hanno impostazioni predefinite della versione TLS obsolete o limiti di supporto che devono essere considerati.

Figura 1: Supporto del protocollo di sicurezza per versione del sistema operativo

Windows Server 2019 GS Edition è conforme a Microsoft SDL, TLS 1.2 solo con un set limitato di suite di crittografia.

Windows Server 2022 Edition è conforme a Microsoft SDL, TLS 1.2 e TLS 1.3 solo con un set limitato di suite di crittografia.

TLS 1.1/1.2 può essere abilitato in Windows Server 2008 tramite questo pacchetto facoltativo di Windows Update.

Per altre informazioni sulla deprecazione di TLS 1.0/1.1 in Internet Explorer/Edge, vedere Modernizzazione delle connessioni TLS in Microsoft Edge e Internet Explorer 11, Modifiche che influisce sulla compatibilità del sito in arrivo in Microsoft Edge e Disabilitazione di TLS/1.0 e TLS/1.1 nel nuovo browser Edge

Un modo rapido per determinare quale versione di TLS verrà richiesta da vari client quando ci si connette ai servizi online fa riferimento alla simulazione handshake in Qualys SSL Labs. Questa simulazione illustra le combinazioni del sistema operativo o del browser client tra i produttori. Vedere Appendice A alla fine di questo documento per un esempio dettagliato che illustra le versioni del protocollo TLS negoziate da varie combinazioni di sistemi operativi/browser client simulati durante la connessione a www.microsoft.com.

Se non è già stato completato, si consiglia vivamente di eseguire un inventario dei sistemi operativi utilizzati dall'azienda, dai clienti e dai partner (gli ultimi due tramite interazione/comunicazione o almeno raccolta delle stringhe User-Agent HTTP). Questo inventario può essere ulteriormente integrato dall'analisi del traffico nella rete perimetrale aziendale. In una situazione di questo tipo, l'analisi del traffico restituirà le versioni TLS negoziate correttamente dai clienti/partner che si connettono ai servizi, ma il traffico stesso rimarrà crittografato.

Miglioramenti alla progettazione di Microsoft per eliminare le dipendenze TLS 1.0

Dalla versione 1 di questo documento, Microsoft ha fornito numerosi aggiornamenti software e nuove funzionalità a supporto della deprecazione di TLS 1.0. Questi includono:

• Registrazione personalizzata IIS per correlare l'IP del client e la stringa dell'agente utente, l'URI del servizio, la versione del protocollo TLS e la suite crittografica.

  • Con questa registrazione, gli amministratori possono infine quantificare l'esposizione dei clienti a TLS debole.

• SecureScore : per aiutare gli amministratori tenant di Office 365 a identificare il proprio utilizzo TLS debole, il portale SecureScore è stato creato per condividere queste informazioni come tls 1.0 ha chiuso il supporto in Office 365 nel mese di ottobre 2018.

  • Questo portale fornisce agli amministratori tenant di Office 365 le informazioni preziose necessarie per contattare i propri clienti che potrebbero non essere a conoscenza delle proprie dipendenze TLS 1.0.

  • Per altre informazioni, visitare https://securescore.microsoft.com/.

• Aggiornamenti di .Net Framework per eliminare l'hardcoding a livello di app e impedire dipendenze TLS 1.0 ereditate dal framework.

• Le linee guida per gli sviluppatori e gli aggiornamenti software sono stati rilasciati per aiutare i clienti a identificare ed eliminare le dipendenze .Net da TLS debole: Procedure consigliate per Transport Layer Security (TLS) con .NET Framework

  • FYI: è probabile che tutte le app destinate a .NET 4.5 o versioni successive debbano essere modificate per supportare TLS 1.2.

• TLS 1.2 è stato retroportato in Windows Server 2008 SP2 e XP POSReady 2009 per aiutare i clienti con obblighi legacy.

• Altri annunci verranno effettuati all'inizio del 2019 e comunicati nei successivi aggiornamenti di questo documento.

Ricerca e correzione delle dipendenze TLS 1.0 nel codice

Per i prodotti che usano le librerie di crittografia e i protocolli di sicurezza forniti dal sistema operativo Windows, la procedura seguente deve aiutare a identificare qualsiasi utilizzo di TLS 1.0 hardcoded nelle applicazioni:

1. Identificare tutte le istanze di AcquireCredentialsHandle(). Ciò consente ai revisori di avvicinarsi più vicino ai blocchi di codice in cui TLS può essere hardcoded.

2. Esaminare le istanze delle strutture SecPkgContext_SupportedProtocols e SecPkgContext_ConnectionInfo per TLS inserito in modo fisso.

3. Nel codice nativo impostare qualsiasi assegnazione diversa da zero di grbitEnabledProtocols su zero. In questo modo il sistema operativo può usare la versione TLS predefinita.

4. Disabilitare la modalità FIPS se è abilitata a causa del potenziale conflitto con le impostazioni necessarie per disabilitare in modo esplicito TLS 1.0/1.1 in questo documento. Per altre informazioni, vedere Appendice B .

5. Aggiornare e ricompilare tutte le applicazioni che usano WinHTTP ospitate in Server 2012 o versioni precedenti.

   1. Applicazioni gestite: ricompilare e ridestinare per la versione più recente di .NET Framework.

   2. Le applicazioni devono aggiungere codice per supportare TLS 1.2 tramite WinHttpSetOption

6. Per coprire tutte le basi, analizzare il codice sorgente e i file di configurazione del servizio online per i modelli seguenti corrispondenti ai valori di tipo enumerati comunemente usati nella codifica hardcoding TLS:

   1. SecurityProtocolType

   2. SSLv2, SSLv23, SSLv3, TLS1, TLS 10, TLS11

   3. WINHTTP_FLAG_SECURE_PROTOCOL_

   4. SP_PROT_

   5. NSStreamSocketSecurityLevel

   6. PROTOCOL_SSL o PROTOCOL_TLS

La soluzione consigliata in tutti i casi precedenti consiste nel rimuovere la selezione della versione del protocollo hardcoded e rinviare all'impostazione predefinita del sistema operativo. Se si usa DevSkim, fare clic qui per visualizzare le regole relative ai controlli precedenti che è possibile usare con il proprio codice.

Aggiornare gli script di Windows PowerShell o le impostazioni correlate del Registro di sistema

Windows PowerShell usa .NET Framework 4.5, che non include TLS 1.2 come protocollo disponibile. Per risolvere questo problema, sono disponibili due soluzioni:

1. Modificare lo script in questione per includere quanto segue:

   [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;
   

2. Aggiungere una chiave del Registro di sistema a livello di sistema (ad esempio tramite Criteri di gruppo) a qualsiasi computer che deve effettuare connessioni TLS 1.2 da un'app .NET. In questo modo .NET userà le versioni TLS "System Default" che aggiunge TLS 1.2 come protocollo disponibile e consentirà agli script di usare versioni TLS future quando il sistema operativo li supporta. (ad esempio, TLS 1.3)

   reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:64 (Il comando sopra aggiunge l'impostazione SystemDefaultTlsVersions al registro di Windows. Assicurati di eseguirlo con diritti amministrativi per modificare le impostazioni di registro.)

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

Le soluzioni (1) e (2) si escludono a vicenda, ovvero non devono essere implementate insieme.

Ricompilare/ridestinare le applicazioni gestite usando la versione più recente di .Net Framework

Le applicazioni che usano versioni di .NET Framework precedenti alla 4.7 possono avere limitazioni che limitano efficacemente il supporto a TLS 1.0 indipendentemente dalle impostazioni predefinite del sistema operativo sottostanti. Per altre informazioni, vedere il diagramma seguente e le procedure consigliate di Transport Layer Security (TLS) con .NET Framework .

SystemDefaultTLSVersion ha la precedenza sulla destinazione a livello di app delle versioni TLS. La procedura consigliata consiste nel rinviare sempre alla versione TLS predefinita del sistema operativo. È anche l'unica soluzione crypto-agile che consente alle app di sfruttare il futuro supporto tls 1.3.

Se si utilizzano versioni precedenti di .NET Framework, ad esempio 4.5.2 o 3.5, per impostazione predefinita l'applicazione userà i protocolli meno recenti e non consigliati, ad esempio SSL 3.0 o TLS 1.0. È consigliabile eseguire l'aggiornamento alle versioni più recenti di .NET Framework, ad esempio .NET Framework 4.6 o impostare le chiavi del Registro di sistema appropriate per "UseStrongCrypto".

Test con TLS 1.2+

Seguendo le correzioni consigliate nella sezione precedente, i prodotti devono essere testati per la regressione per gli errori di negoziazione del protocollo e la compatibilità con altri sistemi operativi nell'organizzazione.

• Il problema più comune in questo test di regressione sarà un errore di negoziazione TLS a causa di un tentativo di connessione client da un sistema operativo o un browser che non supporta TLS 1.2.

  • Ad esempio, un client Vista non riuscirà a negoziare TLS con un server configurato per TLS 1.2+ perché la versione massima supportata di TLS di Vista è 1.0. Il client deve essere aggiornato o rimosso in un ambiente TLS 1.2+.

• I prodotti che usano l'autenticazione TLS reciproca basata su certificati possono richiedere test di regressione aggiuntivi perché il codice di selezione dei certificati associato a TLS 1.0 era meno espressivo di quello per TLS 1.2.

  • Se un prodotto utilizza MTLS con un certificato da un percorso non standard (al di fuori degli archivi di certificati standard in Windows), tale codice potrebbe dover essere aggiornato per garantire che il certificato venga acquisito correttamente.

• Le interdipendenze dei servizi devono essere esaminate per individuare i problemi.

  • Tutti i servizi che interagiscono con i servizi di terze parti devono eseguire test di interoperabilità aggiuntivi con tali terze parti.

  • Tutte le applicazioni non Windows o i sistemi operativi server in uso richiedono indagine/conferma che possono supportare TLS 1.2. La scansione è il modo più semplice per determinare ciò.

Un semplice progetto per testare queste modifiche in un servizio online è costituito dai seguenti elementi:

1. Eseguire un'analisi dei sistemi dell'ambiente di produzione per identificare i sistemi operativi che non supportano TLS 1.2.

2. Analizzare il codice sorgente e i file di configurazione del servizio online per i TLS hardcoded, come descritto in "Ricerca e correzione delle dipendenze TLS 1.0 nel codice"

3. Aggiornare/ricompilare le applicazioni in base alle esigenze:

   1. App gestite

      1. Ricompilare in base alla versione più recente di .NET Framework.

      2. Verificare che qualsiasi utilizzo dell'enumerazione SSLProtocols sia impostato su SSLProtocols.None per usare le impostazioni predefinite del sistema operativo.

   2. App WinHTTP: ricompilare con WinHttpSetOption per supportare TLS 1.2

4. Avviare i test in un ambiente di pre-produzione o staging con tutti i protocolli di sicurezza precedenti a TLS 1.2 disabilitati tramite il Registro di sistema.

5. Correzione di eventuali istanze rimanenti di hardcoding TLS man mano che vengono rilevate durante i test. Ridistribuire il software ed eseguire una nuova esecuzione di test di regressione.

Comunicare ai partner i piani di deprecazione di TLS 1.0

Dopo aver risolto il problema dell'hardcoding TLS e aver completato gli aggiornamenti del framework di sviluppo/sistema operativo, se si sceglie di deprecare TLS 1.0, sarà necessario coordinare i clienti e i partner:

• Il contatto anticipato con partner/clienti è essenziale per un'efficace ritiro di TLS 1.0. Almeno questo deve essere costituito da post di blog, white paper o altri contenuti Web.

• I partner devono valutare la propria prontezza TLS 1.2 tramite le iniziative di test di analisi del codice e test di regressione, come descritto nelle sezioni precedenti.

Conclusione

La rimozione delle dipendenze TLS 1.0 è una questione complessa da gestire dall'inizio alla fine. Microsoft e i partner del settore stanno eseguendo azioni su questo oggi per garantire che l'intero stack di prodotti sia più sicuro per impostazione predefinita, dai componenti del sistema operativo e dai framework di sviluppo fino alle applicazioni/servizi basati su di essi. Seguendo le raccomandazioni fornite in questo documento, l'azienda creerà il percorso giusto e saprà quali sfide aspettarsi. Aiuterà anche i clienti a diventare più preparati per la transizione.

Appendice A: Simulazione handshake per vari client che si connettono a www.microsoft.com, a cura di SSLLabs.com

Appendice B: Deprecazione di TLS 1.0/1.1 durante la conservazione della modalità FIPS

Seguire questa procedura se la rete richiede la modalità FIPS, ma si vuole anche deprecare TLS 1.0/1.1:

1. Configurare le versioni TLS tramite il Registro di sistema impostando "Abilitato" su zero per le versioni TLS indesiderate.

2. Disabilitare curva 25519 (solo Server 2016) tramite Criteri di gruppo.

3. Disabilitare eventuali pacchetti di crittografia usando algoritmi non consentiti dalla pubblicazione FIPS pertinente. Per Server 2016 (presupponendo che le impostazioni predefinite siano effettive), significa disabilitare le crittografie RC4, PSK e NULL.

Collaboratori/grazie a

Mark Cartwright
Bryan Sullivan
Patrick Jungles
Michael Scovetta
Tony Rice
David LeBlanc
Mortimer Cook
Daniel Sommerfeld
Andrei Popov
Michiko Short
Justin Burke
Gov Maharaj
Brad Turner
Sean Stevenson