El problema principal es probablemente que un IE de esa era quisiera admitir SSL 2.0 y, por lo tanto, envía su mensaje inicial ( ClientHello ) en formato SSL 2.0, que no tiene nada en común con el ClientHello de versiones posteriores del protocolo (SSL 3.0 y todas las versiones TLS). Eso permitió que el navegador se conectara a un servidor que conocía SSL 2.0 pero nada más, mientras que ClientHello todavía documenta que el cliente está listo para usar algo más moderno.
Sin embargo, los servidores modernos ya no admiten el formato SSL-2.0 ClientHello . Ha habido un período transitorio durante el cual todavía aceptaron ese formato (aunque no permitirían que la conexión realmente usara SSL 2.0), pero ahora abandonaron el soporte por completo. En particular, el formato SSL-2.0 ClientHello no tiene espacio para extensiones como SNI, lo que explica la necesidad de eliminar dicho soporte.
Otras cuestiones incluyen las siguientes:
-
IE 6.0 admite TLS 1.0 pero está desactivado de forma predeterminada. No sé si IE 5 habría soportado TLS 1.0, pero en cualquier caso no se habría habilitado de forma predeterminada. Sin embargo, muchos servidores modernos rechazan también SSL 3.0 (debido a POODLE, como lo señaló @etherealflux).
-
El código del cliente no sabrá nada de AES, ya que data de antes de la estandarización de ese algoritmo. Intentará utilizar conjuntos de cifrado basados en RC2, 3DES, posiblemente RC4 (esto requeriría cierta verificación porque RC4 era propiedad de Nemesis, el Netscape de IE, por lo que posiblemente IE 5 no lo usaría). Estos algoritmos no son muy populares entre los administradores de servidores en la actualidad ...
-
Los sitios modernos utilizan claves criptográficas bastante grandes. Típicamente, RSA con claves de al menos 2048 bits. Un antiguo Windows + IE podría ser más limitado en el tamaño de las claves RSA que puede manejar. En particular, un Windows + IE que cumpla con las normas de exportación de EE. UU. Sobre criptografía de la era anterior a 2000 podría estar limitado a un tamaño máximo de 1024 bits para claves RSA. La misma combinación también se negaría a usar 3DES o cualquier cosa con una clave simétrica superior a 56 bits, mientras que ningún servidor decente de 2015 aceptaría nada menos que 128 bits.
Para los sistemas basados en Linux, no hay implementación central de SSL (a menudo hay una biblioteca OpenSSL, pero no es algo tan generalizado como SChannel y CryptoAPI de Microsoft). Así que cada navegador tendrá sus propias reglas. Antes del año 2000, esto habría significado a Nestcape Navigator (el que se salta cuando se ve algo en UTF-8 ...). ¿Tal vez algún navegador temprano basado en KDE podría hacer algo de SSL? En ese caso, probablemente usaría OpenSSL y que aún debería poder conectarse a algunos servidores, con la configuración correcta (en particular si se evita el formato SSL-2.0 para el ClientHello ).