Quale versione di TLS utilizza un browser Web quando si collega al server in cui sono abilitati tutti i protocolli SSL?

La teoria, come esposta nello standard è la seguente:

server_version
   This field will contain the lower of that suggested by the client
   in the client hello and the highest supported by the server.

Nel messaggio ClientHello , il client annuncia una singola versione e questo significa "Suppongo tutte le versioni fino a quella versione". Ad esempio, se il client dice "TLS 1.1", il client promette in qualche modo di poter gestire SSL 3.0, TLS 1.0 e TLS 1.1. Si suppone che il server scelga la versione del protocollo più recente supportata da client e server.

Tuttavia, le implementazioni client sanno che non viviamo in un mondo perfetto, e alcuni server sbagliano a volte, quindi fanno collegamenti in un loop. Ad esempio, il client annuncia per la prima volta "TLS 1.2", ma se l'handshake non riesce per qualche motivo che potrebbe essere dovuto al debole supporto del server, il client può riprovare, annunciando solo "TLS 1.1" o "TLS 1.0". Non tutti i client lo fanno, ma questo è comune per i browser Web. Come spiegato da @dave, unClientHello di TLS all'1,2% potrebbe essere più grande di una versione precedente e fare in modo che server mal scritti su di esso, quindi il comportamento "riprova con una versione inferiore" è, purtroppo, necessario.

Come spiegato sopra, il client annuncia solo un intervallo, quindi il cliente non può esprimere un supporto "con buchi", ad es. supportare TLS 1.0 e 1.2 ma non 1.1 (non che abbia molto senso). Allo stesso modo, il client invia sia la "versione massima supportata del protocollo" sia l'elenco ordinato di suite di crittografia supportate, quindi il client non può esprimere in una sola ClientHello una preferenza come: "facciamo TLS 1.2 e AES-CBC, ma se dobbiamo usare TLS 1.0 quindi preferirei RC4 perché temo mortalmente l'attacco BEAST ". Se un cliente vuole applicare tali preferenze, allora deve fare il trucco "connessioni multiple".

Per riassumere , il normale paradigma di SSL è: il client suggerisce, il server sceglie . Ma se il cliente vuole forzare il server a utilizzare una specifica versione di protocollo e / o suite di crittografia, può, occasionalmente, ricorrere a tali collegamenti tramite i re-collegamenti e i browser Web esistenti.

Sebbene alcuni client SSL (inclusi i browser) e server possano essere configurati per abilitare o disabilitare versioni di protocollo, non esiste un ordine di preferenza. Il messaggio ClientHello indica solo la versione più alta offerta (sebbene la versione del livello record venga talvolta utilizzata per suggerire il valore più basso); il messaggio ServerHello può scegliere qualsiasi versione < = l'offerta del client e dovrebbe essere la versione più alta supportata da entrambi. Se il massimo offerto dal client è troppo basso per il server, il server dovrebbe fallire l'handshake, e se la scelta del server è troppo bassa per il client, il client dovrebbe farlo. Vedi Qual è il significato del campo versione in un messaggio ClientHello TLS 1.1+? .

Nota che entrambe le parti potrebbero decidere di fare meno di quello che possono. Ad esempio, Java 7 (SunJSSE) implementa TLS1.2 ma il client di default offre solo 1.0 perché Sun ^ WOracle percepiva troppo rischio di problemi; e il client Java 6 per impostazione predefinita utilizzava il formato SSLv2 con la versione 0301 offerta in modo che il server potesse scegliere SSLv3 o TLS1.0, ma se il server accettava SSLv2 (che è obsoleto e non sicuro), il client non ha superato l'handshake con un'eccezione specifica "SSLv2 è insicuro "invece di solo" cattiva risposta "come sarebbe successo per SSLv3 + ciao al server solo SSLv2. Al contrario, OpenSSL 1.0.1 ha implementato TLS1.2 (e 1.1) e il client per impostazione predefinita ora offre 1.2, che ha causato rapidamente un'eruzione di reclami sulle mailing list sui server che improvvisamente hanno fallito su 1.2 ClientHello, che è significativamente più grande a causa del cifrario di default più grande più alcune nuove estensioni, risultando in un'eruzione di soluzioni spesso brutte.

Le Ciphersuites sono elencate in ordine come descrive Rubber Duck, sebbene il server non sia tenuto a rispettare quell'ordine e alcuni no. Così come le curve ellittiche (a volte importanti), i formati a punti ellittici (raramente importanti) e gli algoritmi di compressione (raramente implementati e spesso indesiderati a causa di attacchi di tipo CRIME). Notate che l'intera stretta di mano, inclusa la lista ciphersuite, è protetta da manomissioni, incluso il downgrade da SSLv3 con lo scambio finito, a meno che non ingannino nel tentativo di migliorare le prestazioni, ad es. link (che per lo più non ha funzionato per altri motivi). Ma i client - o anche gli utenti - possono volontariamente effettuare il downgrade se l'utente malintenzionato simula proprio gli errori del server.

Come parte dell'handshake, il server finisce scegliendo il codice scelto.

Per RFC 5246 , il client (browser) invia un elenco di quali versioni di cifrature supporta. Il server sceglie quindi quale desidera utilizzare. Generalmente, andrà alla cifra più aggiornata. Tuttavia, un'idea interessante degli attacchi man-in-the-middle è quella di eseguire il downgrade dell'elenco di crittografi supportati sul messaggio di benvenuto del client iniziale.

Altro può essere letto su TLS Cipher Suites , ma il riassunto è questo:

When a TLS connection is established, a handshaking, known as the TLS Handshake Protocol, occurs. Within this handshake, a client hello (ClientHello) and a server hello (ServerHello) message are passed. (RFC 5246, p. 37) First, the client sends a cipher suite list, a list of the cipher suites that it supports, in order of preference. Then the server replies with the cipher suite that it has selected from the client cipher suite list. (RFC 5246, p. 40) In order to test which TLS ciphers that a server supports an SSL/TLS Scanner may be used.