- En medio de la competencia entre navegadores de Netscape y Microsoft a mediados de los años 90, surgió el protocolo SSL
- SSL 2 tenía fallas criptográficas y prácticas, y a partir de eso Microsoft introdujo el protocolo PCT
- Como respuesta, Netscape desarrolló SSL 3.0 para intentar recuperar la iniciativa
- La industria y la comunidad querían mantener la compatibilidad entre navegadores, así que delegaron a la IETF el papel de estandarización
- En ese proceso, el nombre del protocolo cambió a TLS 1.0 y así se ha mantenido hasta hoy
Contexto: competencia entre navegadores y nacimiento de los protocolos de seguridad
- A mediados de los años 90, Netscape y Microsoft mantenían una competencia feroz en el mercado de los navegadores
- En ese contexto competitivo, Netscape terminó desarrollando el protocolo SSL
SSL 2 y sus problemas
- La primera versión de SSL no se lanzó porque quedó invalidada de inmediato por fallas criptográficas
- SSL 2, que sí se distribuyó, se usó durante algunos años, pero tenía varias fallas criptográficas y prácticas
- Aunque estos defectos no representaban una crisis crítica inmediata, la necesidad de mejorarlo siguió señalándose constantemente
La respuesta de Microsoft: el protocolo PCT
- En medio de una competencia cada vez más intensa, Microsoft añadió funciones propias a SSL 2 e introdujo un protocolo llamado PCT
- PCT solo era compatible con Internet Explorer (IE) e IIS
La nueva estrategia de Netscape: SSL 3.0
- Netscape también quería corregir los problemas de SSL 2, pero no quería que Microsoft tomara el control de la iniciativa
- Por eso desarrolló SSL 3.0, buscando cambios claramente diferenciados respecto a lo anterior
Negociaciones de estandarización en la industria del navegador
- La industria y los miembros de la comunidad no querían que el protocolo se dividiera en dos (evitar una bifurcación)
- En Consensus Development (donde trabajaba el autor) se encabezó una reunión entre representantes de Netscape y Microsoft
- A esa reunión asistieron Bruce Schneier (antes de hacerse famoso), Paul Kocher (diseñador de SSL 3) y Barbara Fox (representante de Microsoft), entre otros
Estandarización en la IETF y cambio de nombre
- Tanto Netscape como Microsoft acordaron que la IETF (Internet Engineering Task Force) liderara el proceso de estandarización del protocolo
- El autor estuvo a cargo de editar el documento estándar de la IETF (RFC)
- Como parte de un compromiso político, había que hacer algunos cambios a SSL 3.0 y también darle un nombre nuevo (para evitar la impresión de que la IETF simplemente estaba “aprobando sin más” un protocolo ya existente)
- Como resultado nació el nombre TLS 1.0, aunque en la práctica corresponde a SSL 3.1
Cierre
- Viéndolo ahora, todo este proceso de discusión sobre el nombre y la estandarización se siente algo ridículo
1 comentarios
Comentarios de Hacker News
Explicación de por qué es una situación confusa en la que solo viendo los números de versión es difícil entender cuánto cambió realmente el protocolo. SSLv2 fue la primera versión de SSL de uso amplio, pero tenía varios problemas. SSLv3 fue un protocolo rehecho casi por completo. TLS 1.0 era muy parecido a SSLv3, pero durante el proceso de estandarización en la IETF se hicieron algunas revisiones menores. TLS 1.1 fue una versión con ajustes pequeños para corregir problemas en la forma de usar cifrados por bloques en TLS 1.0. TLS 1.2 introdujo cambios de tamaño intermedio para adaptarse a los avances en criptografía, incluyendo soporte para hashes más modernos (como respuesta a las vulnerabilidades de MD5 y SHA-1) y para suites AEAD (como AES-GCM). TLS 1.3 es en gran parte un protocolo nuevo, aunque incorpora algunas características de TLS 1.2 y anteriores. Cada protocolo fue diseñado con negociación automática de versión para que clientes y servidores pudieran actualizarse de forma independiente sin perder conectividad.
Considerando que Microsoft en esa época era una empresa completamente distinta a la de hoy, no suena nada raro incluso bajo estándares actuales. En ese entonces "M$" usaba todos los medios posibles para frenar las tecnologías abiertas de internet, y esa actitud continuó incluso hasta comienzos de la década de 2010. Pienso que eso también contribuyó a que los Java Applets no pudieran evolucionar y terminaran fuera del mercado. También se sentía que el avance de JavaScript y CSS fue lento durante años. En mi empresa me exigían usar las tecnologías más recientes compatibles con IE, pero yo elegí Mozilla 3.0, y después de corregir bugs de JS empecé a usar Mozilla para desarrollo de SPA empresariales. Más adelante, incluso en empresas Fortune 500 se expandió el uso interno de Mozilla/Firefox, y al final recuerdo que fue una buena decisión.
Opinión de que quizá no habría problema en volver a usar SSL para el nombre de la próxima versión. Argumenta que, dado que todo el mundo sigue usando el nombre "SSL", se podría seguir usando sin inconveniente.
También menciona que el nombre "TLS" ya se usa en muchos otros contextos. Actualizar configuraciones y firmas de funciones es bastante molesto, así que da para pensarlo.
Subraya que no quiere darle ideas a nadie con este comentario.
Cuando le indicas a alguien que haga más segura la conexión a un sitio web (o sea, cuando usas la terminología TLS/SSL), pregunta qué nombre suelen usar. También añade que le da curiosidad saber qué edad tienen y si trabajaban antes de 1999. Dice que pronto publicará su propia respuesta.
Yo digo SSL (tengo 27). En el código, en cambio, uso
tls, y en documentación prefiero escribir SSL/TLS para evitar confusiones.sslCertNotBefore. Tal vez sea porque normalmente los programadores no tratan TLS de manera directa. Mi código también tenía que parsear información de certificados en HTTPS, así que fue bastante engorroso. Gracias a toda la automatización y abstracción se puede manejar sin errores, pero también hay un lado en el que eso termina obstaculizando una comprensión profunda de cómo funciona TLS.Mucha gente usa el término SSL porque implementa comunicaciones seguras con bibliotecas cuyo nombre incluye ssl, como OpenSSL. Además de OpenSSL, existen bibliotecas como BoringSSL, LibreSSL y wolfSSL. Las bibliotecas con TLS en el nombre son menos conocidas; por ejemplo GnuTLS, mbedTLS, s2n-tls y RustTLS.
La razón principal por la que uso el término SSL es que parece entenderse mejor. Estrictamente hablando, TLS es lo correcto (de hecho, nadie usa ya SSL 3.0), pero como el término SSL sigue en la biblioteca más representativa, se sigue usando. En realidad, aprendí el nombre SSL durante las crypto wars de los 90, y como recuerdo que en ese tiempo había que descargar ilegalmente la versión de Netscape "US only" para tener cifrado SSL de verdad, creo que lo sigo usando simplemente por costumbre.
Yo normalmente digo "https". Me gusta porque incluso la gente común suele entender más o menos lo que significa.
De hecho, es la primera vez que me doy cuenta de que no estaba distinguiendo correctamente entre SSL y TLS de manera inconsciente. Es curioso descubrir la razón real después de 20 años.
"Transport Layer Security" definitivamente parece un nombre mejor. También prefiero decir TLS. Incluso me da risa porque pronunciar dos veces seguidas la S suena como una serpiente.
Pero TLS ya se usa mucho también para "Thread Local Storage". Aunque Transport Layer Security se volvió oficial desde 1999, Thread Local Storage ya existía antes de 1996 en entornos de desarrollo de MS o IBM. En el mundo Unix, también hubo cierta preferencia por el término thread-specific data desde la aparición de pthread en 1995. Quizá la difusión del término "TLS" se vio impulsada además por el documento del ABI de Itanium de 2001, y puede que Sun Microsystems también ya lo estuviera usando. Si alguien tiene manuales de OS/2, sería bueno que compartiera referencias.
A mí me parece que en realidad SSL le queda mejor como nombre. En teoría, TLS debería ser una medida de seguridad general que funcione en varias capas (por ejemplo, hasta podría integrarse con IPSec), pero en la práctica se usa sobre todo solo para sockets TCP. Existen la variante UDP, DTLS, y QUIC, pero no forman parte de TLS en sí. Más recientemente hay Linux kernel TLS e infraestructura específica de Windows, pero no es algo que se aplique tan fácil como activar una bandera de socket. Y, sinceramente, el sonido de esa S tipo "serpiente" está padre.
"SSL" es más fácil de pronunciar que "TLS". Al decir S-S-L, la lengua casi no se mueve de posición, así que sale más rápido y natural.
Quedaría bien que Kaa de El libro de la selva hablara del nombre S~S~L en un tema sobre seguridad en TCP. De hecho, hasta estaría divertido agregarle otra S y llamarlo SSSL.
La gente que distingue estrictamente entre TLS y SSL suele querer mostrar que conoce bien la diferencia, o le gusta que se hable así. La distinción en sí se parece un poco a la diferencia entre .doc y .docx: técnicamente sí son distintos, pero para la mayoría de los usuarios son casi compatibles. La mayoría solo quiere que HTTPS funcione bien y no presta mucha atención a la estructura interna ni al modo en que opera.
Enlace relacionado: comparte un texto de 1996 llamado 'Randomness and the Netscape Browser' (Dr. Dobb's Journal) https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.html. Como es un texto de 1996, el tono del lenguaje se siente muy distinto al de papers o artículos modernos. Se siente viejo.
Pregunta si TLS 1.0 no tuvo en realidad bastantes mejoras respecto de SSL 3.0. Dice que en el artículo parece describirse solo como "un pequeño ajuste para marcar diferencia", y por eso le da curiosidad.
En internet todavía hay más de 300 mil servicios que soportan SSLv2. Enlace: https://shodan.io/search/report/…. Gráfica de tendencia: https://trends.shodan.io/search?query=ssl.version%3Asslv2#overview. Aunque la cifra ha bajado mucho con los años, parece que todavía hará falta tiempo para que desaparezca por completo.