Come si confronta DHE-RSA-AES256-SHA con RC4 come cifrario per SSL?

6

Ho letto un sacco di problemi [1] in cui dichiaro che RC4 è rotto ed è a rischio.

Ho appena controllato il mio server web (nginx) e sta usando le impostazioni predefinite, che è

DHE-RSA-AES256-SHA

Come si confronta questo Cipher con l'RC4?

È più lento (penso di si) Ma è più sicuro?

[1] link

    
posta Howard 22.03.2013 - 10:27
fonte

1 risposta

6

Crittograficamente "spezzato" e semplicemente "rotto" sono cose diverse, il primo è solitamente inteso come "meno della forza bruta" (che può ancora essere improbabilmente costoso da ottenere).

A parte il fatto che due cifrari, AES e RC4, sono differenti internamente (cifrario a blocchi CBC e cifrario di flusso rispettivamente), le differenze osservabili sono che AES-256 è 256-bit, e non così veloce (come tu correttamente suggerire) come RC4 a 128 bit. La velocità a volte è un motivo citato per Google che lo preferisce . La parte "DHE" significa Diffie-Hellman effimero , che offre PFS , generalmente una buona cosa . Sia AES che RC4 supportano SHA-1 e MD5 per il controllo dell'integrità dei messaggi, il primo è preferito (uno o l'altro deve essere utilizzato, prima di TLSv1.2 che ha aggiunto più algoritmi).

Thomas Pornin riassume perfettamente entrambi i problemi di RC4 e BEAST qui:

La vulnerabilità di RC4 consente di individuare con precisione la maggior parte dei primi 256 byte di una connessione almeno con le condizioni che:

  • il contenuto recuperabile deve essere lo stesso per la durata dell'attacco
  • l'attaccante deve catturare molto di traffico, alcuni 2 24 -2 32 di pacchetti utili (che può distinguere come inizio di una sessione)
  • il contenuto indovinato è ancora utile (ad esempio cookie di sessione HTTP) quando ha terminato
  • la chiave di sessione SSL non viene ripristinata, solo contenuto parziale

Un rapido calcolo del back-of-the-envelope indica se è possibile saturare un collegamento wifi (ad esempio 20Mbps) con il traffico ideale che guarderebbe ~ 2 ore per il primo 3-4 byte recuperati e circa 10 giorni per il ripristino quasi completo dei primi 256 byte. (Questo è solo il factoring in larghezza di banda, i requisiti CPU dell'analisi sono trascurabili.)

Questo problema con RC4 è piuttosto vecchio , è solo la quantificazione dei pregiudizi che è nuovo.

Ho raccomandato i codici AES su RC4 (BEAST è un problema lato client, se l'utente ha ancora un browser vulnerabile in questo momento ci sono probabilmente problemi più grandi da risolvere).

Anche se alcuni di questi problemi sono (IMHO) un po 'esagerati, il miglior risultato è un maggiore progresso verso il supporto uniforme di client e server per TLSv1.1 e versioni successive. Intorno al tempo in cui è stata pubblicata la BESTIA, il supporto era abbastanza povero .

    
risposta data 22.03.2013 - 11:30
fonte

Leggi altre domande sui tag