Vulnerabilità SSL/TLS: come risolvere il problema?

Nei giorni scorsi due ricercatori, esperti in tematiche connesse alla sicurezza informatica, Juliano Rizzo e Thai Duong, avevano anticipato l’individuazione di una nuova modalità d’attacco nei confronti del protocollo SSL/TLS, utilizzato per cifrare i dati in transito tra sorgente e destinazione in un canale intrinsecamente insicuro qual è la rete Internet. Lo strumento ideato, battezzato “BEAST” (Browser Exploit Against SSL/TLS; ved. questo nostro articolo) avrebbe consentito, al duo Rizzo-Duong, di decifrare un cookie PayPal in meno di dieci minuti di lavoro.

Per far fronte alla nuova minaccia, altri specialisti hanno suggerito l’impiego dell’algoritmo RC4. Esso infatti, diversamente rispetto ad AES, che risulterebe oggi impiegato nella maggior parte dei server, non utilizza la cosiddetta modalità “Cipher Block Chaining” (CBC). Tale tecnica prevede che uno stesso blocco di dati in chiaro, se ripetuto, possa produrre blocchi di testo cifrato differenti. Implementazioni di CBC esistono in tutte le versioni di SSL/TLS sino a SSL 3.0/TLS 1.0.

Al centro del problema vi sono i vettori di inizializzazione che non vengono generati casualmente per ciascun blocco (tali vettori, come anticipato, dovrebbero assicurare che blocchi di testo identifici non generino lo stesso testo cifrato). I cookie trasmessi in forma crittografata, quindi, possono essere decifrati piuttosto velocemente andando per tentativi piuttosto che con un tradizionale attacco brute force. Affinché l’aggressione vada in porto, comunque, è necessario un attacco del tipo man-in-the-middle (MitM) che permetta di intercettare la comunicazione tra server e vittima nonché di inviare delle informazioni al server facendo le veci del client legittimo.

Adam Langley, analista di Google, ha rivelato qualche dettaglio in più sull’attacco proposto da Rizzo e Duong: parte dell’attacco MitM sarebbe un codice JavaScript che il browser dell’utente dovrebbe mandare in esecuzione. Tale script, caricato ad esempio attraverso una semplice tag IFRAME, invia migliaia di richieste SSL, opportunamente “costruite”, al server provvedendo via a via a valutare le risposte ottenute.

Il problema potrebbe essere risolto passando a TLS 1.1, approvato nel 2006, ma l’operazione appare ai più irta di ostacoli dal momento che non tutti i browser e pochi server, ad oggi, supportano lo standard. Secondo l’analisi pubblicata da Thierry Zoller, Chrome e Firefox supporterebbero solamente TLS 1.0. Allo stesso modo, sistemi operativi quali Windows 2000, Windows XP, Windows Server 2003, Windows Vista e Windows Server 2008 sarebbero incapaci di gestire, di default, TLS 1.1. Opera 10, invece, è in grado di interagire correttamente anche con i server che impiegano TLS 1.2.

Frattanto, comunque, Google ha deciso di applicare una prima patch per “lenire” i rischi (nonostante il codice alla base dell’attacco BEAST non sia stato ancora reso pubblico). L’intervento, applicato sul browser Chrome, trae ispirazione da una modifica proposta nel 2004 dagli sviluppatori di OpenSSL: per rendere gli attacchi più difficoltosa, i pacchetti dati vengono suddivisi con l’aggiunta di un elemento vuoto prima di oggi pacchetto. L’aggiunta di pacchetti vuoti è una sorta di misura difensiva che è stata implementata da OpenSSL per un buon periodo di tempo.