Devo ignorare l'exploit SSL BEAST e continuare a preferire AES?

Question

Devo ignorare l'exploit SSL BEAST e continuare a preferire AES?

Naviga le tue risposte

#1 da (4 voti)
#2 da (2 voti)
#3 da (2 voti)
#4 da (1 voti)
#5 da (0 voti)

4

A causa dell'exploit di BEAST sembra che tutti stiano dicendo che dovresti smettere di usare AES e usare invece RC4.

Mi chiedo se non sarebbe meglio continuare a utilizzare AES invece per i seguenti motivi:

Per sfruttare BEAST, l'utente malintenzionato deve ottenere che il client esegua il proprio codice javascript. Se possono farlo, hai una vulnerabilità XSS nel tuo sito. Se questo è il caso, non sarebbe molto più semplice semplicemente dirottare la sessione dell'utente o prelevare i dati dalla finestra del browser e inviarli in questo modo invece di provare a utilizzare BEAST?
RC4, che è quello che tutti raccomandano, mi sembra più vulnerabile di AES. È ciò che viene utilizzato in WEP. L'implementazione utilizzata dai browser è più sicura?

Modifica

Ho visto il collegamento nella risposta di Jeff. Per rendere questo exploit funzionante, l'utente malintenzionato deve essere in grado di comunicare al client con il sito per il quale desidera decodificare il traffico. SOP dovrebbe impedire che ciò accada. È possibile utilizzare una vulnerabilità XSS sul sito o una vulnerabilità in un plug-in del browser (come Java, Flash, Silverlight) per bypassare la limitazione SOP. Nel documento usano una vulnerabilità in Java per fare ciò.

In sintesi: SOP dovrebbe proteggerti contro questo, ma potrebbe non farlo. Se hai una vulnerabilità XSS nel tuo sito, questo è l'ultimo dei tuoi problemi.

EDIT 2

La risposta di Thomas si applica qui: Quali codici devo usare nel mio server web dopo aver configurato il mio certificato SSL?

web-application tls beast

posta Sarel Botha 29.09.2011 - 16:54

fonte

5 risposte

Leggi altre domande sui tag web-application tls beast

Quando si memorizzano informazioni di identificazione private in un'applicazione Web, quali sono le migliori pratiche "standard del settore"? [chiuso] Server: perché un dispositivo separato per un firewall, oltre alla riduzione dello spoofing IP o dell'aumento delle prestazioni

score 4 · Answer 1

1) Questo non è sfruttato tramite XSS, ma attraverso un client che visita un sito dannoso. Il sito web mirato non ha bisogno di mostrare alcun difetto. Dettagli: link

2) RC4 in WEP era vulnerabile a causa di un difetto di implementazione. AES in modalità TLS 1.0 / CBC ... esattamente lo stesso tipo di problema. Sono ancora forti algoritmi, hanno appena avuto un errore nel modo in cui sono stati utilizzati.

I browser si stanno adattando inviando pacchetti di un byte all'inizio delle connessioni. Ciò rende il resto pieno di padding casuale e quindi nega la possibilità di utilizzare il testo in chiaro scelto in base all'inizializzazione del CBC.

Dovresti cambiare le cifre? Bene, RC4 sconfigge l'attacco, non presenta una nuova superficie di attacco nota e Google sembra che stia facendo abbastanza bene con esso. Per questi motivi, personalmente la cambierei.

score 2 · Answer 2

Non è davvero una risposta a tutta la tua domanda, ma RC4 non è intrinsecamente insicuro. È stato proprio il modo in cui WEP l'ha usato.

Secondo SecurityNow! episodio 11 :

Steve: Well, and, for example, it uses an extremely good cipher technology called RC4. That's an RSA proprietary cipher which is very good for encrypting as long as you use it correctly. And that's really the key. The foundation of WEP encryption, with this RC4 cipher, is extremely strong. But it was used in a very bad way.

score 2 · Answer 3

Per un'applicazione web, a meno che tu non sappia che i tuoi clienti useranno IE, probabilmente dovresti rimanere fedele a RC4.

Per un'applicazione non web, basta forzare il client a utilizzare TLS 1.1 o 1.2 e il problema scompare.

Esiste una correzione lato client ed è implementata in SChannel (utilizzato da IE), ma solo nella versione di sviluppo di NSS (utilizzata da Firefox e Chrome). Infine, ho sentito che non volevano abilitare la correzione per tutti a causa di problemi durante la connessione ad alcuni server Web meno recenti. L'unica correzione lato server è di evitare tutti i codici a blocchi, il che significa RC4. Che, nonostante sia un codice di flusso vecchio di 25 anni, non ha attacchi dimostrativi contro di esso, come usato in TLS 1.0

score 1 · Answer 4

1

RC4 utilizzato in TLS è sicuro. * -cbc è, nel modo limitato ma non banale, BEAST lo sfrutta, non sicuro.

risposta data 30.09.2011 - 03:38

fonte

score 0 · Answer 5

solo un aggiornamento,

A partire dal 2013, si ipotizza che alcune agenzie crittografiche statali possano possedere la capacità di interrompere RC4 anche se utilizzate nel protocollo TLS. Microsoft consiglia di disabilitare RC4 laddove possibile.

fonte: link

quindi preferisco AES-128