Escribes una URL con https:// y en menos de 200 milisegundos tu navegador y el servidor han negociado un canal cifrado que ningún intermediario puede leer ni manipular. Ese proceso —el handshake TLS— combina criptografía asimétrica y simétrica de una forma tan elegante que merece entenderse línea a línea. Además explica por qué los certificados caducan, qué es exactamente TLS 1.3 y por qué HTTP puro ya no tiene excusa.
El problema que resuelve
Sin TLS, tres ataques son triviales para cualquiera con acceso a la red (tu WiFi pública, tu ISP, un nodo de salida):
- Escucha (eavesdropping): leer contraseñas, tokens o contenido en texto claro.
- Manipulación (tampering): modificar la respuesta — inyectar scripts, cambiar precios, redirigir descargas.
- Suplantación (impersonation): montar un servidor falso que responda al dominio legítimo.
TLS elimina los tres con dos mecanismos complementarios: cifrado del canal y autenticación del servidor mediante certificados.
Los dos tipos de criptografía y su reparto de trabajo
La clave del diseño está en usar cada herramienta para lo que es buena:
Criptografía asimétrica (RSA o, hoy casi siempre, ECDHE sobre curvas elípticas) resuelve el problema imposible: cómo acordar un secreto compartido por un canal que todos pueden escuchar. Es matemáticamente cara, así que solo se usa unos milisegundos al inicio.
Criptografía simétrica (AES-256-GCM o ChaCha20-Poly1305) cifra todo el tráfico real. Es cientos de veces más rápida, pero necesita que ambas partes ya compartan la clave — que es justo lo que el asimétrico acaba de conseguir.
El handshake es, en esencia, "usar lo caro durante 100 ms para fabricar la clave barata que usaremos el resto de la sesión".
El handshake TLS 1.2, paso a paso
TLS 1.2 sigue siendo mayoritario y su flujo ilustra mejor cada pieza:
- ClientHello: el navegador envía las versiones TLS que soporta, la lista de suites de cifrado que acepta y —crucial— un valor aleatorio de 32 bytes.
- ServerHello + Certificate: el servidor elige suite y versión, envía su propio aleatorio y su cadena de certificados X.509: el certificado del dominio firmado por una CA intermedia, firmada a su vez por la raíz.
- Verificación del certificado: el navegador valida la firma subiendo hasta una raíz de su almacén de confianza, comprueba fechas de vigencia, que el nombre del dominio coincida con el SAN (Subject Alternative Name) y consulta si el certificado ha sido revocado (CRL/OCSP).
- Intercambio de claves: con ECDHE, cliente y servidor realizan operaciones Diffie-Hellman sobre curvas elípticas usando sus claves privadas y parámetros efímeros. Del resultado derivan el mismo secreto sin haberlo transmitido jamás.
- Finished: ambos partes calculan un MAC de toda la conversación previa con las claves derivadas. Si alguien manipuló algo en medio, los MAC no coinciden y la conexión muere aquí.
A partir de ese momento, cada registro viaja cifrado y autenticado con AES-GCM: confidencialidad e integridad juntas.
Qué cambia en TLS 1.3
TLS 1.3 (2018) reescribió el handshake con tres objetivos:
- Menos viajes: con reutilización de sesiones, el navegador puede enviar datos útiles tras un solo round-trip (o incluso cero con
0-RTTpara reconexiones). - Forward secrecy obligatoria: eliminó RSA key transport y todo intercambio estático. Las claves de sesión siempre nacen de material efímero (la "E" de ECDHE). Si mañana roban la clave privada del servidor, no pueden descifrar tráfico capturado ayer.
- Superficie mínima: quedó un puñado de suites seguras. Murieron RC4, CBC mal usado, compresión TLS (origen del ataque CRIME) y renegociación.
Por qué los certificados caducan
Un certificado afirma "esta clave pública pertenece a este dominio", firmado por una autoridad. La caducidad limita el daño de claves filtradas y fuerza rotación. Con Let's Encrypt el ciclo son 90 días, diseñado para automatizarse vía ACME (Certbot y similares): renovar debe ser invisible, no un proyecto anual.
Si accedes a un sitio con certificado caducado, erróneo o autofirmado, el navegador bloquea porque cualquiera de esos estados rompe la garantía de suplantación — el tercer ataque del principio vuelve a ser posible.
Lo que HTTPS no protege
Conocer los límites evita falsa sensación de seguridad:
- Quién te visita: el dominio destino es visible en DNS y en el campo SNI del handshake (ECHE/Encrypted Client Hello lo está mitigando). HTTPS cifra el contenido, no el hecho de conectarte.
- Que el sitio sea honesto: un phishing con certificado válido de Let's Encrypt muestra candado verde. El candado significa canal cifrado hacia algo; no que ese algo sea quien dice ser.
- Malware dentro del contenido: cifrar el transporte no sanea lo transportado.
Cómo auditarlo en tu propia web
Los puntos que un chequeo serio revisa: protocolos habilitados (solo TLS 1.2 y 1.3), suite negociada, validez y SAN del certificado, cadena completa (un certificado intermedio ausente funciona en algunos navegadores y falla en otros), HSTS activado y redirección 301 desde HTTP. Nuestro comprobador SSL analiza tu dominio y te da exactamente ese informe; para ver los campos internos del certificado, el decodificador de certificados los vuelca en formato legible.
Preguntas frecuentes
¿HTTPS ralentiza mi web? El coste del handshake es de decenas de milisegundos, amortizado con session resumption y keep-alive. HTTP/2 —que exige HTTPS en la práctica— suele hacer las webs más rápidas que su equivalente HTTP/1.1 sin TLS.
¿Necesito IP dedicada para HTTPS? No desde SNI (Server Name Indication), que permite servir varios dominios TLS bajo una misma IP. Let's Encrypt emite gratis, así que el coste real de HTTPS es cero.
¿Puedo ver el tráfico HTTPS de mi app para depurar? Sí, pero no en la red: dentro de tu propio proceso. DevTools ve el plaintext después de descifrar; mitmproxy requiere instalar su CA en el dispositivo y solo funciona contra apps que no hagan certificate pinning.
Comprueba ahora el estado TLS de tu dominio con el verificador de certificados SSL, gratis y sin registro.