Perché TLS_FALLBACK_SCSV è sicuro contro un attacco MITM?

Question

Perché TLS_FALLBACK_SCSV è sicuro contro un attacco MITM?

#1 da (16 voti)
#2 da (6 voti)

18

Si raccomanda, per attenuare POODLE, se SSLv3 non può essere disabilitato completamente, per utilizzare TLS_FALLBACK_SCSV, un valore della suite di crittografia di segnalazione che indica che il fallback si è verificato. La bozza dello standard dice:

If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the highest protocol version supported by the server is higher than the version indicated in ClientHello.client_version, the server MUST respond with an inappropriate_fallback alert.

L'idea, a quanto ho capito, è che se il client ha provato e non è riuscito a negoziare una connessione con, ad esempio, TLS 1.2 (probabilmente perché un MITM ha forzato questa situazione in un attacco di downgrade del protocollo), il server sarà in grado di rilevare la situazione perché questo valore di segnalazione sarà presente nell'elenco delle suite di cifratura.

Non ho molta familiarità con la negoziazione TLS e non capisco perché non sia semplicemente possibile per l'utente malintenzionato anche manipolare l'elenco di suite di crittografia per rimuovere questo valore di segnalazione?

Ad esempio, il client tenta di connettersi al server con TLS 1.1, ma Mallory il MITM intercetta e simula un errore. E lo fa di nuovo quando il client tenta di connettersi con TLS 1.0. Quando il client tenta di connettersi con SSL 3.0, Mallory rimuove TLS_FALLBACK_SCSV dalle suite di crittografia e passa la richiesta al server, quindi restituisce la risposta del server, consentendo la negoziazione della connessione senza che il server visualizzi l'indicatore FALLBACK?

Quali caratteristiche di TLS prevengono un simile attacco? L'elenco delle suite di crittografia è crittografato in qualche modo, anche prima che la sessione sia stata negoziata?

tls man-in-the-middle

posta David Conrad 20.10.2014 - 19:57

fonte

2 risposte

6

Sebbene non sia strettamente un duplicato di Come funziona SSL / TLS? , la risposta è lì:

The Finished message is a cryptographic checksum computed over all previous handshake messages (from both the client and server). Since it is emitted after the ChangeCipherSpec, it is also covered by the integrity check and the encryption.

Se modifichi una parte dell'handshake nel mezzo, invalida l'intero handshake e la connessione verrà interrotta.

risposta data 20.10.2014 - 20:02

fonte

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

Richiesta http non significativa È possibile utilizzare i certificati jolly su più dispositivi?

score 16 · Accepted Answer

Alla fine dell'handshake, i messaggi di Finished vengono scambiati, sotto la protezione degli algoritmi e delle chiavi appena negoziati; in particolare, il contenuto di questi messaggi è protetto da un MAC . Il contenuto dei messaggi Finished è un hash di tutti i precedenti messaggi di handshake. Qualsiasi manipolazione esterna del messaggio ClientHello mentre transita da client a server verrà rilevata in quel punto: il client e il server non funzioneranno con gli stessi contenuti ClientHello , quindi non otterranno lo stesso valore hash per i messaggi Finished .

Questo protegge la stretta di mano contro l'alterazione fintanto che qualsiasi modifica eseguita dall'attaccante non gli consente di immediatamente di rompere l'intero livello crittografico. Nel caso del barboncino, anche se l'utente malintenzionato riesce a forzare l'utilizzo di SSL 3.0, non può distruggere immediatamente la crittografia e quindi non può "correggere" i messaggi di Finished .