Ho raccolto i problemi che riguardano lo SSL 3.0 e ho scoperto che erano
- sono problemi di configurazione (disabilitazione di RC4, RC2, DES, anon, esportazione, suite null, compressione, lunghezze delle chiavi appropriate, ecc.) o
- richiede un browser in cui l'autore dell'attacco può generare traffico utilizzando JavaScript.
Quindi la domanda è: una connessione SSL 3.0 configurata correttamente può essere attaccata se il client non è un browser? (Pensa ai MUA e ad altri agenti del genere.) Ci sono attacchi che possono indirizzare un client-server SSL 3.0 configurato correttamente che non sarebbe possibile se l'unica cosa che cambierebbe fosse il protocollo con una versione più recente?
Ho le seguenti teorie sui potenziali attacchi:
- BREACH, CRIME: entrambi fanno affidamento sull'effetto di compressione del testo in chiaro noto fornito da un utente malintenzionato, quindi non sono utilizzabili se l'utente malintenzionato non può avviare richieste nel contesto del client SSL vittima
- POODLE: può forzare il fallback su SSL 3.0, ma in questo caso, SSL 3.0 è usato da solo, quindi l'attacco è irrilevante (vedi altri attacchi)
- BEAST, Lucky13: entrambi si basano su oracoli crittografici (basati sul tempo o sulla risposta) che sono sfruttabili solo se l'utente malintenzionato può avviare richieste nel contesto del client SSL vittima, il che non è il caso nel mio scenario precedente
- Attacchi RC4: mitigati disattivando RC4, lasciando le cifrarie 3DES-CBC come uniche scelte (AES non era ancora incluso in SSL 3.0, poiché è stato rilasciato nel 1996)
- FREAK, LOGJAM: mitigato dall'imposizione di lunghezze chiave sane (> 1024 bit) su client e server
In breve, il mio client e il mio server sono configurati in modo che le chiavi abbiano una lunghezza ragionevole e l'unica suite di crittografia abilitata sia SSL_RSA_WITH_3DES_EDE_CBC_SHA .
Vedi anche discussione precedente su / r / crypto