SSL 2.0 non è una vulnerabilità; è un protocollo che sembra contenere vulnerabilità strutturali e, in quanto tale, non dovrebbe essere consentito.
C'è un RFC che dice proprio questo ed elenca le principali carenze note in SSL 2.0:
SSL version 2.0 [SSL2] deficiencies include the following:
o Message authentication uses MD5 [MD5]. Most security-aware users
have already moved away from any use of MD5 [RFC6151].
o Handshake messages are not protected. This permits a man-in-the-
middle to trick the client into picking a weaker cipher suite than
it would normally choose.
o Message integrity and message encryption use the same key, which
is a problem if the client and server negotiate a weak encryption
algorithm.
o Sessions can be easily terminated. A man-in-the-middle can easily
insert a TCP FIN to close the session, and the peer is unable to
determine whether or not it was a legitimate end of the session.
Dei quattro, solo l'ultimo è veramente un problema serio strutturale con il protocollo. Infatti:
-
Sebbene MD5 sia danneggiato per quanto riguarda le collisioni , è ancora abbastanza strong per altri usi, incluso il modo in cui viene utilizzato in SSL 2.0 per proteggere l'integrità.
-
Quando un utente malintenzionato inganna client e server per utilizzare una suite di crittografia debole, il vero problema non è che l'utente malintenzionato possa ingannare il client e il server; è che il client e il server effettivamente accettano per utilizzare una suite di crittografia debole.
-
Il punto sull'utilizzo della stessa chiave per la crittografia e l'integrità ha senso, ancora una volta, solo se il client e il server accettano di utilizzare la crittografia debole. Ciò potrebbe accadere nei giorni precedenti a causa del rispetto delle normative statunitensi sulle esportazioni, ma tutto questo è scomparso dal 2000.
-
La mancanza di terminazione verificata è un problema quando l'SSL viene utilizzato per trasmettere un protocollo in cui i messaggi non sono auto-terminati. Un caso tipico è HTTP 0.9: il client sa di aver ottenuto il file completo perché il server chiude la connessione. Con SSL 2.0, un utente malintenzionato attivo può forzare una chiusura anticipata della connessione e il client non ha modo di sapere se si tratta del vero end-of-file o di un troncamento dannoso.
Si potrebbe sostenere che con il moderno HTTP, questo problema non si applica più.
Quindi, in effetti, se un client e un server utilizzano SSL 2.0 al momento (maggio 2014), è probabile che questo non sia un problema reale (o, almeno, non il più grande problema di sicurezza). La vera ragione per cui SSL 2.0 è bannato è che è stato deprecato per molto tempo (dal 1996 e l'invenzione di SSL 3.0), quindi qualsiasi uso di SSL 2.0 indica che alcuni dei software coinvolti hanno non è stato aggiornato per almeno così a lungo - e che è un problema. SSL 2.0 è glorificato canarino .
Oppure, detto diversamente, usare o persino consentire a SSL 2.0 ti rivela come un amministratore di sistema sciatto, obsoleto, non consono.