I can find various information about SNI (see Wikipedia), but I can't find any statistics about actual support in browsers.
The best I could find out is that it should work on Windows XP with SP3.
Does anyone know if SNI can actually be used in practice?
On
I am late in answering this, but for all readers who may be interested in this kind of solution. Just detect the browser and OS using server-side feature and tell the visitor to use "Install and use secure browser for shopping online like Chrome or Firefox and provide a link to download and install."
This is best way to make shopping secure for your customer and this serves two purposes, one SNI enabled SSL usage and making customer's "shopping secure." Because those outdated browsers on XP are really not safe irrespective of server using SNI enabled SSL or not.
We can risk this, because the percentage of users using older IE versions on XP are below 5% in US and it is negligible or zero in other countries. In fact people in other countries people are used to Open Source browsers.
My own experience, I host many websites for myself as well as many clients and I have SSL for all of them using SNI technology without dedicated IP and I am quite sure that people have shifted to chrome or firefox in many countries, almost all of them and in US, 95% of them.
Forgive me for any inaccurate information.
On
Internet explorer (all versions; 6, 7 and 8) on Windows XP do not support SNI. All the others work. I don't really know how many users on XP use Internet explorer but that's the magic number of users that cannot use SNI .
Mobile Support :
Android default browser on Honeycomb or newer
Windows Phone 7
MobileSafari in Apple iOS 4.0 or later
I think there are two aspects of this, the UI and the detection part.
UX
<!--[if lt IE 7]>
<div>You're using a browser that has high security risks (SSL, XSS, etc). Please consider upgrading it.</div>
<![endif]-->
It's clear that anyone using IE6 or below has high chances to be on Windows XP and not supporting SNI. The other who spoof their user-agent don't matter here.
Server side
Special note
Using the AJAX solution gives you a 99% bullet proof detection but does not conform with a couple of web dev principles.
On
The problem is windows XP clients and Android < 3.0 clients. Unfortunately combined they are still nearly 10% of visitors to many of our websites. In addition, while Blackberry users are a low volume, they are some of our paying customers. XP, Blackberry and Gingerbread combined make SNI not acceptable at most of our websites at this time (Feb 2015). I expect this problem to diminish in about a year or two.
Update on Nov 2016 (21 months later): Going on a fairly standard site with ~10,000 visits/mo. Jan 2013 ~10% non-SNI. Jan 2014 ~6%, Jan 2015 <2%, Jan 2016 ~0.5%, Nov 2016 ~0.1% (1 in 1,000). We did the cutover in Nov/Dec 2015. However, certain markets may have a greater number of these users. I created custom audiences in Google Analytics, so it is easy to see the impact. Just define by OS name,version starts with, and for XP, browser is IE.
On
You will not be able to support SSL connections from XP with SNI. However, allowing XP clients to connect doesn't conform to some standards anyway, so you may have to drop these users for other reasons.
They are just a few percent in 2016 and dropping. If you must support every user with SSL, then you will need to dynamically switch, but if you just need the vast majority ... sure.
On
I can share my experience and approach to switching from one-IP-per certificate in a virtual hosting environment (multiple domains per server) to a load balanced environment with one IP for all domains.
We looked at our Analytics (over 1 million unique visitors / month), which is mostly North American male users looking to buy auto parts online, and found on March 8th, 2014 that approximately 4 % of users were on Windows XP using Internet Explorer (others were minor -- worst case 4.5 % of total users would be affected by not supporting SNI). Keep in mind that we have no "control" over these users so we can't tell them to switch browsers. This percentage is also dropping fairly quickly, at least in the US.
We first decided that it was "OK" for non SNI customers to have a somewhat different experience than customers supporting SNI.
Our approach was to detect server-side (using UA string) which browser/operating system combination does not support SNI (as other people mentioned: Wikipedia article on SNI support). All our domains (~ 120) would have an A record pointing to a single load-balanced IP. We had a second IP (also load balanced) for a domain we can call generic-autoparts.com.
So the setup is [I'm not associated with any domains I use as examples below]:
mikesautoparts.com --> A Nameserver Record of IP X
dansautoparts.com --> A Nameserver Record of IP X
jensautoparts.com --> A Nameserver Record of IP X
... etc
generic-autoparts.com --> A Nameserver Record of IP Y
If a customer hits http://www.dansautoparts.com, and supports SNI, nothing happens. He browses dansautoparts.com, and when it comes time to check out, he uses https://www.dansautoparts.com.
If a customer hits http://www.dansautoparts.com, and we detect that he does not support SNI, we immediately redirect the customer to http://generic-autoparts.com/dansautoparts.com. He shops on there, and at checkout he uses https://generic-autoparts.com/dansautoparts.com
Now, if a customer hits https://www.dansautoparts.com DIRECTLY (link in e-mail, indexed page in search engines), you are out of luck. They'll get a nasty certificate error. In our case, we made sure all e-mails our system sent didn't use https, and we knew that search engines had not indexed our https pages.
Each environment has different challenges and potential trade-offs. We found that this worked well in our case and customers would "accept" (or not notice) getting redirected to http://generic-autoparts.com/[ORIGINAL DOMAIN].com . We also kept checkout secure through generic-autoparts.com.
Let's say 20 % of nonSNI users notice the redirect, it seems fishy, and they leave. In our case, that's 0.8 - 0.9 % (based on March 8th, 2014 numbers) of users and we were willing to "live" with that. I don't have specific data on this right now, but overall sales held steady. [EDIT 3/28/2014: We saw no impact to sales after we switched 100 % of our customers]
Implementation Update July 8th, 2014
Turns out that it's impossible to detect every UA Agent string statically on the server. We implemented the following JavaScript to detect the browser's SNI capability. The general approach is to do a JSONP request against a domain that requires SNI (Apache supports this through "SSLStrictSNIVHostCheck on"). If the JSONP request fails by timing out, we redirect the customer to the nonSNI domain.
To further complicate matters, we do not want to redirect everyone just because the SNI_TEST_DOMAIN is down. If the JSONP request fails (by timing out since there's no way to detect a JSONP failure directly), we verify that the server is available by doing an HTTP "health-check" request. In addition, we do not want to run this javascript code on every page load, since that increases the chance of some strange timeout and incorrectly redirecting many customers, so we set a session variable once the SNI check is done so it won't happen again as the customer navigates the sites.
We know that we get certain false checks that fails due to the JSONP timeout being unreliable, but since implementing this we are getting no complaints from customers.
var redirect='http://REPLACE_WITH_NON_SNI_URL';
var sni_https_timeout, sni_http_timeout;
var https_req = $.ajax({
url : 'https://SNI_TEST_DOMAIN.com/snitest.php',
dataType : "jsonp",
}).done(function() {
window.clearTimeout(sni_https_timeout);
var request = $.ajax({
url: "index.php?ua=sni_check_done",
type: "POST"
});
})
sni_https_timeout = window.setTimeout(function() {
var http_req = $.ajax({
url : 'http://SNI_TEST_DOMAIN/sni_healthcheck.php',
dataType : "jsonp"
}).done(function()
{
window.clearTimeout(sni_http_timeout);
window.setTimeout(function()
{
window.location = redirect;
},
200);
});
sni_http_timeout = window.setTimeout(function() { sni_http_fail(); }, 8000);
}, 8000);
function sni_http_fail() {
var request = $.ajax({
url: "index.php?ua=sni_check_done",
type: "POST"
});
}
snitest.php / sni_healthcheck.php:
<?php
if (array_key_exists('callback', $_GET))
{
header( 'Content-type: application/javascript' );
echo "{$_GET['callback']}();\n";
}
The Wikipedia article you referenced lists the supported browser and server versions. Internet Explorer 7 (Vista or higher, not XP) or later and Mozilla Firefox 2.0, for example. Unless you know all your visitors are using supported browsers, you can't use SNI (with multiple certificates on one IP address) without cutting them off from the SSL portion of your site.