¿Qué es un protocolo SSL/TLS?
Un protocolo SSL/TLS es una negociación entre dos partes en una red -como un navegador y un servidor web- para establecer los detalles de su conexión. Determina qué versión de SSL/TLS se utilizará en la sesión, qué conjunto de cifrado cifrará la comunicación, verifica el servidor (y a veces también el cliente) y establece que existe una conexión segura antes de transferir los datos.
Todo esto ocurre en segundo plano, afortunadamente: cada vez que diriges tu navegador a un sitio seguro se produce una compleja interacción para garantizar que tus datos estén seguros.
Esa es la versión sencilla. Puede que te des cuenta de que una docena de descripciones se ajustan más o menos a este formato, aunque difieren en los detalles de una docena de maneras diferentes, a veces de forma confusa. Vamos a poner un gráfico que muestre un modelo amplio de cómo funciona un apretón de manos TLS, ¿de acuerdo? SSL.com lo tiene cubierto. Compare las opciones aquí para encontrar la opción adecuada para usted, desde certificados S/MIME y de firma de código y mucho más.
PEDIR AHORA
Gráfico obligatorio del apretón de manos SSL/TLS
Todos los sitios relacionados con SSL/TLS tienen su propia versión de un diagrama de apretón de manos – ¡aquí está el nuestro! (Haga clic para ampliar.)
Aclaremos algunas confusiones, si podemos
Algunas confusiones sobre el funcionamiento de los handshakes SSL/TLS se deben a que el handshake es sólo el preludio de la propia sesión segura. Intentemos abordar algunos puntos comunes:
Encriptación asimétrica frente a simétrica
El handshake propiamente dicho utiliza una encriptación asimétrica: se utilizan dos claves distintas, una pública y otra privada. Dado que los sistemas de cifrado asimétrico tienen una sobrecarga mucho mayor, no son utilizables para proporcionar seguridad a tiempo completo en el mundo real. Por tanto, la clave pública se utiliza para el cifrado y la privada para el descifrado sólo durante el apretón de manos, lo que permite a las dos partes establecer e intercambiar confidencialmente una «clave compartida» recién creada. La propia sesión utiliza esta clave compartida única para realizar el cifrado simétrico, y esto es lo que hace que una conexión segura sea factible en la práctica real (la sobrecarga es mucho menor). Por lo tanto, la respuesta completa y correcta a «¿El cifrado SSL/TLS es asimétrico o simétrico?» es «Primero uno, luego el otro».
¿Qué es un «conjunto de cifrado»?
El apretón de manos propiamente dicho tiene múltiples etapas, cada una de ellas gestionada de acuerdo con diferentes reglas. Los detalles se pueden encontrar aquí, pero lo esencial es que en lugar de una serie de negociaciones separadas de ida y vuelta (sobre qué claves utilizar, cómo encriptar el apretón de manos en sí, cómo autenticar el apretón de manos y así sucesivamente) las partes pueden acordar el uso de un «conjunto de cifrado» – una selección preexistente o kit de componentes acordados. (Recuerde que el cifrado asimétrico es costoso en cuanto a tiempo y recursos – el uso del conjunto de cifrado como un atajo acelera el propio handshake). Las especificaciones de TLS permiten un buen número de suites de cifrado, y el cliente y el servidor casi siempre tendrán acceso a uno que ambos puedan emplear.
Handshake básico vs mutuamente autenticado
Otro punto confuso es que el modelo básico que describimos anteriormente permite al cliente verificar al servidor, y la gran mayoría de las sesiones aseguradas por TLS sólo requieren esto. Sin embargo, algunos conjuntos de cifrado requerirán que el cliente también envíe un certificado y una clave pública para la autenticación mutua de ambas partes. Esta autenticación bidireccional, por supuesto, añadirá una sobrecarga al handshake – sin embargo, en algunos casos (por ejemplo, cuando dos bancos están negociando una conexión segura para las transferencias de fondos) el conjunto de cifrado insistirá en ello, y la seguridad adicional se considera que vale la pena.
Diferentes sesiones tendrán diferentes parámetros de seguridad
Cada nuevo handshake crea una nueva sesión, y la configuración utilizada en uno puede diferir drásticamente de otro dependiendo del conjunto de cifrado elegido. Esta es una de las razones por las que existen tantas iteraciones diferentes de esa maldita tabla de handshake, y por lo que estamos dando una visión bastante amplia aquí. También debes saber que las sesiones pueden establecer parámetros que pueden no ser exactamente lo que esperas. Dependiendo del conjunto de cifrado, algunos pasos pueden ser añadidos (como el requisito de autenticación bidireccional) o ausentes. De hecho, hay suites de cifrado que negocian una sesión para no utilizar ningún tipo de cifrado. (Sí, lo sabemos, una conexión HTTPS sobre el puerto 443 que decide enviar datos en claro tampoco tiene sentido para nosotros. SSL.com recomienda encarecidamente que no hagas esto – sólo sé que está en el reino de lo posible.)