Che cosa determina esattamente quale versione di SSL / TLS viene utilizzata quando si accede a un sito?

Come dice @Terry, il client suggerisce , il server sceglie . Ci sono dettagli:

• Il formato generico del primo messaggio client (il ClientHello ) indica la versione più alta supportata e implicitamente afferma che tutte le versioni precedenti sono supportate, il che non è necessariamente vero. Ad esempio, se il client supporta TLS 1.2, indicherà "versione massima: 1.2". Ma il server può quindi scegliere di utilizzare una versione precedente (ad esempio, TLS 1.0), che il client non desidera necessariamente utilizzare.

• I clienti moderni hanno preso l'abitudine di provare più volte. Ad esempio, un cliente può prima inviare un ClientHello che afferma "TLS 1.2" e, se qualcosa (qualcosa) non riesce, prova ancora con un ClientHello che indica "TLS 1.0". I client lo fanno perché esistono server TLS non conformi e non conformi che possono eseguire TLS 1.0, ma rifiutano i messaggi ClientHello che contengono "TLS 1.2".

  Una conseguenza divertente è che un utente malintenzionato attivo può forzare un client e un server a utilizzare una versione precedente (ad esempio TLS 1.0) anche quando entrambi supportano una versione più recente del protocollo, chiudendo forzatamente la connessione iniziale. Questo è chiamato "attacco di versione di rollback". Non è critico se il client e il server non accettano mai di utilizzare una versione di protocollo decisamente debole (e TLS 1.0 è ancora ragionevolmente strong). Tuttavia, ciò implica che un client e un server non possono avere la garanzia che stiano utilizzando la "migliore" possibile versione del protocollo fintanto che il client implementa tale politica "try again" (se il client non ha implementato tale "try again" allora l'attacco di rollback sarebbe stato prevenuto, ma alcuni siti Web sarebbero diventati apparentemente irraggiungibili.

• Il messaggio ClientHello per SSL 2.0 ha un formato molto distinto. Quando un cliente desidera supportare sia SSL 2.0 che alcune versioni successive, deve inviare uno speciale ClientHello che segue il formato SSL 2.0 e specifica che "a proposito, conosco anche SSL 3.0 e TLS 1.0". Questo è descritto in appendice E di RFC 2246 . I moderni client SSL (browser Web) non lo fanno più (credo che IE 6.0 lo abbia ancora fatto, ma non IE 7.0).

  RFC 4346 (TLS 1.1) specifica che tali messaggi ClientHello di tipo SSLv2 saranno " eliminato gradualmente "ad un certo punto e dovrebbe essere evitato. RFC 5246 (TLS 1.2) afferma più chiaramente che i client NON DEVONO supportare SSL 2.0, e quindi non dovrebbero avere motivo per inviare tali messaggi di ClientHello . RFC 6176 ora proibisce SSL 2.0 del tutto.

  Ora una RFC non è una legge: non vai in prigione perché non supporti alcuna RFC particolare. Tuttavia, RFC fornisce ancora una guida e quindi in qualche modo illustra quale sarà lo stato delle cose nel vicino (o lontano) futuro.

In pratica:

• La maggior parte dei client là fuori invierà solo messaggi SSLv3 + ClientHello , e si connetterà felicemente con SSL 3.0, TLS 1.0, TLS 1.1 o TLS 1.2, a seconda di ciò che il server sembra supportare (ma, a causa del "riprovare" "criterio, un downgrade della versione può essere forzato da un utente malintenzionato attivo.
• In realtà, alcuni client non supporteranno SSL 3.0 e richiedono TLS 1.0.
• Analogamente, alcuni client non supporteranno TLS 1.1 o 1.2. I browser Web sono stati aggiornati negli ultimi anni (in seguito alla cattiva stampa risultante dall'attacco BEAST), ma raramente le applicazioni non del browser vengono mantenute in modo aggressivo.
• Molti server accettano ancora un formato diClientHello SSLv2%, a condizione che il messaggio ClientHello sia un SSLv3 + ClientHello sotto mentite spoglie.
• Alcuni server, come il tuo, sono ancora contenti di fare un po 'di SSL 2.0. Questo non è conforme a RFC 6176 ed è disapprovato (le persone che credono nel "classificare server SSL" ti daranno un punteggio negativo). Questo non è un serio problema di sicurezza, tuttavia, a patto che i client non supportino effettivamente SSL 2.0. Anche se un client supporta SSL 2.0, dovrebbe includere alcuni trucchi di prevenzione del rollback (descritti nella RFC 2246), quindi un rollback verso SSL 2.0 non dovrebbe funzionare.

Desiderate ancora disattivare il supporto SSL 2.0 nel vostro server (non necessariamente il formato di% s% di co2date SSLv2, ma il supporto effettivo di SSL 2.0), se non altro per le pubbliche relazioni.

Dovresti leggere il processo di handshake TLS.

Per riassumere brevemente, il client (che in questo caso è il browser) invia un messaggio ClientHello al server. Questo contiene la versione TLS massima supportata e un elenco di suite di crittografia supportate in ordine di preferenza. Il server decide che quale versione TLS e suite di crittografia desidera utilizzare per la connessione TLS e informa il client rispondendo con una ServerHello . Idealmente dovrebbe essere selezionata la versione TLS più alta e la suite di cifratura più potente, ma la specifica TLS non lo garantisce. Il server è libero di utilizzare qualsiasi cosa desideri dall'elenco fornito dal client.

Quando un cliente vuole inviare dati a un server usando SSL / TLS, un client deve prima passare attraverso un handshake per autenticarsi con il server. Questa stretta di mano inizia con "ClientHello", in cui il client invia al server una versione di SSL o TLS che supporta, le crittografie supportate e altri dati di sessione. Nelle versioni precedenti di SSL (versione 2), era possibile intercettare questo pacchetto di handshake e modificare l'elenco di cifrature supportato per contenere solo cifrari deboli. Questo non è più possibile poiché SSLv3 utilizza un hash nella parte finale dell'handshake, dove è presente l'hash client e server e confronta i messaggi inviati e ricevuti.

Tutti i browser moderni supportano SSLv3 fino a TLSv1.2, ma utilizzeranno la versione più alta supportata da un server. Un intermediario non può modificare direttamente alcun pacchetto inviato nell'handshake, ma un intermediario può intercettare e rilasciare determinati pacchetti. Ingannando il browser nel pensare che il server non supporta una determinata versione di SSL / TLS, un utente malintenzionato può eseguire il downgrade della versione negoziata. Puoi vedere come funziona visitando il Pretorio post recente: Man-in-the-Middle TLS Protocol Downgrade Attack

Perché spostarsi da SSLv3 ora?

Sebbene SSLv3 includesse attenuazioni speciali per impedire attacchi di downgrade del protocollo, non è necessariamente il protocollo ideale da utilizzare. SSLv3 presenta differenze crittografiche significative, che potrebbero causare punti deboli che dimostrano ulteriormente perché TLSv1.2 dovrebbe essere lo standard corrente. Le crittografie e i codici di autenticazione concordati, così come i meccanismi di scambio delle chiavi, erano significativamente diversi nei nostri test di downgrade del protocollo. Nell'esempio sopra, TLSv1.2 utilizza la crittografia a curva ellittica (ECC) insieme alla modalità contatore per AES, mentre SSLv3 utilizza il crittografo RC4 e RSA precedenti.

Alcuni potrebbero chiederti perché è necessario. Nel suo discorso su Black Hat del 2013, Alex Stamos ha discusso lo stato attuale e il futuro della crittografia. Ha sostenuto che uno dei pericoli risiede nella possibilità di rompere cifre o meccanismi di scambio chiave più vecchi in futuro. Nel caso di RSA, crittografi e matematici hanno compiuto progressi significativi nel problema della fattorizzazione. Diffie-Hellman (DH) si basa sul problema del logaritmo discreto per la sicurezza crittografica e, sebbene non esista un algoritmo efficiente utilizzato per calcolare i registri discreti, il runtime degli algoritmi di logaritmo discreti è diminuito significativamente nell'ultimo anno. Come Stamos ha discusso, una volta che RSA o DH falliscono, la firma del codice si interromperà e gli attacchi su SSL / TLS diventeranno molto diffusi.

In sintesi, un attacco attivo su una connessione può comportare una sicurezza crittografica ridotta. Client e server possono impedire che ciò accada supportando solo le versioni più recenti di TLS. Inoltre, i client dovrebbero rispondere correttamente agli handshake falliti. Attualmente, molti browser optano per l'interoperabilità sulla sicurezza, il che rende fattibili attacchi di downgrade del protocollo. Questi cambiamenti richiederanno tempo e sforzi significativi. I browser dovrebbero reimplementare aspetti di come gestiscono le strette di mano. La compatibilità con le versioni precedenti potrebbe interrompersi in alcuni casi. Tuttavia, alla fine avremo bisogno di utilizzare le versioni più recenti di TLS che supportano ECC. Perché non fare la spinta ora e prevenire futuri attacchi?