Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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...

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

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.

share|improve this answer
    
I wasn't aware that TLS was disabled by default in IE6. I'm pretty sure that only the servers have been tweaked so that looks like a very likely cause. Thanks for the other pointers to. I'll read around so I've got some pointers to pass on next time I have access to people who have admin access to those machines. –  David Spillett Jul 20 '09 at 11:49
    
It would appear that it is an SSL3/TLS/algo issue. Turning on TLS in IE6 fixes the issue (but the client can do that across the board without six weeks of change request documentation!). The policy that caused the incompatibility was "Use FIPS compliant algorithms for encryption, hashing and signing". –  David Spillett Jul 20 '09 at 13:17
    
Excellent! The psychic powers pay off again... Sorry to hear that the client can't make the change easily, but fortunately this sounds like a management problem now and not a technical one. –  Evan Anderson Jul 20 '09 at 13:35
    
Yeah, I've had this one as well - we're required to use FIPS compliant algorithms on our servers for compliance with BS7799 (well, that's what our assessors say; I'm not convinced the standard actually says that) so we're endlessly telling IE6 users to turn the relevant option on. –  Richard Gadsden Feb 24 '10 at 15:19
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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