TLS logjam

Un gruppo di ricercatori ha pubblicato l’articolo Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice [PDF] spiegato in termini non accademici in un sito apposito.

La pubblicazione illustra una vulnerabilità del protocollo TLS, utilizzato anche da HTTPS. Il metodo è molto simile a quello utilizzato per FREAK: un attacco di tipo MitM forza la connessione tra client e server ad un livello di sicurezza molto basso e, quindi, decodificabile. Il tutto grazie ad un retaggio della Guerra Fredda.

Quando client e server stabiliscono una connessione sicura attraverso TLS, la prima cosa che devono fare è concordare una chiave di sicurezza con cui cifrare il resto delle comunicazioni, per ovvie ragioni questo scambio (handshake) avviene in chiaro.

Uno dei protocolli più diffusi per realizzare questo scambio è il Diffie-Hellman (DHE) di cui esiste una versione in forward secrecy che utilizza le curve ellittiche (ECDHE). Esiste altresì una versione depotenziata dell’algoritmo DHE (DHE_EXPORT) figlia di regole da Guerra Fredda, che utilizza un metodo di scambio facilmente decifrabile. L’unica differenza tra DHE e DHE_EXPORT è il numero di bit di lunghezza dei parametri: almeno 1024 (consigliati, ma non obbligati, qui sta il punto) nel primo e massimo 512 nel secondo.

Durante l’handshake TLS, in chiaro, il client presenta l’elenco di protocolli supportati, il server ne sceglie uno e lo comunica al client. Da qui in avanti avviene il calcolo della chiave di sessione secondo il protocollo scelto e, quindi, la sessione cifrata vera e propria.

Se un attaccante si frappone nella connessione può forzare l’utilizzo di DHE_EXPORT anziché DHE senza che nessuno se ne accorga. Ecco come.

1. Il client invia l’elenco dei protocolli supportati, tra cui anche DHE, ma non include DHE_EXPORT.
2. L’attaccante modifica la richiesta in modo tale che DHE_EXPORT sia il protocollo migliore tra quelli forniti (in sostanza elimina DHE, ECDHE e similari) e la invia al server impersonando il client.
3. Il server, suo malgrado sceglie DHE_EXPORT e comunica la decisione al client.
4. L’attaccante modifica la risposta, al posto di DHE_EXPORT scrive DHE e la invia al client impersonando il server.
5. Il client crede che il server abbia scelto DHE.
6. Il server spedisce al client un parametro Diffie-Hellman a 512 bit aderente alle restrizioni di DHE_EXPORT.
7. Il client presume che il server sia così limitato da supportare connessioni DHE a 512 bit e accetta la chiave perché il protocollo TLS ammette parametri a 512 bit per DHE.
8. L’handshake continua con un livello di sicurezza tale da poter essere facilmente decifrato da terzi.

Il dettaglio della connessione e di come viene modificata è illustrato in un’immagina in cima alla pagina 4 della pubblicazione citata in apertura.

Perché l’attacco funzioni entrambe le parti devono essere vulnerabili.

In questo momento l’unica difesa che può mettere in atto il client è rifiutare arbitrariamente parametri DHE inferiori ad una certa dimensione, ma è una decisione arbitraria non prevista dal protocollo TLS.

Vale la pena di riportare anche qui la chiosa dell’articolo del prof. Matthew Green che spiega FREAK:

Export controls might have made some sense in the days when ‘encryption’ meant big clunky pieces of hardware, but it was nonsensical in a world of software. Non-U.S. users could easily skirt the paltry IP-address checks to download strong versions of browsers such as Netscape, and — when that was too much trouble — they could easily re-implement the crypto themselves or use foreign open source libraries. (The requirements became so absurd that mainstream U.S. companies like RSA Security wound up hiring foreign developers to build their encryption libraries, since it was easier to import strong encryption than to export it.)