Quale versione del protocollo SSL/TLS sarebbe meglio usare?

Versioni protocollo SSL / TLS

Le librerie SSL / TLS e le applicazioni che le utilizzano consentono all’amministratore di limitare le versioni di SSL / TLS consentite, solitamente come parte della configurazione di protezione avanzata. Cinque versioni di SSL / TLS sono ampiamente supportate nel codice della libreria: SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 e TLS 1.2. Tutte queste versioni sono interessate da almeno un problema di sicurezza che richiede una soluzione alternativa o una configurazione speciale da evitare e le prime due contengono gravi difetti che non possono essere risolti senza compromettere la compatibilità. Descriviamo brevemente la cronologia delle diverse versioni di SSL / TLS e mostriamo come ognuno di essi può o non può essere utilizzato in modo sicuro oggi se configurato correttamente.

Protocollo 	Azione
SSL 2.0 	disattivare
SSL 3.0 	disattivare
TLS 1.0 	Disabilita quando possibile
TLS 1.1 	Abilitare
TLS 1.2 	Abilitare

Configurazione consigliata per ciascuna versione di SSL / TLS.

SSL 2.0 è stato rilasciato nel 1995. Contiene numerosi difetti di progettazione che non possono essere risolti senza rompere il protocollo e potrebbero portare all’esposizione o alla modifica di dati riservati. SSL 2.0 non dovrebbe mai essere usato su Internet moderno. Quando viene rilevato oggi, SSL 2.0 è solitamente abilitato in seguito a un incidente o a una configurazione predefinita debole.

Risultato: disabilitare SSL 2.0 senza tener conto della compatibilità con le versioni precedenti.

SSL 3.0 è stato rilasciato nel 1996 come re-design completo. L’ attacco POODLE di Google sfrutta le funzionalità di scripting del browser e l’implementazione del padding non funzionante in SSL 3.0 per lanciare attacchi man-in-the-middle, che potrebbero portare all’esposizione o alla modifica di dati riservati [2] . Due soluzioni alternative potrebbero consentire a SSL 3.0 di rimanere in uso durante la risoluzione di POODLE:

Disabilitare tutte le suite di crittografia in modalità CBC quando comunicano con un client SSL 3.0; i codici di flusso non usano il padding e quindi non sono vulnerabili. Sfortunatamente, l’unico cifrario non CBC ampiamente supportato, RC4, è suscettibile di ulteriori problemi di sicurezza.
Una nuova suite di pseudo-cipher recentemente aggiunta a TLS, TLS_FALLBACK_SCSV , aiuta a rilevare gli attacchi di downgrade per resistere ai tentativi di un utente malintenzionato di obbligare una vittima a eseguire il downgrade a SSL 3.0 [3] . Al momento della stesura di questo documento (inizio 2015), TLS_FALLBACK_SCSV non è ancora supportato universalmente e i client che lo supportano sono comunque in grado di supportare TLS 1.0.

Per i motivi indicati, si consiglia di disabilitare SSL 3.0 anziché fare affidamento su una di queste soluzioni alternative.

Fino al 2014 molti server pubblici continuavano a supportare SSL 3.0 per compatibilità con le versioni precedenti, nonostante la sua sostituzione da parte di TLS quindici anni prima. Questo trade-off è ora inaccettabile alla luce della vulnerabilità irreversibile di POODLE. La disabilitazione di SSL 3.0 garantisce che il software non possa essere configurato in modo errato per utilizzarlo e che gli autori di attacchi non possano forzare il downgrade di un client e di un server.

Risultato: disabilitare SSL 3.0 senza tenere conto della compatibilità con le versioni precedenti.

TLS 1.0 è stato rilasciato nel 1999 come revisione di SSL 3.0. Tra le modifiche al protocollo c’era un nuovo schema di riempimento e, di conseguenza, TLS 1.0 non è vulnerabile all’attacco di POODLE quando il padding TLS è in uso.

Tuttavia, TLS 1.0 è vulnerabile all’attacco BEAST , che sfrutta le capacità e i punti deboli di scripting del browser nell’utilizzo dei vettori di inizializzazione utilizzati durante la crittografia con un codice a blocchi in modalità CBC [4] . BEAST può essere risolto senza interrompere il protocollo TLS 1.0 in due modi:

