Durante más de tres décadas, los protocolos SSL y TLS han protegido miles de millones de transacciones en línea. Lo que empezó como un ambicioso proyecto de seguridad de Netscape en 1994 evolucionó hasta convertirse en los sofisticados estándares de cifrado actuales. Esta historia de SSL abarca seis grandes versiones del protocolo, innumerables mejoras de la seguridad y un cambio fundamental en nuestra forma de pensar sobre la seguridad en la web.
Comprender las versiones de SSL/TLS no consiste sólo en saber qué protocolos están obsoletos. Se trata de reconocer cómo cada vulnerabilidad, ataque y avance ha dado forma al panorama actual, en el que TLS 1.3 asegura el 95% del tráfico web cifrado.
Índice
- El nacimiento del protocolo SSL en Netscape
- SSL 3.0 – Un rediseño completo del protocolo
- TLS 1.0 – La era de la normalización del IETF
- TLS 1.1 y TLS 1.2 – Mejoras de seguridad incrementales
- TLS 1.3 – El estándar de seguridad moderno
- Errores comunes sobre el control de versiones SSL/TLS
- El papel de las autoridades de certificación en la evolución SSL/TLS
- Hitos de la industria que dieron forma a la adopción de HTTPS
- Principales vulnerabilidades de seguridad que impulsaron la evolución de los protocolos
- Futuro de los protocolos SSL/TLS
¡Ahorra un 10% en Certificados SSL al hacer tu pedido en SSL Dragon hoy mismo!
Emisión rápida, encriptación fuerte, 99,99% de confianza del navegador, soporte dedicado y garantía de devolución del dinero en 25 días. Código del cupón: AHORRA10
El nacimiento del protocolo SSL en Netscape
SSL 1.0 – El primer intento inédito (1994)
Taher Elgamal, científico jefe de Netscape, diseñó el Secure Sockets Layer original en 1994. Pero SSL 1.0 nunca vio la luz. Los investigadores de seguridad de Netscape descubrieron fallos críticos antes del lanzamiento público, vulnerabilidades lo suficientemente graves como para desechar toda la versión.
La lección estaba clara: los protocolos criptográficos necesitan una revisión exhaustiva antes de su despliegue. Este contratiempo, aunque frustrante, estableció un patrón de pruebas rigurosas que definiría el futuro desarrollo de SSL y TLS.
SSL 2.0 – La primera versión pública (1995)
¿Cuándo apareció SSL? La respuesta es febrero de 1995, cuando Netscape incluyó SSL 2.0 con Navigator 1.1. Esta versión de SSL introdujo conceptos fundamentales que aún se utilizan hoy en día: el enlace SSL los certificados digitalesX.509 y la autenticación del servidor.
Pero SSL 2.0 tenía problemas. Se basaba en MD5 para la autenticación de mensajes, utilizaba la misma clave para el cifrado y la autenticación, y carecía de protección para el propio apretón de manos. Los atacantes podían degradar las conexiones a un cifrado más débil de 40 bits sin que ninguna de las partes se diera cuenta.
El IETF dejó oficialmente obsoleto el SSL 2.0 en marzo de 2011 mediante el RFC 6176. Para entonces, la mayoría de los servidores ya habían pasado página.
SSL 3.0 – Un rediseño completo del protocolo
Mejoras importantes respecto a SSL 2.0 (1996)
Paul Kocher, Phil Karlton y Alan Freier reescribieron completamente el protocolo SSL para la versión 3.0, publicada en noviembre de 1996. Separaron la capa de transporte de datos de la capa de mensajes, añadieron compatibilidad con el intercambio de claves Diffie-Hellman y las suites de cifrado Fortezza, e implementaron un cifrado adecuado de 128 bits.
SSL 3.0 también introdujo la compresión de registros y una negociación más flexible del conjunto de cifrado. El IETF lo documentó posteriormente en el RFC 6101, reconociendo su importancia histórica. Durante casi dos décadas, SSL 3.0 sirvió como opción alternativa para los sistemas heredados.
La vulnerabilidad POODLE y la eliminación de SSL 3.0
En octubre de 2014, el equipo de seguridad de Google descubrió POODLE (Padding Oracle on Downgraded Legacy Encryption). El ataque explotaba la forma en que SSL 3.0 gestionaba el relleno en modo de encadenamiento de bloques cifrados (CBC). Los atacantes podían descifrar cookies HTTP seguras forzando a los navegadores a pasar de TLS a SSL 3.0.
El IETF respondió rápidamente, eliminando SSL 3.0 en junio de 2015 mediante el RFC 7568. Esto marcó el final de la era SSL. Cuando la gente pregunta por la«última versión de SSL«, la respuesta es SSL 3.0, porque el propio SSL no volvió a actualizarse. La antorcha había pasado a Seguridad de la Capa de Transporte.
TLS 1.0 – La era de la normalización del IETF
Transición de SSL a TLS (1999)
A finales de los 90, el IETF quería estandarizar los protocolos de seguridad de Internet. Tim Dierks y Christopher Allen dirigieron los esfuerzos para transformar SSL en una norma abierta. Microsoft y Netscape negociaron la denominación: TransportLayer Security fue el compromiso que se mantuvo.
TLS 1.0, publicado como RFC 2246 en enero de 1999, era esencialmente SSL 3.1 con un nuevo nombre. Las diferencias eran menores, pero lo suficientemente significativas como para romper la compatibilidad. No podías mezclar clientes SSL 3.0 con servidores TLS 1.0 sin una implementación cuidadosa.
Principales diferencias con SSL 3.0
TLS 1.0 actualizó la criptografía subyacente. Sustituyó el código de autenticación de mensajes (MAC) personalizado de SSL por HMAC, estandarizado por los criptógrafos. La función de derivación de claves cambió para evitar ciertos ataques teóricos. El sistema de alerta se amplió con códigos de error más específicos.
TLS 1.0 también exigía compatibilidad con los conjuntos de cifrado DSS/DH, lo que daba más flexibilidad a las implementaciones. Estos cambios parecían pequeños, pero reflejaban un cambio del desarrollo propietario a la normalización impulsada por la comunidad. El IETF controlaba ahora la evolución del protocolo.
TLS 1.1 y TLS 1.2 – Mejoras de seguridad incrementales
Protección TLS 1.1 contra ataques CBC (2006)
Publicado en abril de 2006 a través del RFC 4346, TLS 1.1 abordaba vulnerabilidades CBC específicas. ¿El mayor cambio? Los vectores de inicialización (IV) explícitos sustituyeron a los IV implícitos. Esto impedía a los atacantes predecir el IV y explotar el encadenamiento de bloques de cifrado.
TLS 1.1 también mejoró la gestión de errores de los registros con relleno. En lugar de revelar errores de relleno específicos, devolvía una alerta genérica bad_record_mac. Estos cambios protegían contra BEAST (Browser Exploit Against SSL/TLS), descubierto años después, en 2011.
Se establecieron registros de parámetros IANA, lo que hizo que la gestión del conjunto de cifrado fuera más organizada. Pero la adopción fue lenta. Muchas organizaciones se saltaron TLS 1.1 por completo, esperando a las mejoras más sustanciales de TLS 1.2.
TLS 1.2 Flexibilidad mejorada (2008)
¿Cuándo se publicó TLS 1.2? En agosto de 2008, a través del RFC 5246. Esta actualización supuso los cambios más significativos desde SSL 3.0. El protocolo pasó de combinaciones MD5/SHA-1 codificadas a funciones pseudoaleatorias (PRF) especificadas por el tipo de cifrado. SHA-256 se convirtió en el nuevo estándar.
TLS 1.2 introdujo modos de cifrado autenticado con datos adicionales (AEAD), como AES-GCM y ChaCha20-Poly1305. Daba a las implementaciones flexibilidad a la hora de elegir algoritmos hash y de firma. Esta adaptabilidad resultó crucial a medida que evolucionaban las normas criptográficas.
El protocolo sigue estando muy extendido en la actualidad. Alrededor del 95,8% de los sitios web siguen soportando TLS 1.2, a menudo junto con TLS 1.3. En marzo de 2021, el IETF obvió conjuntamente TLS 1.0 y 1.1 mediante el RFC 8996, convirtiendo TLS 1.2 en el estándar mínimo aceptable.
¡Ahorra un 10% en Certificados SSL al hacer tu pedido en SSL Dragon hoy mismo!
Emisión rápida, encriptación fuerte, 99,99% de confianza del navegador, soporte dedicado y garantía de devolución del dinero en 25 días. Código del cupón: AHORRA10
TLS 1.3 – El estándar de seguridad moderno
Cinco años en desarrollo (2018)
TLS 1.3 tardó una década en llegar. El IETF publicó el RFC 8446 en agosto de 2018, tras 28 borradores y una amplia colaboración. La simplicidad y el rendimiento impulsaron el rediseño. El grupo de trabajo eliminó funciones heredadas, simplificó el apretón de manos y eliminó clases enteras de vulnerabilidades.
Google, Mozilla, Microsoft y Apple añadieron soporte rápidamente. En 2019, todos los principales navegadores podían negociar conexiones TLS 1.3. Cloudflare y otros proveedores de CDN lo activaron por defecto. La última versión de TLS no sólo mejoró la seguridad, sino que hizo que las conexiones cifradas fueran más rápidas.
Revolucionarias mejoras de seguridad
TLS 1.3 eliminó todo lo que estaba roto o debilitado. ¿Suites de cifrado SHA-1, MD5, RC4, DES y 3DES? Desaparecidos. ¿Intercambio estático de claves RSA y Diffie-Hellman? Eliminados. Ahora el protocolo exige secreto perfecto hacia adelante utilizando Diffie-Hellman efímero para todas las conexiones.
El apretón de manos cambió fundamentalmente. Todos los mensajes posteriores a ServerHello se cifran, ocultando la negociación de miradas indiscretas. La función de derivación de claves cambió a Extraer-y-Expandir basada en HMAC (HKDF), proporcionando mejores garantías criptográficas.
TLS 1.3 también introdujo el modo 0-RTT (tiempo de ida y vuelta cero). Los clientes pueden enviar datos cifrados en el primer mensaje a servidores previamente contactados, eliminando la latencia del handshake. La máquina de estados simplificada hizo que las implementaciones fueran menos propensas a errores. ECC pasó a la especificación base con nuevos algoritmos de firma como RSA-PSS.
Adopción y coexistencia actuales
¿Cuál es la última versión de TLS? TLS 1.3 ostenta ese título. Pero TLS 1.2 no va a ir pronto a ninguna parte. Las organizaciones necesitan tiempo para actualizar los servidores, probar la compatibilidad y actualizar el software cliente. La mayoría de los sitios preocupados por la seguridad ahora admiten ambas, dejando que los clientes elijan la mejor opción disponible.
La coexistencia funciona bien. Los servidores negocian la versión más compatible entre sí. Los clientes que no pueden manejar TLS 1.3 retroceden a TLS 1.2. Este enfoque de migración gradual evita los desastres de compatibilidad que plagaron las transiciones anteriores.
Errores comunes sobre el control de versiones SSL/TLS
Por qué no hay TLS 2.0
¿Cuál es la fecha de lanzamiento de TLS 2.0? No hay ninguna. TLS 2.0 no existe y nunca existirá. El IETF utiliza un versionado incremental: TLS 1.0, 1.1, 1.2, 1.3. La próxima versión, si llega, será TLS 1.4 o posiblemente TLS 2.0, pero saltar directamente a «TLS 2.0» después de SSL 3.0 habría causado una confusión masiva.
La gente suele esperar que los protocolos utilicen números de versión mayores (como el software que salta de la versión 1 a la 2). Pero los protocolos criptográficos evolucionan de forma más conservadora, y cada versión se basa en la anterior.
Terminología SSL vs. TLS
Pide un «certificado SSL» y obtendrás un certificado que funciona con TLS 1.2 y TLS 1.3. La industria sigue utilizando «SSL» en marketing porque resulta familiar. Aunque la versión actual de SSL es técnicamente inexistente (SSL terminó en la versión 3.0), el término se quedó.
Las autoridades de certificación como DigiCert y Sectigo venden «certificados SSL» que utilizan exclusivamente protocolos TLS. Es confuso pero inofensivo. Sólo recuerda: cuando alguien mencione SSL en 2026, casi seguro que se refiere a TLS.
El papel de las autoridades de certificación en la evolución SSL/TLS
Tipos de validación Desarrollo
Los primeros certificados SSL eran caros y lentos. La validación empresarial requería días o semanas de verificación manual. En 2002, GeoTrust introdujo Validación de Dominiosautomatizando el proceso mediante la verificación de la propiedad del dominio a través del correo electrónico o los registros DNS.
Los certificados deValidación Extendida llegaron en 2007, prometiendo la máxima garantía con barras de direcciones verdes en los navegadores. Let’s Encrypt se lanzó en 2015, ofreciendo certificados gratuitos de Validación de Dominio mediante emisión automatizada. Cloudflare le siguió con su propio programa de certificados gratuitos. Estos cambios democratizaron HTTPShaciendo accesible el cifrado a los pequeños sitios web.
Reducción del periodo de validez del certificado
Los periodos de validez de los certificados siguieron reduciéndose. Los requisitos básicos redujeron la validez máxima de cinco años a tres en 2015. En 2018, el límite pasó a ser de dos años. Safari de Apple impuso un máximo de un año en 2020, obligando a otros navegadores a seguirle.
Ahora el sector está presionando para que los ciclos de vida de los certificados sean aún más cortos. El Foro CA/Browser ha definido una clara reducción de los periodos de validez de los certificados: 200 días a partir del 15 de marzo de 2026,100 días a partir del 15 de marzo de 2027 y sólo 47 días para el 15 de marzo de 2029.
Este cambio hace inviable la gestión manual de certificados, empujando a las organizaciones hacia soluciones automatizadas como el Certificado como Servicio (CaaS) basado en ACME, donde la validación, emisión y renovación se gestionan automáticamente.
Hitos de la industria que dieron forma a la adopción de HTTPS
El impulso HTTPS de Google
En agosto de 2014, Google anunció HTTPS como señal de clasificación. Esta única decisión cambió la historia del SSL. Los webmasters que ignoraban el cifrado de repente tenían razones comerciales para preocuparse. En 2016, la mitad del tráfico web estaba cifrado.
Chrome 68 dio el siguiente paso en julio de 2018, marcando todos los sitios HTTP como «No seguros.» La advertencia aparecía en la barra de direcciones para cada página no cifrada. Hoy, más del 95% del tráfico web utiliza HTTPS. Google convirtió el cifrado de una práctica recomendada de seguridad en un requisito empresarial.
Evolución de los indicadores de seguridad del navegador
¿Recuerdas la barra de direcciones verde de la Validación Extendida? Ya no existe. Chrome la eliminó en 2020 después de que una investigación demostrara que los usuarios no la notaban ni la entendían. El propio icono del candado está desapareciendo, sustituido por indicadores neutros que normalizan el HTTPS en lugar de premiarlo.
Chrome 69 eliminó el texto «Seguro», dejando sólo el candado. Los navegadores actuales se centran en advertir sobre las conexiones inseguras en lugar de alabar las seguras. El mensaje: HTTPS es lo que se espera por defecto, no algo especial.
Principales vulnerabilidades de seguridad que impulsaron la evolución de los protocolos
Ataques notables a SSL/TLS
POODLE afectó a SSL 3.0 en 2014, explotando vulnerabilidades de padding oracle en modo CBC. Los atacantes podían descifrar cookies seguras degradando las conexiones y modificando repetidamente el texto cifrado. El ataque acabó con SSL 3.0 en cuestión de meses.
BEAST atacó TLS 1.0 en 2011, utilizando una debilidad CBC similar. Los atacantes podían descifrar las cookies HTTPS inyectando código en el lado del cliente y observando las respuestas cifradas. La solución requería implementar IVs explícitos en TLS 1.1.
BREACH abusó de la compresión HTTP en 2013. El ataque no tenía como objetivo el propio protocolo TLS, pero mostró cómo las decisiones de la capa de aplicación afectan a la seguridad. Heartbleed, descubierto en 2014, expuso un fallo crítico de OpenSSL que filtraba claves privadas y datos de usuario.
Lecciones aprendidas
Cada vulnerabilidad demostró el mismo punto: la retrocompatibilidad es peligrosa. Mantener vivos los protocolos antiguos para los sistemas heredados crea vectores de ataque. La industria aprendió a desaprobar agresivamente y forzar las actualizaciones.
Los investigadores de seguridad también merecen crédito. La divulgación pública de las vulnerabilidades aceleró las mejoras. Sin POODLE, SSL 3.0 podría estar aún hoy al acecho en las configuraciones de los servidores.
Futuro de los protocolos SSL/TLS
Criptografía postcuántica
Los ordenadores cuán ticos amenazan los algoritmos de cifrado actuales. RSA y la criptografía de curva elíptica podrían quedar obsoletos una vez que las máquinas cuánticas alcancen una escala suficiente. El NIST está normalizando algoritmos post-cuánticos diseñados para resistir los ataques cuánticos.
TLS necesitará actualizaciones para soportar estos algoritmos resistentes a la cuántica. La transición no será fácil, la criptografía post-cuántica utiliza claves más grandes y enfoques matemáticos diferentes. Pero la evolución del protocolo que nos llevó de SSL 2.0 a TLS 1.3 demostró que la comunidad puede manejar transiciones importantes.
Tecnologías emergentes
DTLS (Datagram Transport Layer Security) extiende TLS a las conexiones UDP. QUICdesarrollado por Google y estandarizado por el IETF, integra el cifrado directamente en la capa de transporte. Estos protocolos se basan en los fundamentos criptográficos de TLS, al tiempo que se adaptan a diferentes casos de uso.
Alternativas basadas en la cadena de bloques, como Remme, experimentan con la PKI distribuida. Las autoridades de certificación siguen evolucionando, automatizando más procesos y admitiendo periodos de validez más cortos. ¿Qué vendrá después de TLS 1.3? Probablemente mejoras incrementales en lugar de un rediseño completo. TLS 1.3 hizo bien la mayoría de las cosas.
Mantente al día con los certificados SSL Dragon preparados para TLS 1.3
Comprender la evolución de los protocolos es una cosa. Implementar estándares de cifrado modernos es otra. SSL Dragon proporciona certificados digitales totalmente compatibles con TLS 1.3 y TLS 1.2, que admiten los últimos protocolos criptográficos y suites de cifrado.
Ofrecemos una emisión rápida, un cifrado potente y un 99,99% de confianza del navegador mediante asociaciones con las principales autoridades de certificación, como DigiCert, Sectigo y GeoTrust. Nuestras soluciones automatizadas de gestión de certificados te ayudan a gestionar los próximos ciclos de vida de 47 días sin molestias de renovación manual.
¿Estás migrando desde protocolos obsoletos? Nuestro equipo de asistencia te guiará durante la transición. Cada compra incluye una garantía de devolución del dinero de 25 días. Explora nuestra cartera de certificados hoy mismo y protege tu infraestructura con la última versión de TLS.
Ahorre un 10% en certificados SSL al realizar su pedido hoy mismo.
Emisión rápida, cifrado potente, 99,99% de confianza del navegador, asistencia dedicada y garantía de devolución del dinero en 25 días. Código del cupón: SAVE10
