Jaa

Misbehaving HTTPS Servers impair TLS 1.1 and TLS 1.2

  • Artikkeli

Back in the summer of 2009, I blogged about Windows 7’s new support for TLS 1.1 and TLS 1.2. These new protocols are disabled by default, but can be enabled using Group Policy or the Advanced Tab of the Internet Control Panel:

IE Advanced Options Crypto Settings

Some adventurous Internet Explorer users have found that if they enable these new protocols, some secure sites will fail to load:

IE cannot display the page error message

Upon encountering an error like this, a user might try to see what’s going wrong by enabling Fiddler’s HTTPS Decryption feature and re-visiting the site. When they do that, they find that the site starts working correctly.

What’s going on?

Fiddler is based on the .NET Framework’s SSLStream class, which only supports SSLv2, SSLv3, and TLS 1.0, and Fiddler only enables the latter two protocols by default. By running Fiddler, the user has effectively turned off outbound use of TLS v1.1 and TLS v1.2, and that remedies the connection problem.

To see what’s failing, you need to use a lower-level debugger like WireShark or Netmon. When you use Netmon, you’ll see the following sequence:

Netmon inspection of TLS traffic

If you examine the “Encrypted Alert” from the server, you will see that it contains the byte sequence “02 46”, meaning Fatal Alert: Protocol Version.

The server isn’t supposed to behave this way—it’s instead expected to simply reply using the latest HTTPS protocol version it supports (e.g. "3.1” aka TLS 1.0). Now, had the server gracefully closed the connection at this point, it would be okay-- code in WinINET would fallback and retry the connection offering only TLS 1.0. WinINET includes code such that TLS1.1 & 1.2 fallback to TLS1.0, then fallback to SSL3 (if enabled) then SSL2 (if enabled). The downside to fallback is performance—the extra roundtrips required for the new lower-versioned handshake will usually result in a penalty amounting to tens or hundreds of milliseconds.

However, this server used a TCP/IP RST to abort the connection, which disables the fallback code in WinINET and causes the entire connection sequence to be abandoned, leaving the user with the “Internet Explorer cannot display the webpage” error message.

Because Fiddler doesn’t support the newest TLS protocol versions, it does not encounter this problem. However, there are even a few older HTTPS sites that cannot be viewed with Fiddler unless support for TLS 1.0 is disabled in Fiddler. That’s because Fiddler will not fallback from TLS 1.0 to SSL 3, while WinINET will do so (if SSL3 is enabled). If a server refuses a TLS 1.0 connection request from Fiddler, it’s treated as a fatal error. Only by disabling TLS 1.0 support in Fiddler (described here) can the sites’ traffic be successfully inspected by Fiddler.

Hopefully, buggy HTTPS servers will continue to wane in popularity and enable clients to successfully enable newer protocol versions with minimal compatibility impact.

-Eric Lawrence

Update: If the server negotiates a TLS1.2 connection with a Windows 7 or 8 schannel.dll-using client application, and it provides a certificate chain which uses the (weak) MD5 hash algorithm, the client will abort the connection (TCP/IP FIN) upon receipt of the certificate.

Comments

  • Anonymous
    March 24, 2011
    www.microsoft.com/.../portal is an example of this type of failure. Eric, could you ask Microsoft Malware Protection Center (MMPC) to fix the problem? Thanks, Franklin [EricLaw: There are a lot of sites out there with this issue. It's unlikely that the MMPC guys are running their own servers; Geographic load balancing via CDNs makes this even more complicated. ]

  • Anonymous
    November 14, 2011
    Are you at liberty to say which versions of IIS behave correctly? Thanks

  • Anonymous
    July 17, 2012
    Another post on this topic: www.educatedguesswork.org/.../problems_with_secure_upgrade_t.html

  • Anonymous
    March 20, 2013
    One root cause of this may be a bug in Server HTTPS implementations where a ClientHello over 256 bytes fails: github.com/.../Long-Handshake-Intolerance

  • Anonymous
    September 24, 2013
    Why are those protocols disabled in the first place? [EricLaw]: These protocols are disabled in the first place because, as described in the post above, enabling them causes some websites to fail to load. Users uninstall browsers that fail to load websites they care about.

  • Anonymous
    January 30, 2014
    Well, this also cause IE to be unable to handle the SNI extension to TLS (see RFC 4366), hence loading the wrong certificate for the second ssl vhost on my website. So I would say unchecking them  will cause some websites to fail to load as well.Ok, they don't fail to load, you only get a warning about the certificate not beeing issued for the right website. Still, most people will stop there and choose not to ignore the warning. EricLaw I think you're a bit confused. If you untick the Use TLS1.0 checkbox, then you're correct to note that TLS1.0 Extensions will not be sent, which would prevent the use of SNI. Disabling TLS1.1 or TLS1.2 will not prevent the use of TLS1.0 or SNI. 

  • Anonymous
    January 30, 2014
    The comment has been removed

  • Anonymous
    January 30, 2014
    In fact, only checking SSL 2.0 impairs the usage of SNI. With Both SSL 3.0 and TLS 1.0, everything seems to work fine. Is that because SNI is a SSL 3.0 addition or because SSL 2.0 is doing strange things when enables (like trying the lowest protocol version first?). [EricLaw] There are two handshake formats in HTTPS, the SSL2 format and the SSL3+ format. The SSL2 format has no provision for extensions, while the SSL3+ format allows extensions (which aren't used except in TLS1+).