Por qué SSL cambió de nombre a TLS a fines de los 90

• A mediados de la década de 1990, en medio de la guerra de los navegadores, creció la posibilidad de que SSL de Netscape y PCT de Microsoft se separaran, por lo que la industria intentó unificarlos en un único estándar abierto.
• El SSL inicial no llegó a lanzarse por sus fallas, y SSL 2, la primera versión de uso real, se usó durante algunos años, pero tenía limitaciones criptográficas y prácticas.
• PCT de Microsoft era una extensión propia basada en SSL 2 y adaptada a IE e IIS, y Netscape respondió con SSL 3.0 para no perder el liderazgo del estándar.
• Netscape y Microsoft acordaron seguir el proceso abierto de estandarización del IETF, pero era necesario evitar que pareciera que el IETF simplemente ratificaba el protocolo de Netscape tal cual.
• Al final, SSL 3.0 recibió algunos cambios y también cambió de nombre; TLS 1.0 partió, en la práctica, como algo cercano a SSL 3.1.

---

SSL y PCT en la guerra de los navegadores

• A mediados de la década de 1990, la competencia entre los navegadores de Netscape y Microsoft también influyó en la estandarización de los protocolos de seguridad.
• Netscape desarrolló el protocolo SSL.
  • La versión inicial fue vulnerada rápidamente por fallas criptográficas y no se lanzó.
  • La primera versión de producción fue SSL 2, que se usó durante algunos años.
  • SSL 2 tenía fallas criptográficas y prácticas, pero no representaba una crisis tan dramática como para requerir un reemplazo inmediato.
• Microsoft modificó SSL 2 y agregó elementos propios para definir PCT.
  • PCT era un protocolo derivado de SSL 2.
  • Su soporte estaba limitado a IE e IIS.
• Netscape también intentó corregir los problemas de SSL 2, pero no quería que Microsoft asumiera el liderazgo o la propiedad del estándar.
  • Como resultado, desarrolló SSL 3.0, con cambios más importantes.

Estandarización en el IETF y el nombre TLS

• Varias personas de la industria y la comunidad buscaban evitar que el protocolo se bifurcara.
• Consensus Development organizó una reunión entre representantes de Netscape y Microsoft.
  • Tim Dierks trabajaba entonces en Consensus Development junto con Christopher Allen.
  • Bajo contrato con Netscape, escribió la implementación de referencia de SSL 3.0.
  • Bruce Schneier asistió a la reunión; probablemente también asistió Paul Kocher, quien diseñó el protocolo SSL 3, y Microsoft estuvo representada por Barbara Fox.
• Como resultado de la negociación, Microsoft y Netscape aceptaron que el IETF asumiera el protocolo y lo estandarizara mediante un proceso abierto.
  • Este proceso derivó en que Tim Dierks editara el RFC.
• Durante la estandarización, se hicieron algunos cambios a SSL 3.0.
  • El objetivo era evitar que pareciera que el IETF simplemente respaldaba el protocolo de Netscape.
  • Por la misma razón, también se cambió el nombre del protocolo.
• El TLS 1.0 que nació así fue, en realidad, una versión cercana a SSL 3.1.

[GN⁺]

Opiniones en Hacker News

• Los números de versión no reflejan bien las diferencias entre protocolos, así que generan más confusión.
  SSLv2 fue el primer SSL ampliamente desplegado, pero tenía muchos problemas, y SSLv3 era casi un protocolo nuevo.
  TLS 1.0 se parece a SSLv3, pero recibió algunos ajustes durante el proceso de estandarización del IETF, y TLS 1.1 fue una revisión muy pequeña que corrigió problemas en la forma de usar cifrados de bloque.
  TLS 1.2 fue una revisión de tamaño medio que, en respuesta a las debilidades de MD5 y SHA-1, agregó nuevos hashes y suites de cifrado AEAD como AES-GCM; TLS 1.3 reutiliza algunos elementos anteriores a TLS 1.2, pero en su mayor parte se acerca a un protocolo nuevo.
  Todos estos protocolos fueron diseñados para poder negociar automáticamente la versión, de modo que clientes y servidores pudieran actualizarse de forma independiente sin perder conectividad.

  • TLS 1.0 introdujo modularidad mediante el concepto de “extensiones”, así que es difícil verlo como una evolución menor.
    Una de ellas fue session tickets, que permitió la reanudación de sesiones del lado del servidor sin mantener estado sincronizado entre servidores, y otra fue Server Name Indication, que permitió que un servidor usara más de un certificado.
  • La negociación automática de versiones también permitió durante décadas varios ataques de downgrade.
  • Deberían haberlo llamado simplemente TLS v4.0, no TLS 1.0.
    Que las versiones posteriores hayan sido v1.1, v1.2 y v1.3 también parece una terquedad por no querer admitir que resetear el número de versión fue objetivamente un error.
  • Aun así, al menos no usaron números de año para las versiones.

