1. Introduction (Introduzione)

1. Introduction (Introduzione)

In TLS [RFC5246], ogni sessione ha un master_secret calcolato come:

master_secret = PRF(pre_master_secret, "master secret",
                    ClientHello.random + ServerHello.random)
                    [0..47];

dove il pre_master_secret è il risultato di un protocollo di scambio di chiavi. Ad esempio, quando l'handshake utilizza una suite di cifratura RSA, questo valore viene generato uniformemente a caso dal client, mentre per le suite di cifratura Ephemeral Diffie-Hellman (DHE), è il risultato di un accordo di chiave Diffie-Hellman.

Come descritto in [TRIPLE-HS], sia negli scambi di chiavi RSA che DHE, un attaccante attivo può sincronizzare due sessioni TLS in modo che condividano lo stesso master_secret. Per uno scambio di chiavi RSA in cui il client non è autenticato, ciò si ottiene come segue. Supponiamo che un client C si connetta a un server A. C non si rende conto che A è dannoso e che A si connette in background a un server onesto S e completa entrambi gli handshake. Per semplicità, supponiamo che C e S utilizzino solo suite di cifratura RSA.

1. C invia un ClientHello ad A, e A lo inoltra a S.

2. S invia un ServerHello ad A, e A lo inoltra a C.

3. S invia un Certificate, contenente la sua catena di certificati, ad A. A la sostituisce con la propria catena di certificati e la invia a C.

4. S invia un ServerHelloDone ad A, e A lo inoltra a C.

5. C invia un ClientKeyExchange ad A, che contiene il pre_master_secret, crittografato con la chiave pubblica di A. A decifra il pre_master_secret, lo ricrittografa con la chiave pubblica di S e lo invia a S.

6. C invia un Finished ad A. A calcola un Finished per la sua connessione con S e lo invia a S.

7. S invia un Finished ad A. A calcola un Finished per la sua connessione con C e lo invia a C.

A questo punto, entrambe le connessioni (tra C e A, e tra A e S) hanno nuove sessioni che condividono lo stesso pre_master_secret, ClientHello.random, ServerHello.random, nonché altri parametri di sessione, incluso l'identificatore di sessione e, facoltativamente, il ticket di sessione. Quindi, il valore master_secret sarà uguale per le due sessioni e sarà associato sia in C che in S allo stesso ID di sessione, anche se le identità del server sulle due connessioni sono diverse. Ricordiamo che C vede solo il certificato di A e non è a conoscenza della connessione di A con S. Inoltre, anche le chiavi di record sulle due connessioni saranno le stesse.

Lo scenario sopra mostra che TLS non garantisce che i segreti principali e le chiavi utilizzate su connessioni diverse siano diversi. Anche se viene utilizzata l'autenticazione del client, lo scenario funziona ancora, tranne che le due sessioni ora differiscono sia per le identità del client che del server.

Uno scenario simile può essere ottenuto quando l'handshake utilizza una suite di cifratura DHE. Notare che anche se il client o il server non preferiscono usare RSA o DHE, l'attaccante può costringerli a usarli offrendo solo RSA o DHE nei suoi messaggi hello. Gli handshake che utilizzano suite di cifratura Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) sono anche vulnerabili se consentono curve esplicite arbitrarie o utilizzano curve con piccoli sottogruppi. Contro avversari più potenti, anche altri scambi di chiavi, come Secure Remote Password (SRP) e Pre-Shared Key (PSK), si sono dimostrati vulnerabili [VERIFIED-BINDINGS].

Una volta che A ha sincronizzato le due connessioni, poiché le chiavi sono le stesse sui due lati, può allontanarsi e inoltrare in modo trasparente i messaggi tra C e S, leggendo e modificando quando lo desidera. Nella letteratura sullo scambio di chiavi, tali eventi sono chiamati attacchi unknown key-share, poiché C e S condividono un segreto ma entrambi pensano che il loro segreto sia condiviso solo con A. Di per sé, questi attacchi non violano l'integrità o la riservatezza tra parti oneste, ma offrono un utile punto di partenza da cui sferrare attacchi di impersonificazione su C e S.

Supponiamo che C cerchi di riprendere la sua sessione su una nuova connessione con A. A può quindi riprendere la sua sessione con S su una nuova connessione e inoltrare i messaggi di handshake abbreviati invariati tra C e S. Poiché l'handshake abbreviato si basa solo sul segreto principale per l'autenticazione e non menziona le identità del client o del server, entrambi gli handshake vengono completati con successo, risultando nelle stesse chiavi di sessione e nello stesso registro di handshake. A conosce ancora le chiavi di connessione e può inviare messaggi sia a C che a S.

Criticamente, alla nuova connessione, anche il registro di handshake è lo stesso su C e S, sconfiggendo così qualsiasi schema di protezione man-in-the-middle che si basa sull'unicità dei messaggi finished, come l'estensione dell'indicazione di rinegoziazione sicura [RFC5746] o i channel binding TLS [RFC5929]. [TRIPLE-HS] descrive diversi exploit basati su tali attacchi di sincronizzazione della sessione. In particolare, descrive un attacco man-in-the-middle, chiamato "triple handshake", che aggira le protezioni di [RFC5746] per violare la rinegoziazione TLS autenticata dal client dopo la ripresa della sessione. Attacchi simili si applicano ai meccanismi di autenticazione a livello di applicazione che si basano su channel binding [RFC5929] o su materiale chiave esportato da TLS [RFC5705].

Il problema di protocollo sottostante che porta a questi attacchi è che non è garantito che il segreto principale TLS sia unico tra le sessioni, poiché non è legato contestualmente all'handshake completo che lo ha generato. Se risolviamo questo problema nel calcolo iniziale del segreto principale, allora tutti questi attacchi possono essere prevenuti. Questa specifica introduce un'estensione TLS che modifica il modo in cui viene calcolato il valore master_secret in un handshake completo includendo il registro dei messaggi di handshake, in modo che sessioni diverse abbiano, per costruzione, segreti principali diversi. Ciò impedisce gli attacchi descritti in [TRIPLE-HS] e documentati nella Sezione 2.11 di [RFC7457].