34

Recently I found an old installation CD for Windows 98 Second Edition, and looking for a bit of a nostalgia kick, I installed it inside VirtualBox. Win98SE shipped with IE 5.0, and browsing the web with that browser was as broken an experience as you might imagine.

I noticed that, no matter what I tried, I could not get IE to connect to any, any HTTPS site. And it got me wondering why that was. Are all the trusted CA certificates it shipped with expired? Were all the default TLS/SSL algorithms phased out over the last 16 years? Did it need the IE High Encryption Pack (wow, it's been forever since I've thought about that).

I'm curious if this would affect other operating systems of that era (Mandrake 6!) or if the core issue is somehow Windows-specific.

  • 2
    It is most likely the same reason that GitHub doesn't work on IE on Windows XP anymore, outdated SSL ciphers: github.com/blog/1937-improving-github-s-ssl-setup – rink.attendant.6 Aug 4 '15 at 14:36
  • 3
    If you are desperate to use this browser for a specific reason you can run a local proxy. (Caveats Apply) – JamesRyan Aug 4 '15 at 16:46
  • 3
    Many of the early CA roots had validity periods of 30 years or more, and are not expired. They are obsoleted in that practically all certs valid today (and issued in the last few years) are under newer roots. However, some can still chain back to old roots; for example when Verisign went to "Generation 5" in 2006 and it initially wasn't in most clients, they provided a bridge root back to their initial 1996 root and I've seen servers still providing the obsolete bridge in the last year or so. You might see how much ssllabs.com/ssltest/viewMyClient.html screams. – dave_thompson_085 Aug 5 '15 at 3:59
  • You may use some transparent (or not so transparent) proxy configured by you, making the https sites usable. You also need to become your own CA. It is a lot of work, but it could work (also big company networks eavesdrop https traffic on this way). – peterh Jun 15 '18 at 23:42
37

The main problem is probably that an IE from that era would like to support SSL 2.0, and, therefore, sends its initial message (ClientHello) in SSL 2.0 format, which has about nothing in common with the ClientHello of later protocol versions (SSL 3.0 and all TLS versions). That allowed the browser to connect to a server that knew SSL 2.0 but nothing else, while the ClientHello still documents that the client is ready to use something more modern.

However, modern servers no longer support the SSL-2.0 ClientHello format. There has been a transitory period during which they still accepted that format (even though they would not allow the connection to actually use SSL 2.0), but now they dropped the support altogether. Notably, the SSL-2.0 ClientHello format has no room for extensions like SNI, which explains the urge to drop such support.