• En esa época Microsoft era una bestia completamente distinta, así que la confusión de nombres SSL/TLS no se siente tan extraña.
  El M$ de aquellos años intentaba controlarlo todo, y creo que no dejó de intentar frenar las tecnologías abiertas de Internet hasta principios de la década de 2010.
  Logró matar los Java Applets, y creo que también hizo que JavaScript y CSS en general se atrasaran varios años.
  A principios de los 2000, en mi empresa nos presionaban para soportar las últimas “tecnologías” de IE, pero en cuanto se corrigieron bugs clave de JS empezamos a soportar Mozilla 3.0, y más tarde resultó ser una buena decisión cuando una empresa Fortune 500 empezó a usar Mozilla/Firefox en apps internas mucho antes de que se volviera algo común.

  • No creo que Microsoft haya matado los Java Applets.
    Siempre funcionaron en IE, y ese era prácticamente el único canal donde Microsoft podía influir.
    Los Applets fracasaron al convertirse en el ejemplo típico de “Java es lento”; aunque en general eso no fuera necesariamente cierto, sí lo era para los Applets por la espera de descarga y la espera de arranque de la JVM.
    Al final HTML/JS empezó a hacer mejor las funciones dinámicas que antes requerían Applets, y Flash se quedó con las áreas restantes donde HTML no alcanzaba, así que desaparecieron.
  • Los Applets murieron por muchas razones.
    Incluso para una animación trivial, el tiempo de arranque del JRE era absurdamente largo; para la época, los requisitos de memoria y los cuelgues también eran graves, y los problemas de compatibilidad de las primeras versiones de la plataforma Java eran raros.
    El modelo de seguridad basado en asumir que cualquier actor capaz de obtener un certificado CA sería bueno también era ridículo, y la tecnología de sandbox de los navegadores en general, no solo de IE, aún era inmadura.
  • Creo que el apodo “M$” queda mejor hoy en día.
  • Microsoft no ha cambiado tanto, salvo que su departamento de relaciones públicas mejoró.
  • Amazon también tenía https://github.com/aws/s2n-tls.
    Había muchas expectativas sobre s2n, pero parece que fuera de AWS no logró consolidarse mucho.

• Quien distingue con fuerza entre TLS y SSL sabe cuál es la diferencia y asume que la otra persona también debería saberla, pero en la práctica es parecido a la diferencia entre .doc y .docx.
  Son fundamentalmente distintos, pero para los usuarios comunes parecen intercambiables, y en el terreno a la mayoría le importa si HTTPS funciona, no tanto cómo funciona por dentro.

  • La principal dificultad era explicarles a los usuarios comunes que TLSv1.0 es más nuevo y mejor que SSLv2/SSLv3.
    Recuerdo haber discutido bastante con gente que pensaba que un número más grande significaba algo mejor.
  • Aunque SSL fue descartado hace mucho, la gente sigue usando SSL como nombre para referirse al tráfico de red cifrado.
    Sería mucho más fácil llamar TLS a todo el tráfico de red cifrado moderno, y decir SSL solo cuando realmente se use SSL por culpa de sistemas legacy.

• Acabo de darme cuenta de que mi cabeza, de forma inconsciente, tenía problemas para distinguir SSL de TLS.
  Recién después de 20 años entiendo por qué.

  • A mí me pasa igual.
    Después de 15 años en esta industria recién entendí bien que ssl y tls son lo mismo, y me siento como un tonto.
  • Me enteré alrededor de 2010, pero antes tampoco lo sabía.
    Lo que me hizo darme cuenta fue que en Java, incluso si hoy se usa TLSv1.3, para iniciar una conexión cifrada se sigue usando SSLSocket.

• “Transport Layer Security” sí es un mejor nombre.
  También suena bien decir “TLS”, mientras que SSL, con dos eses seguidas, suena como serpiente.

  • El problema es que TLS ya se usaba ampliamente como sigla de thread local storage.
    Está ampliamente documentado que Transport Layer Security empezó en 1999, y hay materiales sobre “Thread Local Storage” que se remontan al menos a 1996.
    En ese entonces era un término más común del lado de Microsoft, o quizá de IBM/OS/2, mientras que en Pthreads y Unix en general se tendía a decir “thread-specific data”.
    El documento del ABI de Itanium de 2001 quizá difundió más el término en el mundo Unix más amplio, pero parece que Sun también lo usaba desde antes en Solaris y Java.
  • Más bien creo que SSL es un nombre más adecuado.
    En teoría, TLS podría ser un mecanismo de seguridad de capa de transporte sobre el que se montara cualquier protocolo, como IPSec, pero en la práctica está casi atado a sockets TCP.
    La variante para UDP, DTLS, o QUIC tampoco son parte de la especificación TLS, y aunque existen kernel TLS en Linux e infraestructura similar en Windows, no es tan fácil como activar TLS con una simple bandera de socket.
  • “SSL” es más fácil de pronunciar que “TLS” porque la posición de la lengua casi no cambia entre las tres letras.
  • El mejor nombre es el que apareció primero y quedó establecido.

