Cada vez que un navegador muestra el candado en la barra de direcciones, está confirmando que existe un canal cifrado de extremo a extremo entre el cliente y el servidor. Ese canal lo proporciona TLS (Transport Layer Security), el protocolo que heredó y sustituyó al antiguo SSL. Aunque por costumbre se sigue hablando de «certificados SSL», SSL 3.0 está obsoleto y prohibido desde la RFC 7568 (2015): lo que protege hoy las conexiones es TLS, y conocer su funcionamiento es imprescindible para cualquier responsable de sistemas que quiera garantizar la confidencialidad, la integridad y la autenticación de los datos en tránsito.
Qué garantiza realmente TLS
TLS ofrece tres propiedades de seguridad simultáneas. La confidencialidad impide que un tercero que intercepte el tráfico pueda leerlo, mediante cifrado simétrico. La integridad garantiza que los datos no se han alterado en tránsito, mediante códigos de autenticación de mensajes (MAC) o cifrado autenticado (AEAD). Y la autenticación verifica que el servidor es quien dice ser, mediante certificados digitales firmados por una autoridad de certificación (CA) de confianza. Sin esta última, el cifrado sería inútil: estaríamos hablando de forma privada con un atacante.
El handshake TLS paso a paso
El protocolo resuelve un problema elegante: cómo dos partes que nunca se han visto acuerdan una clave secreta a través de un canal público que cualquiera puede escuchar. La solución combina criptografía asimétrica (para establecer la confianza) con criptografía simétrica (para cifrar los datos, mucho más rápida). En TLS 1.3 el proceso es:
- ClientHello. El cliente anuncia las versiones y suites de cifrado que soporta y envía su parte de un intercambio de claves Diffie-Hellman efímero (ECDHE).
- ServerHello. El servidor elige la suite, envía su certificado y su parte del intercambio Diffie-Hellman.
- Derivación de claves. Ambas partes calculan de forma independiente la misma clave de sesión simétrica sin que viaje nunca por la red.
- Finished. Se verifica que el handshake no ha sido manipulado y comienza el intercambio cifrado.
La gran mejora de TLS 1.3 (RFC 8446, 2018) frente a TLS 1.2 es la reducción del handshake a un solo viaje de ida y vuelta (1-RTT), con la opción 0-RTT para reanudar sesiones, lo que mejora notablemente la latencia. Además elimina algoritmos heredados inseguros: ya no admite RSA para el intercambio de claves (obligando a forward secrecy), ni RC4, ni MD5, ni los modos CBC vulnerables.
La diferencia entre ambas versiones no es solo de velocidad, sino de superficie de ataque. TLS 1.2 permitía negociar suites de cifrado que hoy se consideran inseguras, y muchos ataques históricos (BEAST, POODLE, Lucky 13) explotaban precisamente esas combinaciones obsoletas o la negociación de versiones a la baja. TLS 1.3 reduce drásticamente el catálogo de suites admitidas a un puñado de opciones modernas con cifrado autenticado (AEAD), de modo que ya no existe la posibilidad de elegir, por error de configuración, una combinación débil. Esta simplificación es en sí misma una mejora de seguridad: menos opciones significa menos formas de equivocarse.
Forward secrecy: por qué importa el intercambio efímero
El Perfect Forward Secrecy (PFS) es una de las propiedades más importantes y peor entendidas. Con intercambio de claves efímero (ECDHE), cada sesión genera claves únicas que se descartan al terminar. Esto significa que, aunque un atacante capture el tráfico cifrado hoy y robe la clave privada del servidor dentro de cinco años, no podrá descifrar las sesiones pasadas. Sin PFS, comprometer una sola clave privada expondría retroactivamente todo el histórico de comunicaciones. TLS 1.3 hace que PFS sea obligatorio.
Certificados digitales: tipos y cadena de confianza
Un certificado X.509 vincula una identidad (un dominio) con una clave pública, y esa vinculación la firma una CA en la que el navegador confía de fábrica. Existen tres niveles de validación:
| Tipo | Validación | Uso típico |
|---|---|---|
| DV (Domain Validation) | Solo control del dominio | Blogs, sitios personales, APIs internas |
| OV (Organization Validation) | Dominio + existencia legal de la organización | Corporativo, comercio electrónico |
| EV (Extended Validation) | Verificación jurídica exhaustiva | Banca, sectores regulados |
La cadena de confianza va del certificado del servidor a uno o más certificados intermedios y, finalmente, a un certificado raíz que el sistema operativo o el navegador ya tiene preinstalado. Configurar mal la cadena (olvidar el intermedio) es una de las causas más frecuentes de error «certificado no confiable» aunque el certificado de hoja sea válido. Iniciativas como Let's Encrypt han democratizado los certificados DV gratuitos y automatizados mediante el protocolo ACME.
Revocación: cuando un certificado válido deja de serlo
Un certificado puede dejar de ser de confianza antes de su fecha de caducidad, por ejemplo si su clave privada se ve comprometida. Para estos casos existen mecanismos de revocación. Las CRL (listas de revocación de certificados) son listados que el cliente debería descargar para comprobar si un certificado figura como revocado, pero su tamaño y latencia las hacen poco prácticas. El protocolo OCSP (Online Certificate Status Protocol) permite consultar el estado de un certificado concreto en tiempo real, aunque introduce un problema de privacidad y de latencia, ya que el navegador contacta con la CA en cada conexión.
La solución moderna es el OCSP stapling: el propio servidor obtiene periódicamente de la CA una respuesta OCSP firmada y con marca de tiempo, y la adjunta («grapa») al handshake TLS. Así el cliente recibe la prueba de validez sin contactar con la CA, eliminando la fuga de privacidad y la latencia. Activar OCSP stapling es una de las optimizaciones de rendimiento y privacidad más recomendables en cualquier despliegue serio.
HSTS, certificate pinning y endurecimiento
Tener TLS activo no basta; hay que evitar que un atacante fuerce una degradación a HTTP. La cabecera HSTS (HTTP Strict Transport Security) indica al navegador que solo debe conectar por HTTPS durante un periodo definido, eliminando la ventana de ataque del primer redireccionamiento. El certificate pinning va más allá: la aplicación (especialmente en móvil) memoriza qué certificado o clave pública concreta espera del servidor, de modo que rechaza cualquier otro aunque esté firmado por una CA válida, mitigando ataques de CA comprometidas. El pinning debe gestionarse con cuidado porque, mal configurado, puede dejar una aplicación inaccesible al renovar el certificado.
Pasos de implementación y verificación
- Generar una clave privada robusta (RSA 2048+ o, preferiblemente, ECDSA P-256) y la CSR.
- Obtener el certificado de una CA de confianza e instalar la cadena completa (hoja + intermedios).
- Configurar el servidor para admitir solo TLS 1.2 y TLS 1.3, deshabilitando SSL 3.0, TLS 1.0 y TLS 1.1.
- Seleccionar suites de cifrado que garanticen forward secrecy (ECDHE) y AEAD (AES-GCM o ChaCha20-Poly1305).
- Activar HSTS, redirección 301 de HTTP a HTTPS y, si procede, OCSP stapling.
- Automatizar la renovación (los certificados públicos tienden a plazos de validez cada vez más cortos) y monitorizar la caducidad.
- Verificar la configuración con herramientas de análisis externo antes de dar por cerrado el despliegue.
Errores comunes
El primero es dejar caducar el certificado: provoca caídas totales del servicio y, peor aún, enseña a los usuarios a ignorar las advertencias de seguridad. El segundo es mantener protocolos obsoletos activos por compatibilidad con clientes antiguos, lo que reabre vulnerabilidades conocidas. El tercero es servir contenido mixto (mixed content): una página HTTPS que carga recursos por HTTP rompe las garantías de seguridad y el navegador la marca como insegura. El cuarto es proteger solo el frontal y dejar sin cifrar el tráfico entre servicios internos, una práctica incompatible con los modelos de confianza cero.
Preguntas frecuentes
¿SSL y TLS son lo mismo? No. SSL es el protocolo antecesor, ya obsoleto e inseguro. TLS es su sucesor. El término «certificado SSL» persiste por costumbre comercial, pero los certificados sirven para TLS.
¿Un certificado EV mejora el posicionamiento SEO? No directamente. Los buscadores valoran que el sitio use HTTPS, pero no distinguen entre DV, OV y EV a efectos de ranking. El tipo de certificado se elige por requisitos de confianza y cumplimiento, no por SEO.
¿Es seguro Let's Encrypt al ser gratuito? Sí. La seguridad la aporta el protocolo TLS y la fortaleza de la clave, no el precio del certificado. Un certificado DV gratuito ofrece exactamente el mismo cifrado que uno de pago del mismo nivel.
¿Debo cifrar también el tráfico entre microservicios internos? Sí, en la arquitectura actual se recomienda TLS extremo a extremo incluso dentro de la red (mTLS, autenticación mutua), porque el perímetro de red ya no se considera una frontera de confianza fiable.
Conclusión
El cifrado en tránsito ha dejado de ser un complemento opcional para convertirse en el requisito mínimo de cualquier servicio que mueva datos por una red. Pero «tener HTTPS» y «tener TLS bien configurado» son cosas muy distintas: la diferencia está en forzar TLS 1.3 con forward secrecy, mantener la cadena de certificados completa, activar HSTS y automatizar las renovaciones para que ninguna caducidad tumbe el servicio. La criptografía que protege estas conexiones es sólida; los incidentes casi nunca se deben al algoritmo, sino a configuraciones desactualizadas y certificados mal gestionados. En Summum auditamos despliegues TLS, eliminamos protocolos heredados y dejamos la renovación automatizada y monitorizada, de modo que el candado del navegador signifique exactamente lo que el usuario cree que significa.