Perché il deprecato protocollo SSL 2.0 è considerato non sicuro e come può essere sfruttato?

4

Sto facendo una presentazione alla classe su "Protocollo deprecato SSL 2.0" e non ho davvero idea di come questo exploit sia usato o di come l'hacker possa usare questo vul. Comprendo l'impatto di questo vul, ma ho bisogno di una spiegazione completa su come funziona e dei passaggi che un utente malintenzionato dovrebbe affrontare per condurre attacchi man-in-the-middle o decifrare le comunicazioni tra il servizio interessato ei client. Si prega di spiegare il processo che un utente malintenzionato può utilizzare in una spiegazione specifica, se possibile.

    
posta user3585363 01.05.2014 - 21:11
fonte

1 risposta

11

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.

    
risposta data 01.05.2014 - 21:27
fonte

Leggi altre domande sui tag