Last week Google made an announcement about its use of SSL/TLS with advice to customers on how to ensure the can continue to connect to Google's services.
Duck wrote an excellent overview of the big change - the switch to 2048-bit certificates - but a less prominent aspect of the announcement should also be a concern to IT administrators, particularly those managing the 33% of desktops that are still running Windows XP*.
The key information appeared towards the end of the announcement:
"Also, clients should support the Server Name Indication (SNI) extension because clients may need to make an extra API call to set the hostname on an SSL connection."
SNI is an extension to the SSL/TLS protocol that allows a browser to specify explicitly the name of the website it's trying to connect to. It allows a single web server to host multiple HTTPS web sites. This practice, known as virtual hosting, is already widely used for hosting regular, non-secure websites.
When your browser connects to an HTTPS site, the very first thing the server does is send a copy of its certificate so your browser can validate its identity. The browser will expect the name on the certificate to match the name of the website it's trying to connect to.
This is fine if the server only hosts one website - it only needs one certificate.
But what if it's a virtual hosting server with multiple websites, each with a different name? It would need to select the right certificate to return so that the browser sees the name it expects.
SNI is a special SSL header that allows the required hostname to be included in the very first packet of the secure negotiation. When a virtual hosting server receives a secure connection request with an SNI header, it can check the header against its list of hosted sites, and present the right certificate.
Support for SNI has been slow to emerge. It's a classic chicken and egg scenario - if browsers don't support SNI, then they can't access secure sites on multi-hosted servers. But until more multi-site servers exist there's no need for browsers to support SNI.
Google's announcement suggests that they intend to host websites in ways that require SNI in the near future. And as more sites adopt the security benefits of using HTTPS by default, we will no doubt see wider adoption of virtual hosting for HTTPS across the board.
So if you're using a browser without SNI support, you may find parts of the web will no longer be available to you.
Most modern browsers support SNI. If you're running Chrome, Firefox or IE 10 on a shiny new Windows 8 laptop you're laughing. However, if you still have systems running IE on Windows XP you may find yourself stuck.
Because Internet Explorer on Windows XP uses the underlying operating system's SSL services to make secure connections, even IE8 on XP does not add the SNI header to outgoing requests.
The solution? Upgrade to a more modern operating system, or switch to a different browser.
Both Chrome and Firefox support SNI on Windows XP.
* Windows XP usage data from Net Applications