¿Cómo protege TLS realmente una conexión HTTPS?

Hay gente que dice "HTTPS significa que está encriptado" y se queda ahí, pero la parte interesante es cómo dos extraños en internet acuerdan un secreto compartido sin nunca encontrarse, por una red llena de gente que podría estar escuchando. Eso es lo que hace TLS, y los mecanismos valen la pena entenderlos si tocas networking, desarrollo web, o seguridad de cualquier forma.

El handshake, paso a paso

Cuando tu navegador se conecta a https://example.com, esto es más o menos lo que pasa (TLS 1.3, que la mayoría de sitios usan ahora):

1. ClientHello — el navegador envía cipher suites soportados, un nonce aleatorio, y una suposición de compartir clave (usando algo como X25519 o secp256r1) para el intercambio de claves.
2. ServerHello — el servidor elige un cipher suite, envía su propio compartir clave, y devuelve su certificado más una firma que prueba que posee la clave privada que corresponde a ese certificado.
3. Derivación de clave — ambos lados ahora independientemente calculan el mismo secreto compartido usando matemáticas al estilo Diffie-Hellman en sus compartires de clave. Ninguno nunca transmite el secreto en sí; se deriva, no se envía.
4. Mensajes Finished — ambos lados confirman que el handshake no fue alterado enviando un MAC sobre toda la transcripción del handshake.

Después de eso, todo está encriptado con claves simétricas derivadas del secreto compartido, usualmente AES-128-GCM o ChaCha20-Poly1305. TLS 1.3 redujo esto del handshake de dos round trips de TLS 1.2 a efectivamente un round trip, lo cual es una verdadera ganancia de latencia a escala.

Por qué el certificado importa más que la encriptación

La encriptación sin verificación de identidad es inútil — cualquiera puede establecer un canal encriptado, incluyendo un atacante corriendo un ataque de intermediario. El certificado es lo que vincula una clave pública a un nombre de dominio, y está firmado por una Autoridad de Certificados (CA) como Let's Encrypt o DigiCine.

Tu navegador confía en una lista fija de CAs raíz integradas en el SO o en la tienda de confianza del navegador. El certificado del servidor forma una cadena a través de certificados intermedios hasta una de esas raíces. Si la cadena no valida, o el dominio en el certificado no coincide con el que solicitaste, obtienes la página de advertencia roja. Ese modelo de cadena de confianza es el verdadero límite de seguridad — roba la clave de firma de una CA y puedes emitir certificados válidos para cualquier dominio, por eso los compromisos de CA se tratan como incidentes mayores.

Qué está haciendo la criptografía simétrica versus asimétrica aquí

La criptografía asimétrica (RSA o curva elíptica) es lenta y cara, así que TLS solo la usa durante el handshake — para autenticar el servidor y para ayudar a establecer el secreto compartido. Una vez que eso está hecho, todos los datos reales (HTML, JSON, lo que sea) están encriptados con cifrados simétricos rápidos. Este enfoque híbrido es el mismo patrón que verás en SSH, PGP, y la mayoría de sistemas de criptografía del mundo real: asimétrica para identidad e intercambio de claves, simétrica para datos en volumen.

La secreto hacia adelante es un detalle relacionado que vale la pena conocer: porque el secreto compartido viene de compartires de clave Diffie-Hellman efímeros generados frescos por sesión, incluso si alguien graba tu tráfico y luego roba la clave privada del servidor, aún no pueden desencriptar sesiones viejas. Esa propiedad no existía en intercambios de clave anteriores de solo RSA.

Verificándolo tú mismo

No necesitas confiar ciegamente en un icono de candado verde. Ejecuta:

openssl s_client -connect example.com:443 -tls1_3

Eso te muestra el cipher suite negociado, la cadena de certificados, y si el handshake realmente completó. Para una mirada más rápida a lo que un navegador ve, curl -v https://example.com imprime la versión de TLS y los detalles del certificado antes de la respuesta HTTP.

También puedes desencriptar tu propio tráfico en Wireshark si exportas la variable de ambiente SSLKEYLOGFILE antes de lanzar Chrome o Firefox — genuinamente útil para debuggear problemas de TLS en lugar de adivinar.

Dónde esto realmente falla en la práctica

La mayoría de fallas reales de HTTPS no son breaks criptográficos, son operacionales: certificados expirados, cadenas intermedias mal configuradas, clientes estancados en versiones viejas de TLS, o contenido mixto (una página HTTPS cargando un recurso HTTP). Los ataques reales a nivel de protocolo contra TLS 1.3 moderno son raros porque la especificación cerró la mayoría de los trucos de oracle de padding y downgrade que plagaron SSL 3.0 y TLS temprano. Los puntos débiles ahora son usualmente los endpoints — una CA comprometida, una clave privada robada, o un usuario clickeando a través de una advertencia de certificado que no debería haber hecho.

Si quieres ir más allá, los segmentos de networking y criptografía de Korra Studio cubren la matemática de Diffie-Hellman subyacente y el análisis de protocolo a nivel de paquete con más profundidad.