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.
So does Safari, but as the Windows version of Safari doesn’t seem to be receiving security updates any more (indeed, hasn’t been updated since 2012) Naked Security isn’t going to recommend it.
* Windows XP usage data from Net Applications
20 comments on “Google’s certificate announcement contains a hidden surprise for Windows XP users”
“So if you’re using a browser without SNI support, you may find parts of the web will no longer be available to you.”
Not quite – please correct if I’m mistaken – all that will happen is you will get a certificate mismatch error flagged by your browser. So when you look at the certificate that comes back and notice it’s for akamai technologies instead of whatever website you tried to connect (hosted by akamai servers) you’ll scratch your head for a bit and figure that its because your browser didn’t supply the real website name via SNI, and you’ll go ahead regardless….
Clearly not a safe way to live but it’s not the same as “no longer .. available”.
As requested… you are mistaken.
XP does not support SNI, so it would not be able to connect. It would not connect to the intended website, but whatever the default website for that IP is. SNI works by the client sending the name of the domain they are trying to reach.
The reality is going to be dependent on the way the web server is implemented. Once an SSL session has been negotiated between the browser and the server, the data sent over the encrypted channel should be regular HTTP 1.1. There is enough information in the HTTP headers for a virtual hosting server to know which web site the user intended to connect to. If the server works this way, browsers without SNI would be able to establish an SSL connection with an error, based on the default identity of the server, but could still go ahead regardless, as FR suggests.
However, a server could choose, or be designed, to be strict in the way it interprets SNI. It could choose to only serve up content from the site requested in the SNI header or to ignore requests with no SNI header.
Since the motivation of most web sites is to get as many people to connect as possible, I suspect the first scenario would be more prevalent. For services where security is a prime concern of the service provider, the second scenario might be more appropriate.
That's a fair point. I could have worded that statement better. But I certainly wouldn't recommend a situation that requires end users to expect to have to ignore certificate validity warnings.
I wouldn't recommend Safari on Windows, just because its no longer being developed or supported??? by Apple.
I agree and I have unilaterally updated Rich's article to agree with you too 🙂
If you’re still using Internet Explorer on any system, you are either grossly uninformed on security issues, or just don’t care.
So.. No problem.
I feel exactly the same way as you do, but unfortunately there are still MANY major businesses/industries that are tied to Internet Explorer (and windows for that matter) forever and mine is one of them (and I absolutely hate that).
I am in the insurance industry and everything is always platformed or developed for windows and IE, and even the web-based programs and company's own websites are all tied in to IE or Java only.
The companies that develop new systems and software for or along with the companies will never care about developing something better or safer because the crap they give us to work with now is fine and will always sell when touted as being an improvement over the prior system.
So like you, there are many people that want to switch, but just have no choice.
I didn't mind when we were still using XP a few years back, and then moved to Windows 7 more recently, but I seriously dread the day we have to switch over to Windows 8 or beyond…
That's exactly the mentality that creates a closed web. I hate websites that simply block users if they're using IE. Usually there is no way around the block and sometimes I have to use IE (like in library, etc.). I know IE10 is pretty competitive with Chrome / Firefox. I use IE10 at home.
Where's with the "use with any browser" mentality? Lazy programmers only design for a specific browser and not for the lowest common denominator. Some websites I see are so plain but they STILL block IE despite it able to use the site (I spoof the UA to get onto the site).
I find it humorous that there are currently websites that block IE users. It wasn't that long ago that there were a *lot* of websites that assumed that the user had IE. I have never come across a site that blocked IE. The worst I find nowadays is the sites that assume you have Flash. (My principle objection to Adobe is that they make you agree, not to just their agreement, but that you have read the agreement, every time you update! Hardly anyone actually does read the agreement (it's multiple pages of fine print), and most people don't mind being pushed into lying in such a situation. But a few do.)
Well that's great. So the company I work for with Win XP machines running IE8 will be out of luck. It's not like I have a choice, here. I would have upgraded to Chrome long ago if they'd let me. As a company, they are EXTREMELY slow in adapting new browsers to make sure the security is up to snuff. We can't even do IE9 because it's just not a priority for them.
I suspect that is the case with a large proportion of the 33% of machines still running XP. I had those IT Admins in mind when I wrote this post. It's possible that they need to build up a stronger argument to convince the organization to make an investment in upgrading.
Please send them a link to this article, if you think it might help!
As far as I know this is also a problem with Android 2.x as the stock browser also doesn't support SNI. Any words from Google how to deal with that?
I am wondering which is/ are the best Browser/ browsers to use for security.
Is ie 8 on windows 7 effected as well?
Yes, it is.
There's a Wikipedia article on SNI that seems to provide thorough list. As always with Wikipedia, you should verify any information before relying on it: http://en.wikipedia.org/wiki/Server_Name_Indicati…
Our PCs are locked down XP and IE7 – Chrome has been blocked
Try Chrome portable 😀
Heck, there is probably a portable version for any browser except IE.
Just tested: SNI does not work with Chrome Frame within IE 8 on Win XP.
Glad I can choose the Browser I want.
ANd Now I have no Google Chrome .. The end!!