TLS_FALLBACK_SCSV fornisce una protezione globale contro gli attacchi downgrade?

TLS_FALLBACK_SCSV non riesce a proteggere contro Logjam per la stessa ragione per cui Logjam funziona effettivamente. Questo meccanismo anti-fallback si basa sul client che lo inserisce in ClientHello e, in definitiva, fa parte dell'input alla funzione hash che calcola il messaggio finale Finished . Funziona solo fino a quando l'attaccante attivo non può interrompere immediatamente la crittografia della sincronizzazione dell'hachat e correggere in tempo reale il contenuto del messaggio Finished . Ma questo è esattamente ciò che accade con Logjam: l'attaccante modifica il messaggio ClientHello per includere la suite di cifratura RSA di esportazione come parte delle suite client, in modo che il ClientHello che il server riceve non sia ciò che il client invia. Mentre è a questo punto, l'attaccante può anche modificare altre parti del ClientHello e il ServerHello che ritorna come risposta, ad es. per modificare la versione massima pubblicizzata (da TLS 1.2 fino a TLS 1.0) e per rimuovere TLS_FALLBACK_SCSV.

Le cose vanno così:

• Il client invia un ClientHello che dice "TLS 1.2, può usare DHE-RSA, TLS_FALLBACK_SCSV".
• L'attaccante lo cambia in un ClientHello che dice "TLS 1.0, può usare solo DHE-EXPORT-RSA, no TLS_FALLBACK_SCSV".
• Il server risponde con un ServerHello che dice "ok, TLS 1.0, DHE-EXPORT-RSA, nessun fallback".
• L'attaccante lo cambia di nuovo in un ServerHello che dice "ok, TLS 1.2, DHE-RSA, il tuo anti-fallback è stato visto e ben elaborato".
• Server invia i parametri export DH, debitamente firmati, con un modulo a 512 bit. L'utente malintenzionato le lascia fluire come è per il client.
• Il client si aspetta parametri DH "normali", ma sono indistinguibili dai parametri DH "export", tranne per le dimensioni del modulo, e il client è totalmente soddisfatto di fare DH debole se il server sembra voler farlo (apparentemente , alcune versioni di Safari accettano anche di usare un modulo a 16 bit ...).
• L'handshake continua, usando questo modulo a 512 bit che sia il client che il server accettano di utilizzare (anche se uno di loro lo considera come "esportazione" e non l'altro).
• L'aggressore lo interrompe subito (grazie alle sue dimensioni ridotte e al modulo prevedibile) e ottiene così la chiave di sessione utilizzata dal client e dal server.
• Alla fine della stretta di mano, sia il client che il server calcolano i Finished di messaggi che dovrebbero inviare e che dovrebbero ricevere. Hanno visto messaggi distinti di handshake (l'autore dell'attacco ha modificato ClientHello e ServerHello ) ma l'attaccante ha, a quel punto, la crittografia e le chiavi MAC, quindi può decifrare, applicare patch e crittografare nuovamente i messaggi Finished a volontà di mantenere l'illusione.

Riepilogo: TLS_FALLBACK_SCSV è un meccanismo "anti-downgrade", ma copre solo la versione del protocollo e, cosa più importante, funziona solo fino a quando l'handshake downgraded è ancora resiliente alla rottura immediata e totale. Questo andava bene per POODLE, dove l'attacco si verifica solo dopo l'handshake, quando vengono inviati messaggi crittografati. Ma non per Logjam.

Come per FREAK, è più o meno lo stesso, tranne che si basa su un ulteriore bug nell'implementazione del client: il client deve accettare di utilizzare una chiave temporanea inviata dal server anche se, dal punto di vista del client , nessuna chiave di questo tipo deve essere inviata poiché il client non ha richiesto una suite di crittografia RSA di esportazione (non esiste una suite di crittografia RSA non di esportazione in SSL / TLS che utilizza ancora una coppia di chiavi RSA effimera).

Mentre è allettante affermare che il problema è un "difetto di protocollo" e risiede nel fatto che i parametri di esportazione DH non sono distinguibili dai parametri DH di non esportazione (questo è il punto di vista degli autori degli attacchi di Logjam), la mia analisi è che il vero problema è che il client e il server accettano entrambi di utilizzare il debole crypto - il server supportando volutamente DHE-export, il client accettando di fare un po 'di DH con un modulo troppo breve.

Credo che il tuo ragionamento sia solido, è solo imperfetto

come sottolineato da @SOJPM:

I think SCSV prevents Protocol downgrade attacks (f. ex. TLS -> SSL) whereas FREAK and Logjam attack weak cipher suites. – SOJPM

Quindi TLS_FALLBACK_SCSV protegge il protocollo utilizzato non la suite di crittografia.

Devi disabilitare cifre di esportazione, SSL, RC4, ecc ... a causa del semplice fatto che i tuoi altri modi si basano su una corretta implementazione su client e server di funzionalità di sicurezza come il meccanismo TLS_FALLBACK_SCSV . e altre attenuazioni. Anche 1 di queste macchine è fuori dal tuo controllo, non devi dipendere dal fatto che sia corretto o corretto.

Anche la disabilitazione fa parte della sicurezza in profondità (consentendo solo un insieme selezionato di cifrari apposti a una grande lista) e l'ottimizzazione della crittografia. (un set limitato è più facile da ottimizzare per un server di un grande set, dal momento che ogni cifratura ha bisogno del proprio set di memoria.

No.
TLS_FALLBACK_SCSV non funzionerà per questo. È solo il cliente che dice "Guarda, mi hai fatto tornare una seconda volta e con una versione ridotta del protocollo!"

Ma Logjam o FREAK non dipendono da una seconda connessione. Funziona con la prima connessione. Il downgrade non è a livello di protocollo. È nei parametri che vengono consegnati.