6. Security Considerations (Considerazioni sulla sicurezza)

6.1. Triple Handshake Preconditions and Impact (Prerequisiti e impatto del Triple Handshake)

Un modo per sferrare un attacco triple handshake è descritto nella Section 1, insieme a una menzione dei meccanismi di sicurezza che si rompono a causa dell'attacco; discussioni più approfondite e diagrammi possono essere trovati in [TRIPLE-HS]. Qui, viene presentata un'ulteriore discussione sui prerequisiti e l'impatto dell'attacco.

Per sferrare un attacco triple handshake, deve essere possibile forzare lo stesso segreto principale su due sessioni diverse. Affinché ciò accada, devono essere soddisfatti due prerequisiti:

Il client, C, deve essere disposto a connettersi a un server dannoso, A. In certi contesti, come il web, questo può essere facilmente ottenuto, poiché un browser può essere istruito a caricare contenuti da un'origine non attendibile.
Il segreto pre-principale deve essere sincronizzato sulle due sessioni. Questo è particolarmente facile da ottenere con gli scambi di chiavi RSA e DHE, ma in alcune condizioni, anche gli scambi di chiavi ECDHE, SRP e PSK possono essere sfruttati a questo effetto.

Una volta che il segreto principale è sincronizzato su due sessioni, qualsiasi proprietà di sicurezza che si basa sull'unicità del segreto principale è compromessa. Ad esempio, un esportatore TLS [RFC5705] non fornisce più una chiave unica legata alla sessione corrente.

Anche la ripresa della sessione TLS si basa sull'unicità del segreto principale per autenticare i peer che riprendono. Quindi, se una sessione sincronizzata viene ripresa, i peer non possono essere sicuri delle identità reciproche e l'attaccante conosce le chiavi di connessione. Chiaramente, un prerequisito per questo passaggio dell'attacco è che sia il client che il server supportino la ripresa della sessione (tramite identificatore di sessione o ticket di sessione [RFC5077]).

Inoltre, in un handshake abbreviato sincronizzato, l'intera trascrizione (che include i valori verify_data) è sincronizzata. Quindi, dopo un handshake abbreviato, i channel binding come "tls-unique" [RFC5929] non identificheranno più univocamente la connessione.

La sincronizzazione dei verify_data negli handshake abbreviati mina anche le garanzie di sicurezza dell'estensione dell'indicazione di rinegoziazione [RFC5746], riabilitando un difetto di iniezione di prefisso simile all'attacco di rinegoziazione [Ray09]. Tuttavia, in un attacco triple handshake, il client vede il certificato del server cambiare attraverso diversi handshake completi. Quindi, un prerequisito per sferrare questa fase dell'attacco è che il client accetti certificati diversi a ogni handshake, anche se i loro nomi comuni non corrispondono. Prima che l'attacco triple handshake fosse scoperto, questo era un comportamento diffuso, almeno tra alcuni browser web; tali browser erano quindi vulnerabili all'attacco.

L'estensione del segreto principale esteso sventa gli attacchi triple handshake alla loro prima fase assicurando che sessioni diverse finiscano necessariamente con valori di segreto principale diversi. Quindi, ci si aspetta ora che tutte le proprietà di sicurezza che si basano sull'unicità del segreto principale reggano. In particolare, se una sessione TLS è protetta dall'estensione del segreto principale esteso, è sicuro riprenderla, utilizzare i suoi channel binding e consentire modifiche al certificato durante la rinegoziazione, il che significa che tutti i certificati sono controllati dallo stesso peer. Un'analisi simbolica del protocollo crittografico che giustifica l'estensione del segreto principale esteso appare in [VERIFIED-BINDINGS].

6.2. Cryptographic Properties of the Hash Function (Proprietà crittografiche della funzione hash)

Gli hash di sessione di due sessioni diverse devono essere distinti; quindi, la funzione Hash utilizzata per calcolare il session_hash deve essere resistente alle collisioni. Come tale, le funzioni hash come MD5 o SHA1 NON SONO RACCOMANDATE.

Osserviamo che la funzione Hash utilizzata nel calcolo del messaggio Finished deve già essere resistente alle collisioni affinché l'estensione dell'indicazione di rinegoziazione [RFC5746] funzioni, perché una collisione significativa sui messaggi di handshake (e quindi sui verify_data) potrebbe riabilitare l'attacco di rinegoziazione [Ray09].

La funzione hash utilizzata per calcolare l'hash di sessione dipende dalla versione del protocollo TLS. Tutte le attuali suite di cifratura definite per TLS 1.2 utilizzano SHA256 o superiore, e così fa l'hash di sessione. Per le versioni precedenti del protocollo, si può assumere che solo MD5 e SHA1 siano supportati, e questo documento non richiede alle implementazioni legacy di aggiungere il supporto per nuove funzioni hash. In queste versioni, l'hash di sessione utilizza la concatenazione di MD5 e SHA1, come nel messaggio Finished.

6.3. Handshake Messages Included in the Session Hash (Messaggi di handshake inclusi nell'hash di sessione)

Il session_hash è inteso per comprendere tutte le informazioni di sessione rilevanti, inclusa la negoziazione della suite di cifratura, i messaggi di scambio di chiavi e le identità di client e server. L'hash è necessario per calcolare il segreto principale esteso e quindi deve essere disponibile prima dei messaggi Finished.

Questo documento imposta il session_hash per coprire tutti i messaggi di handshake fino al ClientKeyExchange incluso. Per le suite di cifratura TLS esistenti, questi messaggi includono tutti i contenuti significativi della nuova sessione -- CertificateVerify non modifica il contenuto della sessione. Allo stesso tempo, ciò consente di calcolare il segreto principale esteso immediatamente dopo il segreto pre-principale, in modo che le implementazioni possano distruggere il segreto pre-principale temporaneo dalla memoria il prima possibile.

È possibile che nuove suite di cifratura o estensioni TLS possano includere messaggi aggiuntivi tra ClientKeyExchange e Finished che aggiungono un contesto di sessione importante. In tali casi, alcune delle garanzie di sicurezza di questa specifica potrebbero non essere più applicabili e potrebbero essere possibili nuovi attacchi man-in-the-middle. Ad esempio, se il client e il server supportano l'estensione del ticket di sessione [RFC5077], l'hash di sessione non copre il nuovo ticket di sessione inviato dal server. Quindi, un man-in-the-middle potrebbe essere in grado di far sì che un client memorizzi un ticket di sessione che non era destinato alla sessione corrente. Gli attacchi basati su questo vettore non sono ancora noti, ma le applicazioni che memorizzano informazioni aggiuntive nei ticket di sessione oltre a quelle coperte nell'hash di sessione richiedono un'attenta analisi.

6.4. No SSL 3.0 Support (Nessun supporto SSL 3.0)

Il protocollo Secure Sockets Layer (SSL) versione 3.0 [RFC6101] è un predecessore del protocollo TLS ed è ugualmente vulnerabile agli attacchi triple handshake, insieme ad altre vulnerabilità derivanti dal suo utilizzo di costruzioni crittografiche obsolete che sono ora considerate deboli. SSL 3.0 è stato deprecato [RFC7568].

La contromisura descritta in questo documento si basa su un'estensione TLS e quindi non può essere utilizzata con SSL 3.0. I client e i server che implementano questo documento DOVREBBERO rifiutare gli handshake SSL 3.0. Se scelgono di supportare SSL 3.0, le sessioni risultanti DEVONO utilizzare il calcolo del segreto principale legacy e si applicano le considerazioni sull'interoperabilità della Section 5.4.