¿Qué versión de TLS utiliza el navegador web cuando se conecta al servidor donde están habilitados todos los Protocolos SSL?

La teoría, como se expone en el estándar es que:

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.

En el mensaje ClientHello , el cliente anuncia una versión única, y esto significa "Admito todas las versiones hasta esa versión". Por ejemplo, si el cliente dice "TLS 1.1", entonces el cliente promete de alguna manera que puede manejar SSL 3.0, TLS 1.0 y TLS 1.1. Se supone que el servidor elige la versión de protocolo más reciente que admiten tanto el cliente como el servidor.

Sin embargo, las implementaciones de los clientes saben que no vivimos en un mundo perfecto, y algunos servidores se equivocan a veces, por lo que hacen conexiones en un bucle. Por ejemplo, el cliente primero anuncia "TLS 1.2", pero si el protocolo de enlace falla por alguna razón que podría se debe al soporte del servidor, el cliente puede intentarlo de nuevo, anunciando solo "TLS 1.1" o "TLS 1.0". No todos los clientes hacen eso, pero esto es común para los navegadores web. Como explica @dave, un TLS 1.2 ClientHello puede ser más grande que una versión anterior y hacer que los servidores mal escritos se disparen, por lo que el comportamiento de "intente nuevamente con una versión más baja" es, por desgracia, necesario.

Como se explicó anteriormente, el cliente solo anuncia un rango, por lo que el cliente no puede expresar un soporte "con agujeros", por ejemplo. soporta TLS 1.0 y 1.2 pero no 1.1 (no es que tenga mucho sentido). De manera similar, el cliente envía tanto su "versión máxima de protocolo admitido" como su lista ordenada de suites de cifrado admitidas, por lo que el cliente no puede expresar en una única ClientHello una preferencia como: "hagamos TLS 1.2 y AES-CBC, pero si tenemos que usar TLS 1.0, entonces preferiría RC4 porque tengo un miedo mortal al ataque de BESTIA ". Si un cliente desea imponer tales preferencias, entonces debe hacer el truco de "conexiones múltiples".

Para resumir , el paradigma normal de SSL es: lo sugiere el cliente, el servidor elige . Pero si el cliente quiere forzar al servidor a usar una versión específica del protocolo y / o una suite de cifrado, entonces puede, a través de las reconexiones, y los navegadores web existentes pueden jugar este tipo de juegos ocasionalmente.

Aunque algunos clientes SSL (incluidos los navegadores) y los servidores pueden configurarse para habilitar o deshabilitar versiones de protocolo, no hay un orden de preferencia. El mensaje de ClientHello indica solo la versión más alta ofrecida (aunque la versión de capa de grabación a veces se usa para sugerir la más baja); El mensaje de ServerHello puede elegir cualquier versión < = la oferta del cliente, y debe ser la versión más alta admitida por ambos. Si el máximo ofrecido por el cliente es demasiado bajo para el servidor, el servidor debe fallar el protocolo de enlace, y si la opción del servidor es demasiado baja para el cliente, el cliente debe hacerlo. Consulte ¿Cuál es el significado del campo de versión en un mensaje TLS 1.1+ ClientHello? .

Tenga en cuenta que cualquiera de los lados puede decidir hacer menos de lo que puede. Por ejemplo, Java 7 (SunJSSE) implementa TLS1.2 pero el cliente por defecto solo ofrece 1.0 porque Sun ^ WOracle percibió demasiado riesgo de problemas; y el cliente Java 6 usó por defecto el formato SSLv2 con la versión ofrecida 0301 para que el servidor pudiera elegir SSLv3 o TLS1.0, pero si el servidor aceptó SSLv2 (que es obsoleto y muy inseguro), el cliente falló el protocolo de enlace con una excepción específica "SSLv2 es inseguro "en lugar de simplemente" mala respuesta "como hubiera ocurrido con SSLv3 + hola a SSLv2-only server. Por el contrario, OpenSSL 1.0.1 implementó TLS1.2 (y 1.1) y el cliente por defecto ahora ofrece 1.2, que rápidamente causó una serie de quejas en las listas de correo sobre servidores que fallaron repentinamente en el 1.2 ClientHello, que es significativamente mayor debido a la la lista de cifrado predeterminada más grande más algunas extensiones nuevas, lo que resulta en una erupción de soluciones a menudo feas.

Ciphersuites se enumeran en orden como lo describe Rubber Duck, aunque el servidor no está obligado a cumplir ese orden y algunos no. También lo son las curvas elípticas (a veces importantes), los formatos de puntos elípticos (raramente importantes) y los algoritmos de compresión (raramente implementados y con frecuencia indeseables debido a ataques de tipo CRIME). Pero tenga en cuenta que todo el protocolo de intercambio, incluida la lista de conjuntos de cifrado, está protegido contra la manipulación, incluida la degradación desde SSLv3 por el intercambio finalizado, a menos que haga trampa en un intento de mejorar el rendimiento, por ejemplo. enlace (que en su mayoría falló por otras razones). Pero los clientes, o incluso los usuarios, pueden degradarse voluntariamente si el atacante simplemente simula los errores del servidor.

Como parte del protocolo de enlace, el servidor termina eligiendo el cifrado elegido.

Por RFC 5246 , el cliente (navegador) envía una lista de las versiones de cifrados que admite. El servidor entonces elige cuál quiere usar. En general, irá por el cifrado más actualizado. Sin embargo, una buena idea de los ataques de hombre en el medio es degradar la lista de cifrado admitida en el mensaje inicial de saludo del cliente.

Se puede leer más en suites de cifrado TLS , pero el resumen es el siguiente:

  

Cuando se establece una conexión TLS, se produce un protocolo de intercambio, conocido como Protocolo de protocolo de enlace TLS. Dentro de este protocolo de enlace, se pasa un mensaje de saludo de cliente (ClientHello) y de saludo de servidor (ServerHello). (RFC 5246, p. 37) Primero, el cliente envía una lista de conjuntos de cifrado, una lista de los conjuntos de cifrado que admite, en orden de preferencia. Luego, el servidor responde con el conjunto de cifrado que ha seleccionado de la lista de conjuntos de cifrado del cliente. (RFC 5246, p. 40) Para probar qué cifrados TLS puede utilizarse un servidor con un escáner SSL / TLS.