Supponiamo che il seguente proxy TLS esista
User <-----> Load Balancer that decrypts, encrypts <------> WebServer
Dove il server Web esegue una versione vulnerabile di OpenSSL.
L'utente può sfruttare il server Web se è vulnerabile a TLS o Beast, supponendo che il primo collegamento al servizio di bilanciamento del carico sia sicuro?
BEAST è una vulnerabilità sul client , non sul server. Un server non è, e non è mai stato, "vulnerabile a BEAST". C'è una certa confusione sugli strumenti che "testano i server SSL", che possono segnalare una "vulnerabilità BEAST" se il server non riesce a correggere un client vulnerabile - vale a dire, se il client è vulnerabile, e specifica in il suo ClientHello che preferisce usare una suite di cipher con un cifrario a blocchi in modalità CBC, e dice anche che accetta di usare una suite di cifratura non vulnerabile (ad esempio basata su RC4), quindi il server ha la possibilità di salvare il client scegliendo la suite di crittografia non CBC, nonostante le preferenze del client. Quando il server non lo fa, gli strumenti di test SSL segnaleranno "vulnerabile a BEAST", ma la vulnerabilità è ancora sul client, non sul server.
Detto questo, sia BEAST che CRIME si basano su un contesto di utilizzo in cui l'utente malintenzionato può eseguire tutte le seguenti operazioni:
L'utente malintenzionato può scegliere parte dei dati che vengono crittografati, insieme ad alcuni dati segreti a cui l'aggressore è molto interessato (in genere, un cookie HTTP).
L'utente malintenzionato può visualizzare il risultato crittografato.
Le informazioni ottenute dal punto 2 possono essere utilizzate per il punto 1: l'attacco è adattativo .
Nel tuo caso, ciò richiede che l'attaccante possa intercettare le comunicazioni tra il servizio di bilanciamento del carico e il server Web, e possono scegliere i dati che vengono crittografati dal servizio di bilanciamento del carico. Poiché il bilanciamento del carico crittografa i dati appena decrittografati, direttamente dall'utente, si applica il concetto di BEAST e CRIME. Questo è vero indipendentemente dal modo in cui i dati vengono trasmessi dal browser dell'utente al servizio di bilanciamento del carico. Quel TLS specifico protegge i dati in transito tra l'utente e il servizio di bilanciamento del carico, ma l'attacco è in realtà sulla connessione tra il servizio di bilanciamento del carico e il server Web, ad esempio fuori dal campo di applicazione del primo TLS.
Le cose saranno ancora impegnative per l'attaccante, per i seguenti motivi:
Il solito metodo con cui un utente malintenzionato può inserire i suoi dati nel flusso di testo in chiaro e osservare il risultato crittografato è attraverso un falso punto di accesso WiFi. Tuttavia, nella tua situazione, l'autore dell'attacco deve in qualche modo iniettare il suo codice JavaScript malevolo sul lato client (quindi deve essere vicino all'utente, in termini di rete), ma anche osservare le cose sulla rete interna tra il servizio di bilanciamento del carico e il server Web. L'autore dell'attacco deve trovarsi in due posti contemporaneamente.
BEAST non funziona più. Per applicare l'attacco, l'attaccante deve avere un controllo piuttosto fine sui byte che aggiunge al flusso di testo in chiaro; le semplici intestazioni HTTP non sono sufficienti. Si noti che stiamo parlando del codice dannoso eseguito sul client, ad esempio nel contesto del browser dell'utente. Gli autori di BEAST avevano trovato due modi per spingere i loro byte nello stream, usando un buco Java, o una bozza di implementazione di WebSockets. Entrambi i fori sono stati corretti nei browser per diversi anni.
Anche se BEAST funzionasse ancora, potrebbe ancora avere problemi a superare il load balancer: la regolazione fine dell'input addizionale dell'attaccante non è compatibile con la richiesta HTTP; le cose devono essere un po 'più di basso livello.
CRIME funzionerà bene, però.
Leggi altre domande sui tag network threat-mitigation crime beast