Risoluzione del problema relativo a TLS 1.0, seconda edizione

In questo documento vengono illustrate le indicazioni più recenti su come identificare e rimuovere rapidamente le dipendenze del protocollo TLS (Transport Layer Security) versione 1.0 nel software basato sui sistemi operativi Microsoft, con informazioni dettagliate sulle modifiche dei prodotti e sulle nuove funzionalità fornite da Microsoft per proteggere i clienti e i servizi online. È concepito per essere usato come punto di partenza per la creazione di un piano di migrazione in un ambiente di rete TLS 1.2+. Anche se le soluzioni descritte in questo articolo possono essere utili per la rimozione dell'utilizzo di TLS 1.0 nei sistemi operativi non Microsoft o nelle librerie di crittografia, non sono oggetto di questo documento.

TLS 1.0 è un protocollo di sicurezza definito per la prima volta nel 1999 per stabilire canali di crittografia su reti di computer. Questo protocollo è supportato da Microsoft a partire da Windows XP/Server 2003. Sebbene non sia 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 delle nuove vulnerabilità di sicurezza in TLS 1.0 fornisce alle aziende l'incentivo a disabilitare completamente TLS 1.0.

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

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

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

• Test di regressione completo sull'intero stack di applicazioni con TLS 1.0 disabilitato.

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

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

• Coordinamento con partner commerciali e clienti per notificare il passaggio per deprecare TLS 1.0.

• Capire quali client potrebbero non essere più in grado di connettersi ai server una volta disabilitato TLS 1.0.

L'obiettivo di questo documento è fornire consigli che consentono di rimuovere gli ostacoli tecnici per la disabilitazione di TLS 1.0, aumentando al contempo la visibilità dell'impatto di questo cambiamento sui clienti. Il completamento di queste indagini può contribuire a ridurre l'impatto aziendale della vulnerabilità di sicurezza successiva 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 un'esigenza strategica di adottare soluzioni più sicure e agili per il futuro (altrimenti note come agilità crittografica) per affrontare i compromessi dei protocolli di sicurezza futuri. Sebbene in questo documento si propongano soluzioni agili per l'eliminazione dell'hardcoding di TLS, le soluzioni di agilità crittografica più ampie esulano dall'ambito di questo documento.

Stato corrente dell'implementazione di TLS 1.0 da parte di Microsoft

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

Per la pianificazione della migrazione a TLS 1.2+, gli sviluppatori e gli amministratori di sistema devono essere consapevoli del rischio di hardcoding della versione del protocollo nelle applicazioni sviluppate dai propri dipendenti e partner. In questo caso l'hardcoding significa che la versione TLS è fissata su una versione obsoleta e meno sicura rispetto alle versioni più recenti. Le versioni TLS più recenti della versione hardcoded non possono essere usate senza modificare il programma in questione. Questa classe di problemi non può essere risolta senza modifiche al codice sorgente e senza la distribuzione di aggiornamenti software. L'hardcoding della versione del protocollo era comune in passato a scopo di test e supporto, in quanto molti browser e sistemi operativi diversi avevano diversi livelli di supporto di TLS.

Versioni supportate di TLS in Windows

Molti sistemi operativi hanno valori predefiniti della versione TLS obsoleti o limiti di cui è necessario tenere conto.

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 Microsoft IE/Edge, vedere Modernizzazione delle connessioni TLS in Microsoft Edge e Internet Explorer 11, Modifiche che influiscono sulla compatibilità del sito in Microsoft Edge e Disabilitazione di TLS/1.0 e TLS/1.1 nel nuovo browser Microsoft Edge

Un modo rapido per determinare quale versione di TLS verrà richiesta dai vari client quando si connettono ai servizi online consiste nel fare riferimento alla simulazione di handshake in Qualys SSL Labs. Questa simulazione riguarda le combinazioni di sistema operativo client/browser tra i produttori. Vedere l'Appendice A alla fine di questo documento per un esempio dettagliato che mostra le versioni del protocollo TLS negoziate da varie combinazioni di sistema operativo client/browser simulate durante la connessione a www.microsoft.com.

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

Miglioramenti di progettazione di Microsoft per eliminare le dipendenze di TLS 1.0

Dalla versione v1 di questo documento, Microsoft ha fornito una serie di aggiornamenti software e nuove funzionalità per supportare la deprecazione di TLS 1.0. tra cui:

• Registrazione personalizzata IIS per correlare l'IP client/stringa dell'agente utente, l'URI del servizio, la versione del protocollo TLS e il pacchetto di crittografia.

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

• SecureScore: per aiutare gli amministratori del tenant di Office 365 a identificare l'utilizzo di TLS vulnerabili, è stato creato il portale SecureScore allo scopo di condividere queste informazioni poiché TLS 1.0 non è più supportato da Office 365 da ottobre 2018.

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

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

• Aggiornamenti di .NET Framework per eliminare l'hardcoding a livello di app e impedire le dipendenze di 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.

• È stato eseguito il backporting di TLS 1.2 a Windows Server 2008 SP2 e XP POSReady 2009 per aiutare i clienti con obblighi legacy.

• Verranno effettuati altri annunci all'inizio del 2019 e comunicati negli aggiornamenti successivi di questo documento.

Ricerca e correzione delle dipendenze di TLS 1.0 nel codice

