SSL/TLS funciona estableciendo un canal cifrado entre el navegador del visitante y el servidor web mediante un proceso de negociación llamado handshake. En ese proceso, ambas partes verifican identidades y acuerdan las claves que usarán para cifrar la conversación, todo en una fracción de segundo antes de que se transmita cualquier dato.
Si alguna vez te preguntaste qué ocurre exactamente detrás del candado de HTTPS, este artículo te lo explica desde los fundamentos hasta los detalles técnicos, sin dar nada por sentado.
SSL y TLS: ¿son lo mismo?
Técnicamente no. SSL (Secure Sockets Layer) fue el protocolo original, desarrollado por Netscape en los años 90. TLS (Transport Layer Security) es su sucesor, más seguro y eficiente. Las versiones SSL 2.0 y 3.0 están obsoletas y deshabilitadas en todos los servidores modernos.
Hoy en día usamos TLS 1.2 o TLS 1.3, pero el término "SSL" persiste en el lenguaje cotidiano porque así lo conoció la gente primero. Cuando alguien dice "instalar un certificado SSL", en realidad está hablando de TLS moderno.
| Versión | Año | Estado actual |
|---|---|---|
| SSL 2.0 / 3.0 | 1995–1996 | Obsoleto, inseguro, bloqueado |
| TLS 1.0 / 1.1 | 1999–2006 | Deprecado (deshabilitado en browsers modernos) |
| TLS 1.2 | 2008 | Vigente, ampliamente soportado |
| TLS 1.3 | 2018 | Estándar actual recomendado |
Los dos tipos de cifrado que usa TLS
Para entender cómo funciona SSL/TLS es indispensable distinguir dos tipos de criptografía que trabajan juntos:
Cifrado asimétrico (clave pública / clave privada)
Usa un par de claves matemáticamente vinculadas: la clave pública (que todos pueden ver) y la clave privada (que solo el servidor conoce). Lo que se cifra con la pública solo lo puede descifrar la privada, y viceversa.
Es seguro pero computacionalmente costoso. Por eso TLS lo usa solo durante el handshake inicial, para intercambiar credenciales y acordar una clave de sesión.
Cifrado simétrico (clave de sesión)
Usa una única clave compartida para cifrar y descifrar. Es mucho más rápido que el asimétrico. Una vez que el handshake termina, toda la comunicación usa cifrado simétrico con la clave de sesión acordada.
La combinación es elegante: la seguridad del cifrado asimétrico para establecer la clave, la velocidad del simétrico para transmitir los datos.
El handshake TLS paso a paso
El handshake es la negociación que ocurre cada vez que un navegador se conecta a un sitio HTTPS. En TLS 1.3 sucede en un solo viaje de ida y vuelta (1-RTT); en TLS 1.2 tomaba dos. Aquí el flujo completo:
- ClientHello: el navegador envía al servidor las versiones de TLS que soporta, los algoritmos de cifrado disponibles (cipher suites) y un número aleatorio.
- ServerHello: el servidor elige la versión de TLS y el cipher suite, envía su propio número aleatorio y presenta su certificado digital (que contiene su clave pública).
- Verificación del certificado: el navegador comprueba que el certificado fue firmado por una Autoridad Certificadora (CA) de confianza, que el dominio coincide y que no está caducado o revocado.
- Intercambio de clave: usando la clave pública del servidor y los números aleatorios, ambas partes derivan de forma independiente la misma clave de sesión simétrica. Nadie más puede calcularla.
- Finished: cada parte envía un mensaje cifrado con la clave de sesión para confirmar que el handshake fue exitoso. A partir de aquí, todo el tráfico HTTP viaja cifrado con esa clave.
El handshake completo tarda típicamente entre 50 y 200 ms dependiendo de la latencia de red. TLS 1.3 lo optimizó significativamente y también permite el 0-RTT resumption para conexiones que ya se habían establecido antes.
¿Qué protege TLS exactamente?
Una vez que la conexión está establecida, TLS protege todo el contenido de las peticiones HTTP:
- Las URLs completas (incluidos los parámetros
?query=). - Los headers HTTP (cookies, tokens de autenticación).
- El cuerpo de formularios POST (usuarios, contraseñas, datos de tarjeta).
- Las respuestas del servidor (contenido HTML, JSON de APIs, archivos).
Lo que TLS no oculta es el dominio al que te conectas (visible en el SNI del handshake y en DNS), ni la dirección IP del servidor. Para eso se necesitan capas adicionales como DNS sobre HTTPS (DoH) o VPN.
Por qué TLS 1.3 es el estándar que debes usar hoy
TLS 1.3, publicado en 2018, eliminó una serie de algoritmos obsoletos e inseguros que arrastraba TLS 1.2 (RC4, MD5, SHA-1, intercambios de clave RSA estáticos). Las mejoras clave son:
- Handshake más rápido: 1 viaje de ida y vuelta en lugar de 2 (reduce la latencia en ~100 ms en conexiones típicas).
- Perfect Forward Secrecy obligatorio: aunque alguien grabe el tráfico hoy y obtenga la clave privada mañana, no podrá descifrar sesiones pasadas.
- Superficie de ataque reducida: al eliminar cipher suites débiles, desaparecen vectores de ataque conocidos como BEAST, POODLE y SWEET32.
Si tu servidor todavía acepta TLS 1.0 o 1.1, es momento de deshabilitarlos. Puedes aprender cómo en nuestra guía de configuración de seguridad SSL.
Conclusiones clave
- SSL es el nombre histórico; el protocolo actual se llama TLS. Hoy debes usar TLS 1.2 o, preferiblemente, TLS 1.3.
- TLS combina cifrado asimétrico (para el handshake) y simétrico (para los datos), obteniendo seguridad y velocidad a la vez.
- El handshake verifica la identidad del servidor, intercambia claves y establece el canal cifrado antes de transmitir un solo byte de datos de usuario.
- TLS 1.3 es más rápido, elimina algoritmos débiles y fuerza Perfect Forward Secrecy, lo que lo hace el estándar de seguridad actual.
- TLS protege URLs, headers y cuerpos de peticiones, pero no oculta el dominio ni la IP del servidor.
¿Quieres verificar que tu sitio usa TLS 1.3 y tiene la configuración óptima? El equipo de elenlace.com realiza auditorías de seguridad SSL y te entrega un informe con los ajustes exactos que necesitas — contáctanos y lo revisamos.
Preguntas frecuentes
¿Por qué el navegador muestra "conexión segura" si alguien podría ver a qué dominio me conecto?
Porque "segura" se refiere al cifrado del contenido y a la autenticación del servidor, no al anonimato. TLS garantiza que nadie puede leer ni modificar los datos que intercambias con el sitio. Lo que sí es visible para un observador de red es el dominio (vía SNI y DNS), pero no el contenido de tus páginas, formularios ni sesiones.
¿Qué es Perfect Forward Secrecy y por qué importa?
Perfect Forward Secrecy (PFS) significa que cada sesión TLS usa claves efímeras que se descartan al terminar. Si un atacante captura tráfico cifrado hoy y en el futuro obtiene la clave privada del servidor, no puede descifrar las sesiones pasadas porque las claves de sesión ya no existen. TLS 1.3 lo hace obligatorio.
¿El handshake TLS es siempre igual de lento?
No. TLS 1.3 lo redujo a 1 viaje de ida y vuelta (1-RTT), y con session resumption puede ser 0-RTT para conexiones repetidas al mismo servidor. En la práctica, el impacto en tiempo de carga es milisegundos, completamente invisible para el usuario.
¿Cómo sé qué versión de TLS está usando mi servidor?
Puedes verificarlo con herramientas en línea como SSL Labs (ssllabs.com/ssltest) o con el comando openssl s_client -connect tudominio.com:443 desde la terminal. Lo ideal es ver "TLSv1.3" en la línea del protocolo y un cipher suite con ECDHE para garantizar Perfect Forward Secrecy.
¿Prefieres que lo hagamos por ti? En El Enlace resolvemos hosting y desarrollo web profesional.
Recursos útiles
Otros proveedores y guías que vale la pena comparar:
