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.