Disabilitare tutte le suite di crittografia in modalità CBC; i codici stream non sono vulnerabili. Sfortunatamente, l’unico cifrario non CBC ampiamente supportato, RC4, è suscettibile di ulteriori problemi di sicurezza.
Modificare le librerie client e server TLS per aggiungere un “tocco” al modo in cui il software comunica, chiamato “insert empty fragments”.

Se TLS 1.0 deve essere supportato, si consiglia di verificare che sia il client che il server seguano la soluzione alternativa di “inserimento di frammenti vuoti” anziché passare a RC4.

Molti server continuano a supportare TLS 1.0 per la compatibilità con le versioni precedenti, in quanto alcuni software ampiamente distribuiti non supportano versioni successive di TLS (ad esempio, Windows XP, Windows Server 2003, OpenSSL 0.9.8), mentre altri software, incluso Mozilla Firefox, non implementare TLS 1.1 fino a molti anni dopo la sua introduzione nel 2006. Gli utenti di TLS 1.0 che desiderano utilizzare soluzioni alternative anziché interrompere il supporto devono essere diligenti nel garantire che le loro librerie TLS siano aggiornate e configurate correttamente. Consigliamo agli utenti di eseguire l’aggiornamento, a meno che uno specifico problema di compatibilità con le versioni precedenti non precluda la disabilitazione di TLS 1.0.

Risultato: disabilitare TLS 1.0; riattivare in caso di problemi di compatibilità con le versioni precedenti.

TLS 1.1 è stato rilasciato nel 2006 come revisione di TLS 1.0. Tra le modifiche al protocollo c’è un nuovo schema di generazione di IV; quindi, TLS 1.1 non è suscettibile a BEAST.

Mentre gli attacchi sono stati lanciati con successo contro specifiche funzionalità di TLS 1.1, come compressione (CRIME) e rinegoziazione, esistono soluzioni alternative che non interrompono la compatibilità del protocollo. Nota: questi problemi influenzano anche TLS 1.2.

Gli utenti di TLS 1.1 dovrebbero essere diligenti nell’assicurare che le loro librerie TLS siano aggiornate e configurate correttamente per abilitare i workaround di sicurezza in base alle migliori pratiche attuali (ad esempio, disabilitando la compressione e abilitando la soluzione alternativa per la rinegoziazione di RFC 5746).

Risultato: abilita TLS 1.1.

TLS 1.2 è stato rilasciato nel 2008 come revisione di TLS 1.1. Al momento, non è necessario eseguire l’aggiornamento da TLS 1.1 a 1.2 in risposta a eventuali vulnerabilità conosciute e sfruttabili, ma TLS 1.2 introduce funzionalità utili quali suite di crittografia GCM a prestazioni più elevate e una funzione pseudocasuale basata su SHA-256. Le suite di crittografia GCM utilizzano anche la crittografia autenticata, in sostituzione del tradizionale schema Encrypt-then-Authenticate di TLS.

Gli utenti di TLS 1.2 dovrebbero essere diligenti nel garantire che le loro librerie TLS siano aggiornate e configurate correttamente per abilitare i workaround di sicurezza in base alle migliori pratiche attuali (ad esempio, disabilitando la compressione e abilitando la soluzione alternativa alla rinegoziazione di RFC 5746).

Risultato: abilita TLS 1.2.

Cipher Suites

I protocolli SSL / TLS sono stati progettati per essere estensibili e modulari, consentendo di modificare i protocolli di autenticazione server / client, scambio di chiavi, crittografia e integrità dei messaggi (MAC) senza sostituire l’intero protocollo. Le suite di crittografia più recenti utilizzano RSA, ECDH o ECDSA per l’autenticazione, ECDHE per lo scambio delle chiavi, AES per la crittografia e GCM per l’integrità, ma esiste anche un gran numero di suite di crittografia compatibili con precedenti e versioni precedenti. Abbiamo suddiviso le suite di crittografia in tre categorie: quelle che dovrebbero essere sempre abilitate per la massima sicurezza possibile, quelle che possono essere attivate se lo si desidera per la compatibilità e quelle che dovrebbero essere sempre disabilitate a causa di problemi di sicurezza.

Suite Cipher consigliate

Gli amministratori dovrebbero essere sicuri di abilitare le seguenti suite di crittografia.

Suite di crittografia ECDH / DH AES. Queste n

uove suite di crittografia utilizzano Elliptic-Curve Diffie Hellman (ECDH) e Diffie-Hellman (DH) per lo scambio di chiavi. A differenza delle vecchie suite di crittografia che utilizzano RSA statico basato sulla chiave pubblica del server per questo scopo, il traffico ECDH / DH catturato passivamente non può essere decifrato, anche se la chiave privata del server viene compromessa in seguito. Questa funzione è nota come segretezza in avanti .

