Source : le blog de l’équipe IE (http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx)
The new Windows Vista platform offers several HTTPS improvements.
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.