He aquí una pregunta sobre la que vale la pena reflexionar: si SSL lleva años «muerto», ¿por qué todo el sector sigue diciendo «SSL» cada día? Compras un «SSL certificate», configuras «SSL settings» y lees páginas de proveedores sobre «SSL security», pero el protocolo que realmente hace el trabajo es, casi con toda seguridad, TLS. La distinción entre SSL y TLS se ha convertido en una de las peculiaridades de nomenclatura más persistentes en el ámbito de la ciberseguridad.
La razón es más importante que las trivialidades. Elprotocolo Security Socket Layer(SSL) quedó oficialmente obsoleto ya en 2015, y en 2020 todas las versiones de SSL habían desaparecido de los navegadores y servidores compatibles. Los certificados que las autoridades de certificación comercializan como «certificadosSSL » son, en la práctica, certificadosTransport Layer Security(TLS). La denominación se mantuvo; el protocolo, no.
Este artículo se salta las definiciones básicas y va directo a lo que los equipos de seguridad realmente necesitan. Aclararemos las diferencias reales entre los dos protocolos, explicaremos por qué la falta de uniformidad en la terminología puede distorsionar tu postura de seguridad y expondremos lo que tu equipo debería hacer hoy mismo. Ambos protocolos se basan en certificados X.509 para autenticar los terminales y establecer la confianza, por lo que el vocabulario que utilices determina tu nivel de comprensión de los sistemas que gestionas.
Una breve historia: de « SSL » a TLS
Netscape, un navegador de Internet muy popular en la década de los noventa, creó SSL para proteger las primeras transacciones en la web. SSL 1.0 nunca llegó a comercializarse debido a graves fallos de seguridad. SSL 2.0 salió al mercado en 1995, pero presentaba sus propias deficiencias. SSL 3.0 le siguió en 1996, antes de que se dejara de utilizar oficialmente en 2015.
Cuando el protocolo necesitó un marco estandarizado e independiente de los proveedores, el Grupo de Trabajo de Ingeniería de Internet (IETF) tomó el relevo. El IETF desarrolló TLS como sucesor de SSL: TLS 1.0 se lanzó en 1999, basado en SSL 3.0, pero deliberadamente no interoperable con él. TLS La versión 1.1 se lanzó en 2006, TLS la 1.2 en 2008 y, finalmente, TLS la 1.3 en 2018, tras aproximadamente 30 borradores de la IETF. El gran número de borradores refleja la evolución que ha experimentado TLS, que ha abordado y reforzado el protocolo frente a múltiples vulnerabilidades detectadas a lo largo de los años. Ejemplos de dichas vulnerabilidades son los ataques de relleno y de degradación, Poodle, Heartbleed, etc.
La limpieza que se llevó a cabo a continuación fue decisiva. Microsoft, Apple, Google, Mozilla, Cloudflare y Cisco dejaron de recomendar el uso de TLS 1.0 y 1.1 en marzo de 2020. En la actualidad, solo TLS 1.2 y TLS 1.3 siguen en uso activo, y todas las versiones anteriores se consideran ahora un riesgo, más que una opción heredada.
Diez diferencias técnicas clave entre SSL y TLS
Los protocolos comparten ciertas similitudes, pero sus mecanismos internos difieren de formas que afectan directamente a la seguridad. La tabla siguiente resume diez diferencias clave, seguidas de un análisis más detallado de cada una de ellas, desde el diseño general SSL hasta el más moderno TLS 1.3.
| SSL | TLS (1.3) | |
|---|---|---|
| Secreto perfecto hacia adelante | Nunca es obligatorio | Obligatorio (con una única excepción) |
| AEAD | Nunca | Obligatorio |
| Algoritmos | Algoritmos débiles, como MD5, SHA-1 y DES | Algoritmos modernos y robustos, como SHA-2 y AES |
| Mensajes de alerta | Se enviaba sin cifrar en las primeras versiones | Cifrado, con notificación de errores |
| Funciones de derivación de claves | Añadir KDF ad hoc, a menudo basadas en algoritmos específicos | Utiliza un KDF moderno con sólidas garantías de seguridad |
| Ataques de relleno contra RSA | Permite versiones de RSA vulnerables a los ataques de relleno | No permite versiones de RSA que sean vulnerables a ataques de relleno |
| Protección contra ataques de degradación y sustitución | Es vulnerable, en muchos aspectos, a los ataques de degradación y sustitución | Cuenta con numerosos mecanismos de protección contra la degradación, entre los que se incluyen transcripciones que vinculan criptográficamente cada etapa del protocolo. |
| PQC | El PQC nunca se estandarizará para SSL | Se están elaborando las normas PQC |
| Protocolo de registro | El protocolo de registro propio de Netscape | Protocolo de registro normalizado por la IETF |
| Optimizado | 2 RTT | 1 RTT |
 
