Recentemente ci siamo chiesti se un'autenticazione SSL reciproca basata su certificati possa proteggere da un attacco di Poodle su SSLv3?
Siamo bloccati in una situazione in cui un'applicazione client supporta solo SSLv3 per ottenere i nostri servizi web basati su SOAP. Ovviamente vogliamo disabilitare SSLv3 sul lato server, ma l'applicazione client non sarà in grado di connettersi.
Quindi, l'uso dell'autenticazione SSL reciproca fornisce una soluzione per evitare un attacco di Poodle?
Strettamente parlando, no, l'autenticazione reciproca non protegge da POODLE. Alcuni dettagli possono avere importanza, però.
Il nucleo dell'attacco di POODLE è che c'è un modo, con SSL 3.0, di alterare alcuni record in modo che il destinatario non noti la sostituzione con probabilità 1/256. Con questa errata funzionalità del protocollo, gli hacker possono "provare" le ipotesi di decrittografia su un singolo byte di dati crittografati e impareranno quel byte con probabilità 1/256. In caso di fallimento, tuttavia, il destinatario riceve correttamente il problema e la connessione viene interrotta. Il punto importante qui è che nulla di tutto ciò è influenzato in alcun modo dai dettagli della stretta di mano; l'autenticazione del client basata su certificato non fa sparire il problema del protocollo.
La classica descrizione basata su Web di POODLE applica quindi quel problema in un contesto Web, cioè:
In questo contesto, POODLE recupera il cookie di destinazione con una media di 128 connessioni per byte indovinato (tale numero può essere in qualche modo abbassato assumendo che i byte dei cookie siano caratteri ASCII stampabili).
Nel tuo caso, l'applicazione client non è probabilmente un browser Web e, in quanto tale, potrebbe essere difficile per gli autori di attacchi attivare connessioni ripetute. Inoltre, se si esegue l'autenticazione reciproca con i certificati, è possibile che non si abbiano cookie di sessione di grandi dimensioni, eliminando così un obiettivo succoso. Tuttavia, gli attaccanti possono ancora tentare la fortuna e indovinare alcuni byte, se accettano di interrompere la maggior parte delle connessioni su cui tentano di indovinare. Se gli attaccanti riescono a farcela con discrezione dipende in realtà da come si comporta l'applicazione quando le connessioni vengono interrotte. In particolare , se viene eseguito "keep-alive" HTTP (come di consueto per SOAP-over-HTTP-over-SSL), il client si aspetta alcune richieste di errore (perché il server ha perso la pazienza e chiuso la connessione) e riavviarli in silenzio, quindi è probabile che gli hacker possano fare le loro ipotesi in silenzio.
Si noti che POODLE riguarda una violazione di riservatezza , non una violazione di integrità . Se si utilizza SSL solo in modo che i dati vengano autenticati, ma senza inviare nulla di segreto attraverso il tunnel SSL, POODLE cessa di essere un problema.
Riepilogo: ciò che fornisce la mitigazione per POODLE non è il certificato client; ciò che può fornire una mitigazione è che il client non è un browser Web. Tuttavia, la vulnerabilità del protocollo è ancora presente e può ancora essere sfruttabile, a seconda dei dettagli del protocollo dell'applicazione.
Dovresti davvero pensare all'aggiornamento di queste applicazioni client. Mantenendo attivo SSL 3.0, stai cercando problemi.
Leggi altre domande sui tag tls known-vulnerabilities