Es complicado. Lo que presentaré a continuación es una versión dramáticamente simplificada de los detalles. (Debido a que los detalles reales se encuentran en cientos de páginas de RFC). Hay esencialmente 3 pasos criptográficos para una conexión TLS:
- autenticación
- Intercambio de claves
- Comunicaciones cifradas para la aplicación
Autenticación generalmente implica que el servidor se identifique ante un cliente presentando un certificado. Este certificado valida que está hablando con un servidor legítimo: tiene el nombre de host del servidor incorporado, la fecha de caducidad y está firmado por una autoridad de certificación legítima. Además, contiene una clave pública: la posesión de la clave privada correspondiente es una prueba de que el certificado "le pertenece a usted". La mayoría de las veces, este es un par de claves RSA, aunque también es posible usar DSA o ECDSA, o incluso otro sistema de clave pública (pero en Internet abierto, casi siempre es RSA de 2048 o 4096 bits). Esto es lo que da a los clientes advertencias de certificados (nombre de host incorrecto, CA incorrecta, caducado, etc.). Esta es la parte para la que genera una clave y debe coincidir con su especificación de cifrado.
En segundo lugar es intercambio de claves . Si no está buscando un perfecto secreto hacia adelante, esto puede ser tan simple como que el cliente cifre una parte de los datos utilizando la clave pública del servidor desde su certificado. El servidor luego desencripta esto, y ambos lados lo usan para generar la clave de conexión. Por otro lado, si desea un perfecto secreto hacia adelante (es decir, el robo de la clave RSA no es suficiente para descifrar todas las conexiones anteriores) utiliza una variante del intercambio de claves Diffie-Hellman: básicamente, una técnica para llegar a un secreto compartido de forma segura . Sin un hombre activo en el medio, un tercero no puede obtener la clave compartida, y el paso de autenticación garantiza que no haya un hombre activo en el medio. Este paso DH puede ser Diffie Hellman sobre un grupo entero (DHE) o sobre una curva elíptica (ECDHE). Ya sea que utilice RSA, DHE o ECDHE para el intercambio de claves, ahora tiene una clave secreta compartida entre el cliente y el servidor que nadie más debería tener.
Finalmente, obtienes la comunicación cifrada real. Los crypos asimétricos como RSA y DH son demasiado lentos para las comunicaciones en curso de grandes volúmenes, por lo que utilizamos sistemas criptográficos simétricos (como AES) para esto. Esto utiliza la clave compartida intercambiada en el paso anterior para comunicarse. Cada paquete también está firmado, ya sea con un HMAC (por lo que es posible que vea SHA256 como parte de su especificación de cifrado) o una etiqueta como GMAC de GCM (para AES-GCM). Además, AES (y otros cifrados) se pueden ejecutar en varios modos: GCM, CTR, CBC, etc.
Algunos ejemplos:
ECDHE-RSA-AES128-SHA256 significa usar Elliptic Curve Diffie-Hellman para el intercambio de claves, RSA para autenticación y AES128 con firma de mensajes SHA256. (Se utiliza el modo CBC, aunque no se incluye explícitamente).
ECDHE-ECDSA-AES128-GCM-SHA256 es Elliptic Curve Diffie-Hellman para intercambio de claves, Elliptic Curve DSA para autenticación, AES 128 para criptografía (GCM para paquetes de firma, SHA256 para firmar otros datos).
AECDH-RC4-SHA es Curva elíptica anónima Diffie Hellman para el intercambio de claves, sin autenticación (por lo tanto, anónima), RC4 para el cifrado y SHA-1 para la autenticación de paquetes. (Por favor, no use esto. Todo está roto por los estándares modernos. Es un ejemplo.)