Share via

TLS enabled by default in IE 7.0 and WinINet

  • Article

Transport Layer Security (“TLS”) and Secure Sockets Layer (“SSL”) are transport-layer protocols for server and client authentication, data encryption, and data integrity of application layer protocols such as HTTP, SMTP, and FTP. In order to provide a more secure experience, Microsoft is enabling TLS and extensions by default in Internet Explorer 7.0 and WinINet. Starting with Windows Vista, Schannel - the Security Support Provider (SSP), which implements TLS 1.0, will send “Extensions” during SSL/TLS protocol negotiation. The negotiation of the best common protocol occurs automatically between hosts. However, if needed, users can toggle TLS and Extensions in the “Advanced” tab of the “Internet Options” dialog. We do not supply a mechanism for toggling Extensions independently of TLS.

The reason that we have enabled TLS Extensions (aka SSLv3.1) in Windows Vista by default is that TLS provides a number of enhancements beyond SSLv3. Some of the benefits of TLS include:

  • TLS is an IETF standard.
  • TLS provides more secure hashes through its use of the HMAC algorithm instead of the SSL MAC algorithm.
  • TLS adds a number of new alert messages.
  • TLS allows the use of an intermediary authority.
  • TLS support “extensions”, an RFC-specified mechanism for extending the protocol with additional functionality.
  • TLS supports AES and Elliptic Curve Cryptography-based (ECC) cipher suites

Although the SSLv3 and TLSv1 protocols differ only slightly, they are not interchangeable. Client and server must agree on which protocol, version, and extensions to use during the protocol negotiation phase. This negotiation happens transparently between the client and server – with TLS backing-off to SSLv3 when both parties do not claim support for TLS. Over the years, the IETF has expanded TLS beyond its original RFC 2246 to include support for Extensions and additional cipher suites such as AES, Kerberos and ECC. The extensions to TLS 1.0, defined in RFC 3546, provide additional behaviors beyond what the original drafters of RFC 2246 envisioned, such as:

  • IETF has added cipher suites that rely on algorithms beyond the original RC2, RC4, IDEA, DES and 3DES to the TLS protocol.
  • IETF has added support for virtual hosting of HTTPS websites on a single IP address/port with the “server_name” extension. With “server_name”, the client sends the hostname during its “extended” Client Hello to the server. This allows the TLS server to select the appropriate server certificate for the client. This is similar in capabilities brought on by the host-header requirement of HTTP/1.1. (server_name extension)
  • IETF has added support for client certificate URLs. Client Certificate URLs allow the client to tell the server to “go” to a particular URL for the client’s certificate, which helps in network-constrained environments, e.g. mobile phone. (client_certificate_url extension)
  • IETF allows for MAC truncation which helps in bandwidth constrained environments by allowing the use of an 80-bit (10 byte) truncated HMAC. (truncated_hmac extension)
  • RFC 3546 also added support for the certificate status extension (e.g. via OCSP) which allows the server to send revocation state of the server certificate to the client.

Although the vast majority of modern web servers behave correctly when receiving a handshake containing TLS 1.0 extensions, some web servers do not respond in the RFC required manner when support does not exist for extensions. RFCs for TLS require that servers simply ignore extensions that appear in the “client hello” message that they do not support, which effectively disables those extensions for the session. During our testing using tools like Microsoft Network Monitor (“netmon”), we learned that servers that do not understand TLS + extensions may respond incorrectly in one of three ways:

  1. The server replies with a message that specifies that there was an invalid handshake;
  2. The server unexpectedly resets the TCP connection; or
  3. The server ignores the request and does not respond, which keeps the connection open past the WinINet 30 second connection timeout