Per i prodotti che usano le librerie di crittografia e i protocolli di sicurezza forniti dal sistema operativo Windows, i passaggi seguenti consentono di identificare qualsiasi utilizzo di TLS 1.0 hardcoded nelle applicazioni:

1. Identificare tutte le istanze di AcquireCredentialsHandle(). Questo consente ai revisori di avvicinarsi a blocchi di codice in cui TLS può essere hardcoded.

2. Esaminare le istanze delle strutture SecPkgContext_SupportedProtocols e SecPkgContext_Connessione ionInfo per TLS hardcoded.

3. Nel codice nativo impostare tutte le assegnazioni diverse da zero di grbitEnabledProtocols su zero. Ciò consente al sistema operativo di usare la versione TLS predefinita.

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

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

   1. App gestite: ricompilare e ridestinare alla versione .NET Framework più recente

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

6. Per individuare tutte le istanze, analizzare il codice sorgente e i file di configurazione dei servizi online per identificare i modelli riportati di seguito corrispondenti ai valori di tipo enumerato usati comunemente in TLS hardcoded:

   1. SecurityProtocolType

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

   3. WINHTTP_FLAG_edizione Standard CURE_PROTOCOL_

   4. SP_PROT_

   5. NSStreamSocketSecurityLevel

   6. PROTOCOL_SSL o PROTOCOL_TLS

La soluzione consigliata in tutti i casi sopra indicati 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 ovviare a 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, in qualsiasi computer che debba eseguire connessioni TLS 1.2 da un'app .NET. In questo modo, .NET userà le versioni TLS con le "impostazioni predefinite del sistema" aggiungendo TLS 1.2 come protocollo disponibile E consentirà agli script di usare le versioni TLS future quando saranno supportate dal sistema operativo. (ad esempio, TLS 1.3)

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

   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 sottostante. 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 di crittografia agile che consente alle app di sfruttare il supporto futuro di TLS 1.3.

Se la destinazione è rappresentata da versioni di .NET Framework precedenti, ad esempio 4.5.2 o 3.5, per impostazione predefinita l'applicazione userà i protocolli precedenti e non consigliati come 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 appropriate del Registro di sistema per UseStrongCrypto.

Test con TLS 1.2+

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

• Il problema più comune in questo test di regressione sarà un errore di negoziazione TLS dovuto a 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 TLS massima supportata di Vista è la 1.0. Tale 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 è meno espressivo di quello per TLS 1.2.

  • Se un prodotto negozia MTLS con un certificato da una posizione non standard (all'esterno degli archivi certificati con nomi standard in Windows), potrebbe essere necessario aggiornare il codice per assicurarsi che il certificato venga acquisito correttamente.

• Le interdipendenze dei servizi devono essere esaminate per identificare le aree problematiche.

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

  • Le applicazioni non Windows o i sistemi operativi server in uso richiedono l'analisi e la conferma che possono supportare TLS 1.2. L'analisi è il modo più semplice per determinarlo.

Un progetto semplice per testare queste modifiche in un servizio online è costituito dalle operazioni seguenti:

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 dei servizi online per identificare TLS hardcoded come descritto in "Ricerca e correzione delle dipendenze di TLS 1.0 nel codice".

3. Aggiornare/ricompilare le applicazioni come richiesto:

   1. App gestite

      1. Ricompilare con la versione .NET Framework più recente.

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

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

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

5. Correggere tutte le istanze rimanenti di hardcoding di TLS man mano che vengono rilevate durante il test. Ridistribuire il software ed eseguire una nuova esecuzione dei test di regressione.

Notifica ai partner dei piani di deprecazione di TLS 1.0

Dopo aver risolto l'hardcoding di TLS e aver completato gli aggiornamenti del sistema operativo/framework di sviluppo, se si sceglie di deprecare TLS 1.0 sarà necessario coordinarsi con clienti e partner:

• Contattare tempestivamente i partner/clienti è essenziale per una corretta implementazione della deprecazione di TLS 1.0. Questa comunicazione dovrebbe avvenire come minimo tramite post di blog, white paper o altri contenuti Web.

• Ogni partner dovrà valutare la propria conformità a TLS 1.2 tramite le iniziative di sistema operativo/analisi del codice/test di regressione descritte nelle sezioni precedenti.

Conclusione

La rimozione delle dipendenze di TLS 1.0 è un problema complicato da affrontare in ambienti end-to-end. Microsoft e i partner del settore stanno intervenendo oggi su questo problema per garantire che l'intero stack di prodotti sia più sicuro per impostazione predefinita, dai componenti del sistema operativo e i framework di sviluppo fino alle applicazioni o ai servizi basati su di essi. Seguendo le indicazioni riportate in questo documento, la propria azienda potrà tracciare la strada giusta e sapere quali sono le sfide da affrontare. Tali indicazione consentiranno inoltre ai clienti di preparasi meglio alla transizione.

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

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

Attenersi alla procedura seguente 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 di TLS indesiderate.

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

3. Disabilitare tutte le suite di crittografia usando gli algoritmi che non sono consentiti dalla pubblicazione FIPS pertinente. Per Server 2016 (presupponendo che siano attive le impostazioni predefinite) questo significa disabilitare la crittografia RC4, PSK e NULL.

Collaboratori/ringraziamenti

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