Secreto perfecto hacia adelante
SSL Normalmente, una sesión se protegía cifrando su clave con la clave a largo plazo del servidor. Cualquiera que obtuviera posteriormente esa clave a largo plazo podría descifrar todas las conversaciones que se hubieran grabado, incluso las de años atrás. TLS La versión 1.3 exige una clave nueva y de un solo uso para cada conexión, que se descarta en el momento en que finaliza la conexión. El robo de la clave privada de un servidor sigue siendo grave, pero ya no deja al descubierto el tráfico anterior.
AEAD
SSL codificaba los datos y comprobaba si habían sido manipulados en dos pasos distintos, en un orden que obligaba al receptor a descodificar los datos proporcionados por el atacante antes de confirmar su autenticidad. Los atacantes aprendieron a aprovechar esa brecha. La versión 1.3 de TLS solo permite algoritmos de cifrado que realicen ambas tareas a la vez, por lo que cualquier dato que no supere la comprobación de manipulación se descarta antes incluso de ser examinado.
Algoritmos
SSL Se basaba en cifrados y funciones hash que, desde entonces, han sido descifrados, y además incluía opciones debilitadas deliberadamente que eran un vestigio de las normas de exportación de la década de los noventa. La versión 1.3 de TLS eliminó todas ellas y ofrece únicamente una breve lista de algoritmos que siguen siendo fiables. La clave está precisamente en ese menú más reducido. Ya no hay ninguna opción débil que pueda seleccionar un servidor mal configurado.
Mensajes de alerta
Cuando fallaba una conexión SSL , el mensaje de error se transmitía sin cifrar, por lo que cualquiera que estuviera vigilando la red podía saber exactamente qué había fallado. TLS 1.3 cifra esos mensajes casi de inmediato, lo que mantiene la confidencialidad de los fallos. La contrapartida para los administradores es que una captura de red ya no basta por sí sola para explicar un fallo, y la resolución de problemas pasa a basarse en los registros del cliente y del servidor.
Funciones de derivación de claves
Cada conexión comienza con un único secreto compartido y requiere varias claves independientes derivadas de él. SSL utilizaba una fórmula propia para ese paso, que funcionaba en la práctica pero que nunca se había respaldado con ninguna prueba. TLS La versión 1.3 utiliza un método estándar y bien estudiado, con un argumento de seguridad claro que lo respalda, y deriva cada clave de tal forma que, aunque se conozca una, no se revela nada sobre las demás.
Ataques de relleno contra RSA
Durante décadas, una forma concreta de utilizar RSA adolecía de un fallo conocido que permitía a un atacante paciente recuperar la clave secreta fundamental de una conexión. Se aplicaron correcciones en repetidas ocasiones, pero estas fueron eludidas una y otra vez. La versión 1.3 de TLS dejó de aplicar parches y eliminó por completo ese uso de RSA. RSA sigue apareciendo, pero solo para verificar la identidad y únicamente en una forma que cuenta con una sólida garantía de seguridad.
Protección contra ataques de degradación y sustitución
Varios de los ataques más conocidos contra SSL nunca lograron descifrar ningún sistema criptográfico. Se interponían en medio de una conexión y modificaban discretamente la negociación inicial, engañando a ambas partes para que acordaran una protección débil que cada una creía que la otra había solicitado. SSL no pudo detectar la manipulación. TLS 1.3 verifica que ambas partes hayan visto una negociación idéntica y sin modificaciones antes de que se transfiera ningún dato real.
Criptografía poscuántica
SSL ha quedado obsoleto y no se seguirá trabajando en él. TLS La versión 1.3 se diseñó para admitir nuevos algoritmos sin necesidad de una nueva versión del protocolo, lo cual cobra importancia ahora que está llegando la criptografía resistente a los ordenadores cuánticos. El intercambio de claves poscuánticas ya se ha incorporado a los navegadores más habituales. Los certificados poscuánticos son el paso más difícil que queda por dar, sobre todo porque las nuevas claves y firmas son mucho más grandes.
Protocolo de registro
SSL Era una especificación propia de una empresa, que se revisaba cada vez que dicha empresa decidía hacerlo. Una vez que la responsabilidad pasó a manos de un organismo de estándares abiertos, todas las versiones posteriores han sido revisadas públicamente por los creadores de software y analizadas de forma independiente por investigadores antes de su publicación. TLS 1.3 también oculta en mayor medida la estructura interna de una conexión a cualquiera que observe la red.
Idas y vueltas del protocolo de establecimiento de conexión
Antes de que una conexión SSL pudiera transmitir un solo byte de datos reales, ambas partes tenían que intercambiar dos rondas completas de mensajes. TLS 1.3 reorganiza ese intercambio inicial de modo que basta con una sola ronda. En una conexión móvil lenta, el tiempo de ida y vuelta que se ahorra se nota en la rapidez con la que se carga una página.
TLS TLS . 1.2 frente a . 1.3: qué ha cambiado
Dado que tanto TLS 1.2 como TLS 1.3 siguen utilizándose activamente, comprender las diferencias entre ambas versiones es una necesidad práctica, no un ejercicio académico. Destacan tres cambios.
Rendimiento más rápido del protocolo de enlace
TLS La versión 1.3 reduce el protocolo de establecimiento de conexión a una sola ida y vuelta, frente a las dos de la versión TLS 1.2. Un menor número de idas y vueltas se traduce en un establecimiento más rápido de la conexión y un HTTPS más ágil para los usuarios. El proceso optimizado de establecimiento de conexión TLS es una de las razones más evidentes para elegir la versión TLS 1.3 como opción preferida para las nuevas implementaciones.
Confidencialidad hacia adelante perfecta de forma predeterminada
Como se ha mencionado anteriormente, TLS 1.3 exige el secreto perfecto hacia adelante mediante Diffie-Hellman efímero, mientras que las versiones anteriores lo consideraban opcional. El protocolo genera una clave de sesión única para cada sesión, por lo que el compromiso de una clave no pone en peligro las demás. Este diseño limita el alcance de una brecha de seguridad y refuerza la resistencia frente a los ataques de fuerza bruta y de «hombre en el medio».
Eliminación de algoritmos criptográficos obsoletos
TLS La versión 1.3 se suministra con un conjunto de cifrado sencillo que incluye únicamente algoritmos sin vulnerabilidades conocidas. TLS La versión 1.2, por el contrario, sigue permitiendo algunos cifrados débiles, lo que amplía la superficie de ataque y complica la configuración. Según el NIST, los servidores y clientes gubernamentales TLS deben ser compatibles con TLS 1.2 con conjuntos de cifrado basados en FIPS, y el NIST recomienda que las organizaciones elaboren planes de migración hacia TLS 1.3.
Cifrado autenticado con datos asociados (AEAD)
TLS Hasta la versión 1.2, el cifrado y la autenticación se trataban como operaciones independientes, aplicándose normalmente el MAC antes del cifrado. Ese orden obligaba a los receptores a procesar el texto cifrado controlado por el atacante antes de verificarlo, lo que dio lugar a una larga serie de ataques de oráculo de relleno. TLS La versión 1.3 solo permite cifrados AEAD, que integran la confidencialidad y la integridad en una única primitiva bajo una única clave y eliminan por completo la composición.
Por qué persiste la terminología «SSL» (y cuándo plantea problemas reales)
El término «SSL» perdura por una sencilla razón: está muy arraigado en las interfaces de los productos, la documentación y el marketing de los proveedores. Las bibliotecas criptográficas como OpenSSL y WolfSSL siguen llevando ese nombre. Las pantallas de configuración siguen denominando los campos «SSL », las bases de conocimientos siguen haciendo referencia a la «SSL setup» y las páginas de ventas siguen anunciando «SSL certificates». Estos términos se han vuelto intercambiables en el uso cotidiano, aunque el protocolo subyacente sea TLS.
En la mayoría de los casos, se trata de una forma abreviada e inofensiva de expresarse. El problema surge cuando la etiqueta y la realidad se alejan entre sí de tal manera que afectan a las decisiones. Un equipo puede creer que está utilizando «SSL» cuando, en realidad, sus servidores negocian TLS 1.2, lo que enturbia cualquier evaluación honesta del estado de seguridad.
El cumplimiento normativo añade otra complicación. En ocasiones, los auditores señalan referencias «SSL» en la documentación que describe configuraciones de « TLS », lo que obliga a los equipos a dedicar tiempo a conciliar la redacción con la implementación. La brecha entre lo que se denomina un sistema y lo que realmente ejecuta es donde se acumulan silenciosamente la confusión y el riesgo.
El futuro de « TLS »: ciclos de vida más cortos y preparación para la era poscuántica
La siguiente cuestión importante es: «¿Cómo gestionamos TLS a gran escala en un contexto en constante evolución?». Hay dos factores que están transformando el panorama: la reducción drástica de la vigencia de los certificados y la llegada de la criptografía poscuántica.
Cambios en la vigencia de los certificados
El CA/Browser Forum ha aprobado acortar la vigencia de los certificados « TLS » según un calendario firme: 200 días para 2026, 100 días para 2027 y 47 días para 2029. A medida que se reduce la vigencia, el volumen de renovaciones se multiplica por ocho aproximadamente, y el seguimiento manual deja de ser viable. Prepararse para una vigencia de los certificados de 47 días implica tratar la renovación como un proceso automatizado y permanente, en lugar de como un simple recordatorio en el calendario.
Criptografía poscuántica
El protocolo « TLS » actual no se diseñó para resistir ataques cuánticos, y el intercambio de claves que tiene lugar durante el proceso de establecimiento de la conexión es el componente más vulnerable. La preocupación más acuciante es el ataque «harvest-now-decrypt-later» (HNDL), en el que los adversarios capturan hoy el tráfico cifrado y lo descifran una vez que los ordenadores cuánticos alcancen la madurez. En respuesta a ello, el sector está realizando la transición hacia la criptografía poscuántica (PQC), en la que los futuros protocolos de establecimiento de conexión sustituirán el intercambio clásico de claves, como el RSA, por mecanismos de encapsulación de claves (KEM).
Las normas ya están aquí. El NIST ha ultimado sus primeras normas sobre PQC, las FIPS 203, 204 y 205, publicadas en agosto de 2024. El intercambio híbrido de claves PQC ya funciona en la versión actual de « TLS » 1.3 mediante nuevos grupos de intercambio de claves, en lugar de una nueva versión del protocolo, y el borrador de la IETF define X25519MLKEM768, SecP256r1MLKEM768 y SecP384r1MLKEM1024 como mecanismos híbridos para « TLS » 1.3.
La adopción está avanzando más rápido de lo que muchos esperaban. Un estudio de evaluación realizado en 2026 reveló que aproximadamente el 49 % de los dominios analizados mostraban una preparación parcial para la era poscuántica mediante el intercambio híbrido de claves, impulsado por la integración de ML-KEM-768 en navegadores, plataformas en la nube y redes de distribución de contenidos (CDN). Las organizaciones deberían planificarse ya para adoptar modelos de certificados híbridos que admitan tanto algoritmos clásicos como poscuánticos.
Aunque TLS 1.2 sigue siendo compatible en muchos sitios, pasar a TLS 1.3 es el siguiente paso que permite aumentar la seguridad y prepara tu infraestructura para el futuro. Todos los mecanismos que se están estandarizando para el cifrado poscuántico TLS están destinados exclusivamente a la versión 1.3, lo que deja a TLS 1.2 totalmente fuera del panorama de la migración.
Cómo Keyfactor ayudarte Keyfactor
Pasar de una mentalidad de «SSL» a operaciones reales de « TLS » requiere algo más que cambiar el nombre de un campo en la documentación. Keyfactor ofrece a los equipos de seguridad la plataforma necesaria para gestionar certificados a gran escala a medida que se acorta su vida útil y para prepararse con confianza para la transición a la era poscuántica.
Automatización del ciclo de vida de los certificados mediante Keyfactor Command ofrece visibilidad de principio a fin y renovación automatizada, lo cual resulta esencial a medida que los ciclos se reducen hasta los 47 días. Su moderna plataforma PKI, EJBCA, ofrece una PKI de nivel empresarial que admite la «agilidad criptográfica» y protocolos de inscripción estándar para la emisión a gran escala de certificados « TLS ».La función de detección e inventario criptográficoidentifica automáticamente todos los activos criptográficos, lo que permite evaluar la preparación frente a la computación cuántica y eliminar las configuraciones heredadas de « SSL » que aún persisten.
La gestión automatizada del ciclo de vida de los certificados convierte un quebradero de cabeza en materia de cumplimiento normativo en una operación repetible. Visita Solicitar una demo para descubrir cómo Keyfactor te ayuda a dejar atrás los supuestos de la era SSL y a gestionar TLS tal y como exigen los estándares de seguridad actuales.
¿Tienes dudas sobre « SSL » frente a « TLS »? Tenemos las respuestas.
¿Sigue siendo seguro utilizar « SSL »?
No. Todas las versiones de SSL han quedado obsoletas debido a vulnerabilidades conocidas, y SSL 3.0 se retiró en 2015. Los navegadores y servidores modernos ya no son compatibles con SSL, por lo que deberías utilizar TLS 1.2 o 1.3.
¿Son lo mismo los certificados « SSL » y los certificados « TLS »?
En la práctica, sí. Los proveedores y las autoridades de certificación que venden «certificadosSSL » están vendiendo, en realidad, certificados TLS . El término se sigue utilizando como abreviatura, pero el protocolo que protege tu conexión es TLS.
¿Cuál es la versión más segura de « TLS » disponible en la actualidad?
TLS 1.3. Elimina los algoritmos obsoletos, aplica el secreto perfecto hacia adelante de forma predeterminada y reduce el proceso de establecimiento de la conexión a una sola ida y vuelta. Esa combinación la convierte en la opción más sólida y eficiente disponible actualmente.
¿Tengo que migrar de TLS 1.2 a TLS 1.3?
TLS 1.2 sigue siendo muy utilizado y es seguro si se configura correctamente, pero TLS 1.3 mejora tanto el rendimiento como la seguridad. El NIST recomienda elaborar planes de migración, por lo que conviene que TLS 1.3 sea el objetivo para las nuevas implementaciones.
¿Cómo afecta la reducción de la vigencia de los certificados a la gestión de SSL/TLS ?
El CA/Browser Forum va a reducir la vigencia máxima a 47 días para 2029, lo que multiplica por ocho, aproximadamente, los ciclos de renovación. La gestión manual resulta insostenible a ese ritmo, por lo que la gestión automatizada del ciclo de vida se vuelve imprescindible.
¿Qué significa la criptografía poscuántica para TLS?
Los ordenadores cuánticos podrían llegar a descifrar los algoritmos que se utilizan actualmente en el protocolo de establecimiento de conexión de TLS . El sector está incorporando algoritmos resistentes a la criptografía cuántica, por lo que las organizaciones deberían realizar un inventario de sus activos criptográficos y planificar modelos de certificados híbridos que admitan tanto algoritmos clásicos como poscuánticos.
¿Por qué los navegadores siguen mostrando «SSL» en su configuración de seguridad?
Denominación heredada. Los navegadores y las herramientas hacen referencia a SSL por costumbre, pero el protocolo que protege la conexión es TLS. Si ves una conexión segura HTTPS, esta se está ejecutando en TLS.
¿Cómo puedo saber qué versión de TLS utiliza mi servidor?
Utiliza herramientas de línea de comandos de command, como OpenSSL, o un servicio de pruebas en línea. Al ejecutar «openssl s_client -connect yourdomain.com:443», se muestran la versión de TLS negociada y el conjunto de cifrado.
