Quanto è protetto l'handshake SSL / TLS dalle modifiche?

Question

Quanto è protetto l'handshake SSL / TLS dalle modifiche?

#1 da (12 voti)

12

L'handshake SSL / TLS è protetto dai tentativi di downgrade del messaggio Finito, di un hash firmato e autenticato del master secret e di tutti i precedenti messaggi di handshake.

Considera un cliente che utilizza un insieme di suite di crittografia forti e deboli che si connette a un server che supporta lo stesso set di crittografie. Di solito, una o entrambe le parti preferiscono una cifratura strong e la connessione verrà stabilita in modo sicuro.

Quali funzionalità avrebbe bisogno di un utente malintenzionato per eseguire attivamente il downgrade dell'handshake su uno dei pacchetti di crittografia deboli? Suppongo che la creazione della chiave principale tramite RSA o (EC) DH non possa essere interrotta dall'attaccante.

Penso che debbano essere in grado di fare almeno quanto segue:

Calcola un valore hash valido per l'handshake modificato (ad esempio con alcune suite di crittografia rimosse o modificate in valori non validi), senza conoscere il master secret e probabilmente anche senza conoscere il valore hash originale (a seconda dello schema di crittografia utilizzato)
Esegui le modifiche dell'hash ai testi cifrati (con testi in chiaro sconosciuti), poiché il messaggio Finito è crittografato
Modifica il tag di autenticazione crittografato per il messaggio Finito (poiché SSL / TLS utilizza l'autenticazione-quindi-crittografia) in modo che sia valido per l'hash dell'handshake modificato, anche in questo caso senza conoscere il valore originale.

"Quanto è rotto" ha una funzione di hash, "quanto malleabile" deve essere un codice per abilitare tale attacco? C'è qualche possibilità oggi o nel prossimo futuro (considerando gli attacchi esistenti su MD5, SHA1, RC4, ecc.) Di un attacco che diventa possibile per una delle suite di cifratura legacy esistenti, ad eccezione forse delle versioni di esportazione dove potrebbe essere la chiave master brute-forzato dall'attaccante?

O è sicuro lasciare le suite di crittografia "moderatamente sicure" abilitate nel client e fare affidamento sulla protezione dell'handshake?

tls man-in-the-middle

posta lxgr 30.10.2014 - 11:36

fonte

1 risposta

Leggi altre domande sui tag tls man-in-the-middle

Configurazione di un server CTF di sicurezza Garantire una previsione su un evento futuro

score 12 · Accepted Answer

In "hash" dei messaggi di handshake, come usato nei messaggi Finished , viene calcolato con PRF , che utilizza il master secret come parametro aggiuntivo (in SSL 3.0 il calcolo è diverso ma il master secret è ancora usato, i valori di 36 byte sono di tipo HMAC con MD5 e SHA-1). Se l'attaccante altera uno dei precedenti messaggi di handshake, deve essere in grado di correggere il primo messaggio Finished di conseguenza. Quel messaggio è il primo che viene crittografato.

La conseguenza è che anche se il sistema di crittografia è terribilmente debole, l'utente malintenzionato deve essere in grado di romperlo senza alcun testo in chiaro noto se vuole semplicemente apprendere il contenuto del messaggio Finished . Questa deve essere una interruzione online , il che significa che qualsiasi errore da parte sua implica l'impossibilità di completare l'handshake. In quanto tale, anche la crittografia a 40 bit sarebbe molto efficace nel contrastare tali attacchi.

Supponiamo tuttavia che, per qualche ragione, il livello di crittografia sia completamente trasparente per l'utente malintenzionato (ad esempio, la suite di crittografia è TLS_RSA_WITH_NULL_SHA , senza alcuna crittografia). Il nostro attaccante deve ancora affrontare due sfide formidabili:

Il MAC è HMAC (o sort-of-HMAC nel caso di SSL 3.0), per il quale non è noto alcun attacco, anche quando si usa MD5 come funzione di base (si veda questo , quindi che ). Per fare una baseline, c'è un noto attacco di contraffazione su HMAC con MD4, ma anche quello è ancora molto costoso e quindi solo teorico.
Lo stesso PRF è basato su un sacco di HMAC, quindi l'attaccante avrà difficoltà a calcolare il suo Finished modificato. I semplici attacchi di falsificazione su HMAC non sarebbero sufficienti; avrebbe dovuto essere in grado di recuperare la chiave (il segreto principale).

In particolare, in TLS, i messaggi Finished hanno lunghezza 12 byte (36 byte per SSL 3.0), mentre il segreto principale ha una lunghezza di 48 byte. Ciò significa che è matematicamente impossibile recuperare il master segreto completo dal primo messaggio Finished , tuttavia il PRF potrebbe essere debole.

Per essere in grado di rompere l'integrità della stretta di mano, dobbiamo assumere un'interazione molto strana del PRF con se stessa, dal momento che il PRF viene utilizzato per calcolare sia la chiave di crittografia che quella MAC applicate al% co_de generato da PRF contenuto. Questo sembra poco plausibile. In alternativa, rompere il meccanismo di scambio delle chiavi stesso. Lo scambio di chiavi (RSA, DH ...) sembra l'unico percorso di attacco non ridicolo (per quanto ne sappiamo).