• Me da curiosidad qué suele decir la gente cuando le dice a alguien que debe conectarse de forma segura a un sitio web, o en situaciones donde usaría el término TLS/SSL

  1. si dice SSL o TLS
  2. qué edad tiene, o si trabaja desde antes de 1999
  • Normalmente digo SSL
    Durante mucho tiempo ni siquiera supe que TLS era “lo mismo”, y ahora que lo sé, 9 de cada 10 veces sigo diciendo SSL
    Tengo 38 años y empecé a trabajar en 2011, pero hice programación de redes por primera vez alrededor de 2004~2005
    Acabo de mirar otra pantalla y vi que una función a la que le agregué un if hace unos minutos también se llamaba sslCertNotBefore
    Creo que parte del problema es que los programadores normalmente no tratan directamente con TLS
    Construí un sistema que extraía información detallada de certificados en conexiones HTTPS, y fue bastante trabajoso sacar de la biblioteca estándar de Java la información que necesitaba
    Si se maneja automáticamente y de forma invisible, es difícil equivocarse, pero esa caja negra no ayuda mucho a que se difunda una comprensión profunda de cómo funciona realmente TLS
  • Parece que la razón por la que la mayoría lo llama SSL es que los nombres de las bibliotecas que manejan comunicaciones seguras incluyen SSL
    Están OpenSSL, la más dominante, además de BoringSSL, LibreSSL, wolfSSL, etc.
    Entre las bibliotecas que llevan TLS en el nombre están GnuTLS, mbedTLS, s2n-tls y RustTLS, pero se usan relativamente menos
  • Normalmente digo SSL
    Es más probable que se entienda que TLS, que es más preciso, y ya nadie usa SSL 3.0 real
    También aparece SSL en los nombres de bibliotecas clásicas como OpenSSL
    Aunque quizá sea una costumbre de la época de las guerras criptográficas de los años 90, cuando aprendí SSL y, para usar cifrado SSL de verdad, había que conseguir la versión “US only” de Netscape
  • Normalmente digo “https”
    Porque a veces incluso la gente común sabe qué significa
  • Últimamente digo cada vez más “TLS”, pero hasta hace apenas 1 o 2 años casi siempre decía “SSL”
    Aun así, a veces se me escapa SSL
    Tengo 51 años y empecé a trabajar en IT a mediados de los 90

• Me parece que TLS 1.0 incluía mejoras bastante importantes respecto de SSL 3.0
  Leyendo el artículo, parece que solo hubieran cambiado unas pocas cosas para que se viera diferente

  • La principal diferencia está en el padding
    Cuando se preanunció que el ataque POODLE solo afectaba a SSL3 y no a TLS1.0, solo con esa información ya se podía predecir que sería un oráculo de padding
    Ambos son bastante parecidos, y es justo decir que incluyeron algunas “correcciones de bugs”
    Fue hace mucho, así que quizá haya olvidado algunas cosas, y como SSL3 y TLS1.0 siempre se implementaban juntos, puede que se me hayan pasado detalles
  • Los cambios fueron pequeños, más pequeños que en cualquier otra revisión de versión
    En general, fue más bien que la IETF no aprobó tal cual el protocolo SSL 3.0 e hizo algo de marcar territorio
  • Sin duda hubo cambios y mejoras significativas, pero no fue un rediseño completo como SSL 3.0

• Como artículo relacionado está “Randomness and the Netscape Browser”, de Dr. Dobb's Journal, enero de 1996
  https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.ht...
  Es un texto escrito en 1996, y el lenguaje usado ya se siente bastante distinto al de las publicaciones actuales, lo que me hace sentir viejo

  • Depende de qué publicaciones leas
    Igual que en 1996, hoy artículos como los de LWN [1] se leen con un estilo bastante parecido
    Aunque quizá apunten a un público un poco más general y sean algo menos rígidos
    [1] https://lwn.net/
  • Los autores de ese artículo encontraron ese problema de seguridad y también salieron en la portada de The New York Times: https://www.nytimes.com/2012/02/15/technology/researchers-fi...

• Recuerdo que “SSL and TLS: Designing and Building Secure Systems”, de Eric Rescorla, fue realmente útil para entender la historia de TLS y cómo llegó hasta donde está hoy
  Es un libro de 2001, pero ya advertía sobre algunos problemas que luego se convirtieron en CVE, y se puede conseguir usado por unos pocos dólares

• Para alrededor de 2014, creo que el consenso de que SSL 2.0 tenía fallas graves ya era muy firme
  Ni siquiera el handshake estaba autenticado correctamente