In che modo un utente malintenzionato può eseguire il downgrade / modifica delle suite di crittografia quando sono MAC? (Freak, Logjam usa attacchi di downgrade)

Question

In che modo un utente malintenzionato può eseguire il downgrade / modifica delle suite di crittografia quando sono MAC? (Freak, Logjam usa attacchi di downgrade)

#1 da (2 voti)

1

Nell'handshake di Finished di TLS tutti i messaggi precedenti scambiati vengono inviati dal client al server (e invertiti) e protetti da un MAC. Questo è anche ciò che "impedisce "TLS_FALLBACK_SCSV da essere modificato / eliminato da un utente malintenzionato.

Ma attacchi come Freak e Logjam usano attacchi di downgrade . Per esempio. come spiegato in un blog di Cloudflare :

A MitM attacker intercepts a client connection and replaces all the accepted ciphersuites with only the DHE_EXPORT ones

Quindi, quando l'integrità e l'autenticità di Client hello (e di altri messaggi, ma questo può essere il più importante qui) è protetta, come può essere modificata in attacchi come Freak e Logjam in cui le suite di cifratura dell'esportazione sono forzate?

hmac export tls man-in-the-middle tls-downgrade

posta rugk 21.02.2016 - 12:15

fonte

1 risposta

Leggi altre domande sui tag hmac export tls man-in-the-middle tls-downgrade

ulteriori vantaggi per la sicurezza della rete da doppi hop dmz? Non crittografare il disco rigido, ma rendere impossibile modificare le cose senza una password?

score 2 · Accepted Answer

Dopo aver letto alcuni documenti, posso finalmente rispondere alla mia domanda.

Fondamentalmente ho avuto un malinteso. È importante conoscere il " TLS Record Protocol ". Questo protcol è la base di TLS e viene sempre utilizzato. All'inizio per l'handshake e alla fine quando l'handshake è terminato e i dati vengono trasmessi su TLS (quando si utilizza HTTPS questo è HTTP). (trattodall'articolo Wikipedia tedesco su TLS ; CC-BY-SA 3.0 )

Tuttavia all'inizio non esiste ovviamente alcuna crittografia o HMAC che il client e il server possano utilizzare per proteggere i messaggi scambiati in quanto non hanno ancora concordato di utilizzare un cifrario (ciò è fatto nell'handshake). Quindi devono usare una cifra senza alcuna crittografia e protezione dell'integrità . Questo è TLS_NULL_WITH_NULL_NULL . Dopo che il livello del record è stato inizializzato con questo codice, che fondamentalmente non offre alcuna protezione, l'handshake può iniziare.

Quindi i messaggi di hello di client e server sono quindi non protetti e un utente malintenzionato può manometterli. Per proteggere l'intero processo, i messaggi Finished (che vengono scambiati alla fine dell'handshake) contengono un hash (HMAC) di tutti i precedenti messaggi inviati e pertanto consentono a client e server di verificare l'integrità di questi messaggi.

In SSL 3.0 fino a TLS 1.1 viene utilizzata una combinazione di MD5 e SHA-1. In TLS 1.2 viene utilizzato l'HMAC definito nel codice. Ulteriori dettagli sono spiegato qui . Il problema è che la chiave utilizzata nell'HMAC e nello stesso HMAC può essere debole. Per esempio. l'HMAC potrebbe utilizzare un hash MD5 (come nel attacco SLOTH contro TLS 1.2). Ciò è stato spiegato anche dal scopritore dell'attacco SLOTH (in particolare una diapositiva 8). Concludono:

The TLS downgrade protection mechanism itself depends on downgradeable parameters.
- hence, the only fix is to find and disable all weak parameters: groups, curves, mac algorithms,...

Il modo in cui gli attacchi di downgrade sui cifrari di EXPORT funzionano in dettaglio è spiegato in questa risposta .