Resumen

  • En diciembre de 1994, Netscape ya presentaba SSL como parte de su Commerce Server; un historial técnico posterior dice que Navigator 1.0 admitía SSL 2.0.
  • SSL 3.0 quedó como un Internet-Draft caducado en noviembre de 1996; la referencia histórica estable del IETF no llegó hasta el RFC 6101 de 2011.

La primera prueba no es un estándar. En diciembre de 1994, Netscape anunció Navigator 1.0 y su línea de servidores Netsite. El comunicado de la época describió Commerce Server como un producto que incorporaba Secure Sockets Layer, basado en la tecnología de RSA Data Security, y presentó el conjunto cliente-servidor como apto para el comercio por Internet. Es una afirmación de lanzamiento de la empresa, no un recuento independiente de instalaciones. Aun así, sitúa SSL dentro de un producto comercial ofrecido al público antes de que el registro normativo tuviera una referencia duradera.

Un historial posterior del código de seguridad de Netscape aporta un detalle de versión que el anuncio no da: Navigator 1.0 admitía SSL 2.0 y Navigator 2.0 añadió SSL 3.0. El mismo relato dice que el código de seguridad se adaptó a los servidores Netscape 2.0. Es un recuerdo técnico de primera parte, no un censo de entregas; complementa el anuncio fechado sin sustituirlo.

Los documentos de 1995 muestran el paso a una descripción técnica pública. Una copia archivada identifica «The SSL Protocol», de Kipp Hickman y Taher Elgamal, como un Internet-Draft de junio de 1995. Un borrador de febrero conservado por Mozilla explica SSL como una capa independiente del protocolo de aplicación: un intercambio inicial negocia parámetros criptográficos y autentica el servidor antes de que fluyan los datos de la aplicación. Estos textos describen un comportamiento implementable. Su condición de borrador no los convertía en un estándar aprobado de Internet ni garantizaba la interoperabilidad entre todas las implementaciones.

SSL 3.0 muestra la diferencia con especial claridad. IETF Datatracker registra draft-ietf-tls-ssl-version3-00 como un Internet-Draft caducado, actualizado por última vez el 21 de noviembre de 1996 y sin estado RFC previsto. El texto está fechado el 18 de noviembre. En 2011, el RFC 6101 publicó esa versión como registro histórico. Su prólogo dice que SSL 3.0 se había implementado ampliamente y sirvió de base para TLS, pero que el IETF nunca lo había publicado formalmente salvo mediante varios borradores expirados. El RFC creó una referencia estable; no convirtió retroactivamente SSL 3.0 en un estándar de seguimiento.

Esta cronología no implica que SSL careciera de especificaciones ni que las organizaciones de estándares no participaran. Cada registro responde a una pregunta distinta. Un anuncio de producto establece qué ofrecía una empresa; un historial del código informa qué admitía una familia de clientes; un borrador permite examinar y revisar un protocolo; un RFC publicado ofrece un texto citable a largo plazo y declara su estado. Ninguna fuente demuestra por sí sola el despliegue universal ni un comportamiento idéntico.

Por eso conviene no reducir la adopción a un solo momento. Una implementación funcional puede atraer usuarios antes de una especificación estable. Un borrador puede mejorar la interoperabilidad sin certificarla. Y un RFC histórico posterior puede hacer legible un protocolo antiguo sin respaldar su seguridad ni su uso actual. En SSL, el producto, el texto de trabajo y la cita duradera llegaron en calendarios distintos.