Come testare l'attacco BEAST se il server non è connesso a Internet?

Ho scritto uno strumento da riga di comando chiamato TestSSLServer che può essere utilizzato per quel lavoro.

Lo strumento fa un sacco di strette di mano interrotte con il server (invia ClientHello e riceve ServerHello, quindi chiude la connessione). Innanzitutto, stabilisce l'elenco delle suite di crittografia supportate dal server, inviando un elenco completo di molte suite, quindi rimuovendo una per una la suite che il server seleziona ogni volta.

Quindi lo strumento invia un altro ClientHello, con la massima TLS versione 1.0 e le suite di crittografia basate su CBC, seguite da quelle non basate su CBC (suite prese tra le suite "forti" supportate dal server). Se il server seleziona una suite di crittografia non basata su CBC, viene considerata "protetta" (il server impone una scelta che protegge il client); se seleziona una suite di crittografia CBC, lo strumento segnala "vulnerabili" (anche in questo caso, la vulnerabilità è sul lato client, ma il server non riesce ad applicare la protezione sul client).

Sfondo. Per ulteriori informazioni su come mitigare l'attacco BEAST, ti consiglio di leggere i seguenti due post del blog: Rizzo/Duong contromisure BEAST e Mitigazione dell'attacco BEAST su TLS . Scoprirai presto che non esistono soluzioni davvero eccezionali.

Cosa cercare. In questo momento, l'unica mitigazione sul lato server nota è che il server imponga l'uso di RC4 rifiutando di accettare qualsiasi altra ciphersuite. Una variazione simile è quella di posizionare RC4 ciphersuite come la massima preferenza; questo è quasi sicuro, in quanto garantisce che qualsiasi client che supporta RC4 utilizzerà RC4.

Pertanto, quando si esegue la scansione di un server SSL, se il server assegna la priorità a qualsiasi cifratura superiore basata su crittografia a blocchi delle cifrarie RC4, può essere considerato vulnerabile all'attacco BEAST. Se tutte le cipassute che accetta usano RC4 (o se le cipheruites RC4 hanno la priorità prima di qualsiasi cifratura del codice a blocchi, eccetto per le cipherità TLS 1.2-only), probabilmente è al sicuro dall'attacco BEAST.

Determinare le priorità del server sulle cipheresi può essere complicato e può richiedere più connessioni al server con un insieme diverso di cipheresi ogni volta. Tuttavia, in questo caso, un metodo semplice potrebbe essere quello di collegare il client a un elenco di cipheresi che inizia con tutte le suite di codici a blocchi (non solo TLS-1.2) e quindi terminare con alcune cipherità RC4. Se il server sceglie una crittografia cifrata a blocchi, il server è probabilmente vulnerabile all'attacco BEAST.

Idealmente, il server supporterà TLS 1.1 o superiore. Se sia il client che il server supportano TLS 1.1, l'attacco BEAST diventa molto più difficile (richiede un attacco man-in-the-middle). Pertanto, se il server non supporta TLS 1.1, è possibile che venga emesso un avviso / avviso che suggerisce che l'aggiornamento dell'amministratore del server fornisca il supporto per TLS 1.1. Tuttavia, apparentemente supportare TLS 1.1 su entrambi gli endpoint non è una garanzia assoluta di sicurezza, a causa della possibilità di attacchi downgrade se è presente un man-in-the-middle, quindi suggerirei di elencarlo semplicemente come un avviso / avviso, piuttosto di un errore critico.

Ulteriori informazioni sulla scansione del server SSL. Potresti prendere in considerazione l'utilizzo del servizio SSL Labs per la scansione di un Server SSL È un ottimo modo per testare molte possibili vulnerabilità di configurazione. Verificherà anche se il server è vulnerabile all'attacco di BEAST, ma controllerà anche molti altri problemi comuni e seri, il che è probabilmente più utile del semplice problema BEAST.

questo si basa solo su alcune ricerche online, senza anlaisi dettagliata, ma da quello che raccolgo, è più una vulnerabilità lato client che una server. Naturalmente la vulnerabilità è quando la comunicazione tra client e server viene attaccata, ma la correzione dovrebbe essere principalmente sul client . Il motivo principale, a quanto ho capito, è perché il client seleziona i suoi cifrari preferiti e invia una lista ordinata al server da cui "scegliere". Il server dovrebbe generalmente accettare la richiesta del cliente (ma non deve). Questa è la mia comprensione limitata dell'handshake da questa risposta SO

Con questo in mente, ci sono alcuni workaround del server che sembrano essere efficaci. Uno dei quali è quello di evitare cifrari a blocchi che usano CBC, e ad es. utilizzare RC4 come alternativa. Questo può essere applicato dal server. Ovviamente l'utilizzo di TLS 1.1+ risolverà anche il problema, ma da quello che ho capito non è ampiamente supportato. Secondo l'articolo di wikipedia su RC4

RC4, being a stream cipher, is the only common cipher which is immune[6] to the 2011 BEAST attack

( [6] collegamento a serverfault:)

Per tornare alle specifiche della tua domanda. Immagino che la cosa logica sia controllare quali crittografie il server supporta e se supporta TLS 1.0 + uno dei cifrari a blocchi con CBC che sono vulnerabili a BEAST, si potrebbe dire che il server è vulnerabile a BEAST. Sembra che potrebbe essere più facile usare sslscan piuttosto che openssl per elencare tutte le crittografie supportate dal server e da questo scoprire i server vulnerabili.