Differences between IE6 and later with regard to HTTPS handling

Question

Straight to the question: Does anything have a good resource for details of what changed between IE6 and IE7, specifically that might make IE6 unable to connect to HTTPS resources on a IIS7 (Windows 2008) based web servers? Our assumption is that the servers are only accepting newer protocol versions/variants than IE6 can not cope with, but we can not find where this might be configured.

To cut a short story long:

We've hit a problem with a couple of web servers running a client application. Since a pile of local policy changes and other registry settings were changed as a result of the client having penetration testers review the configuration, Internet Explorer 6 has refused to connect to the site via HTTPS (the error reported is the default "cannot find server or DNS error" message). IE7 and IE8 are fine, as are other browsers we have tried (FireFox on Windows, FF on Ubuntu, links, ...) though this is a moot point as many of the users more-or-less exclusively use IE6. IE6 is happy to access the same resources on the same IIS installations via HTTP.

Going through the changes that are documented we have found nothing obvious that has made this the case, and even applying all the changes to one of our test servers does not create the problem, those one of the changes was with regard to pulling in non-local policies so I suspect that this is where the problem comes from.

I've not been able to find any useful information by searching (many many sites documenting how to perform the most basic SSL configuration on the web server and get certificates trusted by client applications and such, but no word apparently relating to this issue), nor has anything obvious jumped out at me while scanning through the local policies documentation for the web server from Microsoft.

Telling the client to upgrade from IE6 is, unfortunately, not an option. I'm loath to tell them to simply rebuild the web server(s) and being more careful which check-boxes they click next time, but it is getting to be point where that might have to be our recommendation...

Answer 1

Have you sniffed the client-to-server handshake between IE6 and the IIS machines yet? (http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail) I suspect that this will give you the first bit of information about what's going wrong, especially if you compare the handshake to a working IE7-based client-to-server conversation. An incompatible handshake is my guess as to what's happening.

Here's Microsoft's "official" "changes to HTTPS in IE 7" document: http://msdn.microsoft.com/en-us/library/bb250503(VS.85).aspx

I'm wondering about the "Use TLS 1.0" checkbox in the "Advanced" settings of your IE6 clients. IE7 enables TLS 1.0 by default, and IE6 disables it. It's unclear if your Customer's pentesters played around with the settings on the servers, clients, or both. I can imagine that, assuming they were playing around with the servers, they disabled SSL v2 on the servers (see http://support.microsoft.com/kb/187498) but didn't tell anybody to enable TLS 1.0 on the IE6 clients.

On the servers, they would have altered/created the "Enabled" DWORD value under "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" and set it to 0, assuming they did disable SSL v2.

Answer 2

As a test to trace down the source of the error: Does the connection via the webbrowser control work? You can use for example the iMacros Browser 30-day trial for this test. It uses the same engine as IE, but with a different wrapper.