[argsv]

I just ran this on a Fedora machine and connected to Windows using rdesktop. It works and it's amazing. I like it. The Internet will surely be confused today with a surge of traffic from Internet Explorer 5. Incidentally, google.com still loads and allows searching; bing.com does not load.

[forgotmypw17]

google is, ironically, one of the few remaining "major" sites which support http.

i'm a bit of a browser historian, so i regularly browse the web in everything from mosaic, to ie3 and netscape, firefox 3.x, and all the modern-day favorites such as links and w3m.

so i started building my own websites with all the oldies in mind. it takes some tweaking, but not that much, and i enjoy strolling^Wsurfing down memory lane, looking at that gorgeous ie3 menubar, which was replaced with a flat gray in ie4, or writing something in opera 12.x.

[coderdecoder]

Nice trip down the memory lane :D. Works great on POP_OS (didn't uninstall my desktop).

[skerit]

Yes, do as I say!

[gattilorenz]

With the Web Rendering Proxy (https://github.com/tenox7/wrp) you can also visit bing.com :)

[xxpor]

What're the most recent tls features IE5 supports? Does it even work with non-sha1 certs?

[iforgotpassword]

Google looks at your user agent and doesn't redirect to https if it's an old browser.

[speedgoose]

Isn't this a security vulnerability?

[toast0]

For IE5, there's two distinct obstacles to serving https.

1) It's unlikely to accept any x.509 certificates you can get issued under today's CA/B guidelines; and I'm also not sure how many CAs from then are still valid, either because they had too small of keys or they expired

2) I'm not sure if ie5 supports TLS 1.0 and if it does, it's probably not by default, because that how things were back then.

Given these conditions an https handshake is highly likely to fail, and as the server operator there's no way to provide useful information to the user in that case. If they go to your http site and you redirect them to a handshake error that you know they were going to see... That's not useful. You could be secure and not provide service... but then again, your redirect could be MITMed cause http. Or you could provide a useful service with no security.

This is a choice, not a vulnerability.

This doesn't open up any new way to attack a modern client. Modern clients would have google.com HSTS preloaded and not use http at all. But even if that's not available, a MITM that fiddles with the User-Agent to avoid getting a redirect could have fetched the search results via https and proxied them back via http, as long as the client made an http request.

Edit to add: if you could get a cert IE5 would accept, it likely wouldn't be acceptable by modern clients, so you'd need to distinguish clients from the TLS handshake (although, I guess it really is an SSL handshake for ie5?). There's no client identifier in there, but you can certainly tell the difference between modern and ancient; it gets trickier to tell the difference between ancient and pretty old or pretty old and trying to do a fallback handshake.

[devoutsalsa]

When working at Transmeta as a QA engineer, I remember finding a software bug in the Crusoe processor that prevented IE 5.5 from working with SSL.

https://en.wikipedia.org/wiki/Transmeta_Crusoe

[PeterisP]

Perhaps, but all the vulnerability is in using IE5; there's nothing the site can do to make an IE5-compatible connection secure.

[duskwuff]

In modern browsers, google.com is in the HSTS preload list, so the browser won't even make an initial request over HTTP.

[ehPReth]

Only www.google.com and other subdomains are preloaded unfortunately.. I’m having trouble quickly googling the reason (is that irony?) but from memory a Googler said that they had a lot of internal stuff hosted above google.com they couldn’t make https (HVAC controllers and such?)

You can see the full HSTS list here I believe: https://source.chromium.org/chromium/chromium/src/+/master:n...

[Narretz]

For who? For Google? Or for the client? The server's security shouldn't be dependent on https

[speedgoose]

Both. If you can stop a https redirect by rewriting the user agent header, it can be used to track the Google searches for example. HSTS would help if the browser did connect to the https website recently, but it looks like a security vulnerability to me.

I just realized after writing this comment that if you can rewrite http headers, you can also stop the redirect so perhaps it doesn't matter.

[userbinator]

It wouldn't be surprising if they did that so people could download a newer browser (such as Chrome...) which would itself be signed anyway.