Other issues include the following:

  • IE 6.0 supports TLS 1.0 but it is deactivated by default. I don't know if IE 5 would have supported TLS 1.0, but in any case it would not have been enabled by default. However, many modern server reject SSL 3.0 as well (because of POODLE, as was noted by @etherealflux).

  • The client code will know nothing of AES, since it dates from before the standardization of that algorithm. It will try to use cipher suites based on RC2, 3DES, possibly RC4 (this would require some verification because RC4 was the property of IE's nemesis, Netscape, so possibly IE 5 would not use it). These algorithms are not a lot popular among server admins nowadays...

  • Modern sites use rather large cryptographic keys. Typically, RSA with keys of at least 2048 bits. An old Windows+IE might be more limited in the size of RSA keys that it can handle. In particular, a Windows+IE that would comply with the US export rules on cryptography of the pre-2000 era could be limited to a maximum size of 1024 bits for RSA keys. The same combination would also refuse to use 3DES or anything with a symmetric key larger than 56 bits, while no decent server of 2015 would accept anything less than 128 bits.

For Linux-based systems, there is no central SSL implementation (there is often an OpenSSL library, but not something as pervasive as Microsoft's SChannel and CryptoAPI). So every browser will have its own rules. Before 2000, this would have mean Nestcape Navigator (the one that segfaults when it sees anything in UTF-8...). Maybe some early KDE-based browser could do some SSL ? In that case, it would probably use OpenSSL and that should still be able to connect to some servers, with the right configuration (in particular if avoiding SSL-2.0 format for the ClientHello).

  • modern servers no longer support the SSL-2.0 ClientHello format [citation needed] ssllabs.com/ssltest/… - SSL 2 handshake compatibility Yes – Cthulhu Aug 4 '15 at 17:03
  • @Cthulhu Google is probably the only major company that still accepts it, given that it's being used as the gateway to the internet. – Nzall Aug 4 '15 at 20:18
  • Interesting tidbit: of the recent major browsers, only IE, Safari and (presumably) Edge use SChannel. Firefox uses NSS. Chrome used SChannel with the very first few releases, then switched to NSS, then switched to BoringSSL (Google's own lib based on OpenSSL/LibreSSL). – Bob Aug 5 '15 at 1:45
  • Minor: RC4 was claimed trade secret by then-RSA Data Security (now a division of EMC), who tried to charge everybody AFAIK including Microsoft. There was no US export restriction on strength of authentication, only confidentiality, and the "EXPORT" suites handled that by using a second RSA key of up to 512 not 1024 and symmetric ciphers limited to 40 not 56; as you say any decent server today refuses both export 40 and single-DES 56. Also SSL2-Hello is better called 'transition' than 'transitory'; it lasted more than 10 years (although it shouldn't have). – dave_thompson_085 Aug 5 '15 at 3:47
  • I assume it also has a problem with SHA-1 being phased out. According to Wikipedia SHA-2 wasn't published until 2001, so it couldn't have been supported by something that old. – kasperd Aug 5 '15 at 7:38
6

There might be more reasons, I'll just list a few that came up my mind:

  1. When establishing the SSL/TLS connection (the handshake) the client sends a list of cipher suites to the server. The server's responsibility is then select the one which will be used. In case there is no suitable cipher, the connection is terminated.
  2. SNI - Server Name Indication extension. AFAIK this is not supported for IE6 and earlier on XP.

To be honest, I am not even sure if IE5 supports TLS.

  • Any IE version on XP doesn't support SNI, it's Windows version that matters, not IE. Also, SSL doesn't support SNI, only TLS does. – Adm Selec Aug 6 '15 at 7:00
2

You're most likely correct. Most websites now prohibit the usage of outdated SSL protocols - recall that SSL v3.0 was part of the POODLE attack, among other things! If your browser only supports the disabled protocols, then you won't be getting very far.

Wikipedia has a great chart on its page about SSL/TLS, showing what protocols are supported by default on various browser versions. Most importantly, Internet Exploder 6 only supports up to TLS 1.0, and it's disabled by default. This means that your browser is probably trying to use SSL v3.0.

You should be able to check the status of your trusted certs - after so many years, I hope they've expired. The OS is so old that Google searches don't pull up much advice on how to do that, though!

2

The likely cause might be that not many servers support the cypher conditions IE5 has the ability to use. At the time of your IE's release it only had SSL support and not TLS support.

SSL 1.0 was never publicly released. SSL 2.0 and 3.0 have since been deprecated. Even though servers out in the wild could support them they will likely not be found on servers for most popular websites.

The TLS 1.0 standard was not defined until 1999. And Microsoft has long notorious for not picking up with standards in a timely manner. You likely have IE 5.0 or 5.01 (bug fix edition) packaged in your OS which lacks any encryption. The version with encryption was 5.5. It is not packaged with your version of the OS but compatible. However you won't be free and in the clear just yet. It only supports 128 bit TLS 1.0 which IE disables by default.

Additionally EV certificate, SHA-2 certificate, ECDSA certificates are also not supported. Finding a server in the wild that has a 128 bit cert with TLS 1.0 and IE5 era cypher suit will be extremely rare.

  • Rare that would be. I wonder if 3DES is safe. Probably. – Joshua Aug 5 '15 at 3:12
  • EV is not a problem, an old browser will just ignore the extension. SHA2 almost certainly is; XP didn't support RSA/SHA2 until SP3 so I'd bet that 98 and even NT can't do it at all. ECDSA could be a problem, but I doubt you'll find public sites that require ECDSA; not that many even allow it. – dave_thompson_085 Aug 5 '15 at 3:56
  • @dave_thompson_085 Sites that use CloudFlare services and run on HTTPS with Comodo SHA2 certificates (not GlobalSign SHA1) require ECDSA support, making Internet Explorer and Chromium-based browsers on Windows XP fail. Just see how many people complain: code.google.com/p/chromium/issues/… I don't use CloudFlare but currently have 3 sites that require ECDSA, and more coming. Your comment makes me think you're living in 2001 year or so :(. – Adm Selec Aug 6 '15 at 6:40
2

Install Opera compatible with Windows 98, I am using 10.10.

Access the menu bar.

Tools->Perferences => Advanced tab

Select Security and then the Security Protocols... button.

Popup window has check box for Enable SSL 3.

Success! Google's site using HTTPS works again!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.