Suite di crittografia AES. Le semplici suite di crittografia AES vengono utilizzate dai client che non supportano le suite di crittografia ECDH / DH o che sono disabilitate.

Un modo rapido per specificare solo le suite di crittografia basate su AES mentre richiede i certificati RSA, ECDH o ECDSA per l’autenticazione del server, quando si utilizza OpenSSL, è: AES+aRSA:AES+aECDH:AES+aECDSA . I moderni processori x86 supportano la crittografia AES e AES / GCM con accelerazione hardware. Questa funzionalità consente alle suite di crittografia AES di offrire sia prestazioni elevate che una solida sicurezza.

Suite di crittografia facoltative o non comuni

Le librerie SSL / TLS supportano comunemente molti altri cifrari e schemi di autenticazione, come le suite di crittografia Camellia, Triple-DES e SEED; e Kerberos, chiave già condivisa e schemi di autenticazione DSS. Mentre al momento attuale, non ci sono attacchi noti contro questi algoritmi, in genere possono essere disabilitati senza alcuna conseguenza di compatibilità. La disattivazione delle funzionalità non necessarie nelle librerie di sicurezza fondamentali aiuta anche a ridurre la superficie di attacco.

Suite Cipher deboli o spezzate

I seguenti tipi di suite di crittografia sono deboli o danneggiati e devono sempre essere disabilitati.

Cifra nullo. Il codice NULL (eNULL) non esegue alcuna crittografia e dovrebbe essere utilizzato solo per il test o il debug.

Esportare cifre di grado. Queste suite di crittografia obsolete sono state utilizzate quando le restrizioni all’esportazione degli Stati Uniti hanno limitato la forza crittografica a 40 bit (oltre 56). La maggior parte delle restrizioni pertinenti sono state revocate nel 2000, quindi non sono necessarie per tutti i software attuali e sono troppo deboli contro gli attacchi di forza bruta.

Cifre anonime Mentre SSL / TLS utilizza quasi sempre certificati per dimostrare l’identità di un server, questo non è richiesto quando si utilizza una suite di crittografia anonima (di solito disabilitata di default a livello di applicazione, ad esempio mod_ssl o IIS).

Suite di crittografia basate su MD5. Molte suite di crittografia meno recenti utilizzavano un algoritmo MAC basato su MD5 per rilevare le modifiche ai dati crittografati. L’algoritmo MD5 ha dimostrato di essere debole e suscettibile alle collisioni; inoltre, alcune suite di crittografia MD5 utilizzano crittografie con punti deboli noti, come RC2, che vengono automaticamente disabilitate evitando MD5.

Suite di crittografia RC4. L’algoritmo di scheduling chiave del cifrario RC4 è debole in quanto i primi byte di output possono essere correlati con la chiave. Questa debolezza è stata utilizzata in alcuni attacchi contro Wired Equivalent Privacy (WEP), il primo standard di crittografia per reti Wi-Fi 802.11, con risultati catastrofici. Sebbene SSL / TLS non sia vulnerabile o sfruttabile con le stesse tecniche del WEP, la debolezza sottostante in RC4 esiste comunque, ei ricercatori di sicurezza di Microsoft e di altre aziende ora raccomandano che sia disabilitato.

Questo consiglio potrebbe sorprendere molti professionisti IT, poiché una delle raccomandazioni immediate alla vulnerabilità di BEAST solo pochi anni fa era quella di disabilitare tutti i cifrari tranne RC4. Tuttavia, le migliori pratiche attuali indicano che RC4 stesso dovrebbe essere disabilitato.

Futuro

TLS 1.3 è, al momento della stesura, attualmente in fase di sviluppo e apporta modifiche sostanziali al protocollo rispetto alle revisioni precedenti; infatti, è la revisione più significativa del protocollo da SSL 3.0. In un’inversione dalla pratica precedente, molte caratteristiche di compatibilità debole o retrocompatibile, come RC4, compressione e autenticazione RSA statica, vengono proposte per essere eliminate da TLS 1.3. Quando viene distribuito TLS 1.3, gli amministratori dovrebbero implementare il supporto quando possibile. In particolare, quando i client e i server migrano a TLS 1.3, non saranno più necessari soluzioni temporanee e hardening.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *