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