Quanto è sicuro HTTPS con crittografie deboli?

RC4 ora non è considerato sicuro, ci sono documenti che vietano esplicitamente il suo utilizzo in TLS: RFC7465 .

Dovresti non utilizzare RC4 al momento.

post aggiornato come informazioni obsolete su crypto è pericoloso

Informazioni obsolete, pubblicate nel 2012:

RC4 è sicuro, infatti, se non stai usando TLS 1.2, dovresti usare RC4 per proteggerti da BEAST.

MD5 non è sicuro, ma se è usato come funzione MAC non è ancora rotto

A loro merito, se hai disabilitato l'hash MD5, negozierà con SHA-1, infatti, se disabiliti RC4 negozierà AES: link

I punti deboli noti di RC4, in questo momento (marzo 2013), sono i bias statistici:

• I primi byte dello stream, in particolare il secondo byte, sono piuttosto distorti, il che significa che se un utente malintenzionato osserva molte sessioni SSL, potrebbe fare una buona ipotesi su quale sia il secondo byte inviato dal client o il server potrebbe essere (all'inizio della sessione). Ma questo non gli insegnerà molto: l'attaccante già sa che il secondo byte inviato dal client è una 'E' (per una richiesta HTTP 'GET') e il secondo byte inviato dal server è una 'T' (per una risposta HTTP, che inizia sempre con 'HTTP').

• Altri pregiudizi riguardano coppie di byte meno probabili di quanto dovrebbero. Il bias può essere esibito dopo aver osservato un gigabyte di uscita RC4. Ma osservare un pregiudizio in condizioni di laboratorio e dedurre qualcosa sui dati crittografati, sono due cose diverse. Non c'è modo conosciuto per trasformare questo bias di RC4 in un vero attacco a SSL (lo scenario più plausibile che ho sentito riguarda l'osservazione di alcuni miliardi di connessioni che contengono tutti gli stessi dati segreti, ad esempio un cookie o una password, in modo affidabile luogo prevedibile - ci vorrebbero solo poche migliaia di anni di intercettazioni dei pazienti).

I punti deboli noti di MD5, al momento (marzo 2013), sono:

• Non resistenza alle collisioni (dall'attacco di Wang nel 2004).
• La debolezza teorica rispetto alle pre-immagini (ma con un costo di oltre 2 ¹²³ , è piuttosto lontana nel regno della "sola teoria").

Nessuno dei due influenza direttamente MD5 se utilizzato in SSL. Infatti, SSL utilizza MD5 come parte di HMAC , che ha una "prova di sicurezza" che mette in relazione la sua sicurezza con la compressione la funzione utilizzata in MD5 è indistinguibile da un PRF . È noto che la funzione di compressione di MD5 è non un PRF; è noto dal 1996 e il lavoro di Dobbertin su quella funzione di compressione. Ciò rende la prova di sicurezza HMAC "inapplicabile". Ma questo HMAC / MD5 non ha dimostrato di essere sicuro, non significa che sia dimostrato di essere insicuro. Attualmente non è noto alcun attacco effettivo su HMAC / MD5. Corrispondentemente, il suo uso in SSL è ancora "sicuro".

Ciò è corroborato dalla situazione di MD4 , un predecessore di MD5. MD4 è molto rotto per quanto riguarda le collisioni, molto più di MD5 (ci vogliono ancora alcuni secondi per creare collisioni MD5, mentre la stessa macchina costruisce milioni di MD4 collisioni al secondo). È anche noto un attacco preimage su MD4, ma solo teorico (costo in 2 ¹⁰² ). HMAC / MD4 ha un attacco "quasi pratico", che porta a falsi in 2 ⁵⁸ query (devi convincere il client o il server SSL attaccato a calcolare molti record SSL all'interno la stessa sessione, sui dati che l'hacker sceglie, prima di produrre un falso record). Ciò significa che se SSL stava usando MD4 invece di MD5, sarebbe ancora "praticamente sicuro" in questo momento, e avremmo solo "bandiere di avvertimento avanzate" sulla necessità di migrare a qualcosa di meglio. MD5 è, su tutti i punti, più robusto di MD4, quindi non c'è bisogno di andare in panico.

E, naturalmente, nulla di tutto questo è legato al certificato . Se il server vorrà usare RC4 o AES o MD5 o SHA-256 è non scritto nel certificato, e completamente fuori dalla portata di qualunque cosa Verisign voglia fare. Il lavoro del certificato termina con la chiave pubblica del server e non copre ciò che il server fa con quella chiave pubblica, per non parlare di ciò che il server fa con qualsiasi chiave di sessione che è stata scambiata usando la chiave pubblica. p>     

Non ci sono attacchi noti su questo ciphersuite. Non lo definirei "debole". Scegliere questa ciphersuite non è quello che definirei best practice, ma se qualcun altro ha fatto la scelta per te e sei bloccato ad usarlo, probabilmente starai bene. È improbabile che sia l'anello più debole del tuo sistema.