TLS requires that a server ignore unsupported or unfamiliar extension requests. The client will know that the server does not support the particular extensions when it receives the “server hello” without the extensions it requested in the response. With an invalid handshake response (#1), we back-off and try SSLv3. Helping the problematic servers in cases of a TCP RST or timeout is not possible because these responses (or lack of) are not clear indicators of a problem with TLS extensions.

We want to be sure that help the TLS ecosystem and encourage web server creators and site owners to take advantage of the benefits offered by TLS extensions. Masking of these problems does little to help with adoption, in addition:

  • Interpreting a TCP reset from the server as a faulty TLS extension server is unacceptable because TCP resets can occur for other, non-TLS related, reasons such as an overloaded web server, proxy server, or firewall;
  • Interpreting a lack of response as an issue with TLS extensions is also not the answer. Network congestion anywhere along the route could be the real issue.

We decided that the best solution is to combine smart engineering with proactive communications. This means that IE7 and WinINet will simply scale-back and attempt to use SSLv3 when enabled in Internet Options whenever we receive an invalid handshake message from a server. For proactive communications, the Internet Explorer team is working with the known web servers and site owners to ensure that their site properly handles the TLS 1.0 extensions.

- Billy Anders

Comments

  • Anonymous
    April 12, 2006
    I have been waiting for the TLS extensions for several years (and suggested them to Microsoft on a number of occasions!), so I'm really glad to see that they are coming.
    Is there documentation in place yet for the SSPI changes that need to be implemented for the TLS extensions?  I'm thinking specifically of the server_name extension for my applications, but I'm sure there is documentation required for the others.

  • Anonymous
    April 12, 2006

    Now if only IE would disable COOKIES by Default

    Remove the Allow all cookies setting and use an accepted list like Firefox

    Make the Temp folder not default to 20 to 25% , it ends up creating 600 to 1200 meg on loads of systems , default to 20 to 30 meg instead.

    Also Windows vista setup program prompt the choice of NOT Installing IE , OE , WMP , Messager and MSN Messager .

    (since most smart tech users will use instead  Firefox, Thunderbird, Media player classic and Miranda IM )

  • Anonymous
    April 12, 2006
    Better late than never. Time for the buggy servers to update, if they can't handle a handshake to spec, they are likely to have other issues that compromise security etc. I would not want to have any of my information given over to company that does not keep its servers and security libraries up to date. Why you expect others would want to?

    Just patch IE6 to pop up errors when such server is accessed from LAN or local, this will cause the admins to take note that their server needs updates but will not affect users/clients from outside the server subnet.


  • Anonymous
    April 17, 2006
    Back in October, we blogged about some of the HTTPS improvements we’re making to IE7.  At the time,...

  • Anonymous
    September 08, 2006
    I've been asked this a couple of times by a number of people since RC1 came out. I experienced this myself...

  • Anonymous
    May 06, 2008
    I really, really wish Microsoft would roll out an IE6 hotfix that turns on TLS encryption by default. A new requirement for our web servers is that they require TLS encryption. The problem is that many of our users are still using IE6, and IIS 6 will serve up a generic error page to the users if their TLS setting is disabled, making our site look like it's down. It appears we'll have to set up a web server on a different machine (Site B) to provide instructions for users for enabling their TLS settings. Unless users with the correct settings bookmark the TLS-enabled site, ALL users will first have to go to Site B, even if their browser is TLS-enabled. There doesn't seem to be any straightforward way to automatically detect and redirect users to the TLS-enabled site from Site B if the browser is configured correctly. This is a really messy solution, and there's not much to be found on the web about better ways to do this.

  • Anonymous
    May 06, 2008
    Doug-- Why should IE have to change just because your servers want such a restriction?   What's so wrong with SSL3 that you won't permit it?

  • Anonymous
    September 10, 2008
    Fred, TLS is the new encryption standard that is being required by the federal government under FIPS-140-2.  In addition, I believe banks are requiring it's use.  It only makes sense to me that a hotfix be deployed to enable this setting.  TLS provides much greater security.  Why not deploy this hotfix?  It certainly doesn't hurt.