Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2

[USMCRET6391]

In the past, we’ve called upon website operators to ensure they are using HTTPS securely. This time, I’d like to tell you about the changes IE7 has made to improve the security and user experience for HTTPS connections.

Safer Protocol Defaults

HTTPS uses encryption to secure your Internet traffic to protect it from snooping or tampering by others on the network. HTTPS uses either the Secure Sockets Layer (SSL) or the Transport Layer Security (TLS) protocols to protect data.

For Internet Explorer 7, the default HTTPS protocol settings will be changed to disable the weaker SSLv2 protocol and to enable the stronger TLSv1 protocol. (Users of IE6 can manually configure these stronger settings by using Internet Explorer’s Tools | Internet Options | Advanced menu.) Hence, by default, IE7 users will negotiate HTTPS connections using SSLv3 or TLSv1.

Generally, IE users will not notice any difference in the user-experience due to this change; it’s a silent improvement in security. Our research indicates that there are only a handful of sites left on the Internet that require SSLv2. Adding support for SSLv3 or TLSv1 to a website is generally a simple configuration change. On a secure site, you can examine what protocol is in use by clicking Properties on the File menu. Alternatively, you can use Microsoft Fiddler’s “Capture HTTPS CONNECTs” option to view a complete listing of which protocols and encryption algorithms your browser offers and which the server chooses.

User Experience changes

Whenever IE6 encountered a problem with a HTTPS-delivered webpage, the user was informed via a modal dialog box and was asked to make a security decision. IE7 follows the XPSP2 “secure by default” paradigm by defaulting to the secure behavior.

Most importantly, IE7 will block navigation to HTTPS sites that present a digital certificate that has any of the following problems:

1. Certificate was issued to a hostname other than the current URL’s hostname
2. Certificate was issued by an untrusted root
3. Certificate is expired
4. Certificate is revoked

Upon encountering a certificate problem, IE7 presents an error page that explains the problem with the digital certificate. The user may choose to ignore the warning and proceed in spite of the certificate error (unless the certificate was revoked). If the user clicks through a certificate error page, the address bar will floodfill with red to serve as a persistent notification of the problem.

In addition, users will no longer see the so-called Mixed-Content prompt, which read: This page contains both secure and nonsecure items. Do you want to see the nonsecure items? IE7 renders only the secure content and offers the user the opportunity to unblock the nonsecure content using the Information Bar. This is an important change because very few users (or web developers) fully understand the security risks of rendering HTTP-delivered content within a HTTPS page.

Improvements on Windows Vista

The new Windows Vista platform offers several HTTPS improvements above and beyond what is mentioned above.

First, Windows Vista includes several new cryptographic algorithms for HTTPS communications, including the Advanced Encryption Standard outlined in RFC3268. AES is a strong, efficient algorithm that offers support for key lengths of up to 256 bits.

Next, certificate revocation checking is enabled by default in Windows Vista. Revocation checking enables a Certification Authority to later revoke a digital certificate which was issued in error or used fraudulently. The performance of certificate revocation checking is enhanced thanks to support for OCSP (Online Certificate Status Protocol) which enables lightweight lookups.

Lastly, the TLS implementation has been updated to support Extensions as described in RFC 3546. TLS extensions improve performance, and add capabilities to the TLS protocol. The most interesting of the extensions is the Server Name Indication (SNI) extension, as it resolves one of the long-standing limitations for HTTPS hosting.

A little background: When a web browser initiates a HTTPS handshake with a web server, the server immediately sends down a digital certificate. The hostname of the server is listed inside the digital certificate, and the browser compares it to the hostname it was attempting to reach. If these hostnames do not match, the browser raises an error.

The matching-hostnames requirement causes a problem if a single-IP is configured to host multiple sites (sometimes known as “virtual-hosting”). Ordinarily, a virtual-hosting server examines the HTTP Host request header to determine what HTTP content to return. However, in the HTTPS case, the server must provide a digital certificate before it receives the HTTP headers from the browser. SNI resolves this problem by listing the target server’s hostname in the SNI extension field of the initial client handshake with the secure server. A virtual-hosting server may examine the SNI extension to determine which digital certificate to send back to the client.

TLS Extensions are a powerful, standards-compliant feature of the TLS protocol. Compatibility should be guaranteed by the RFC requirement that unknown TLS extensions must simply be ignored. Unfortunately, anecdotal data indicates that some TLS servers in the wild are not RFC-compliant and immediately fail the connection when TLS extensions are present.

The Internet Explorer team and others are working to evangelize compliance with the TLS specification to help ensure a smooth experience when using TLS Extensions in Windows Vista.