It might have been low last year. This year with the deprecation of Windows XP, pagerank boost for HTTPS[1] and free certs and caching from CloudFlare[2] all of my sites are now SNI. Some are even HSTS.
I think there are relatively few sites using SNI. Every provider that supports SNI has a big warning attached that it may not work under a variety of circumstances. The only real reason for doing SNI is cost.
That's what led me to this issue. I have a number of sites on the cloudflare free plan using their free SSL and all of them stopped being indexed by bing over the last few weeks.
A year or so ago I worked as a security engineer and one of the products my company used was McAfee Web Gateway proxy, and it did not support SNI either. We would end up with a lot of sites that were blocked for having invalid certificates because Web Gateway couldn't understand what they were doing.
We host some sites on Media Temple, and were told by them that they no longer have any dedicated IP addresses to offer, so if we want an SSL cert on a site we must use SNI. So isn't "running out of IPv4" addresses another reason for using it? Or are we/they misinformed about this?
You could likely upgrade to a higher level plan (higher $) which includes a dedicated IP address. They are likely running low and no longer offer dedicated IP addresses for anything lower than their managed VPS and dedicated server packages. If they don't have any IP addresses left to dedicate to dedicated servers and high-end VPSes, then they're in serious trouble.
Cost is one factor, but SNI also has performance and IPv4 exhaustion repercussions as well.
An SSL cert chain with 30 SANs is 4.3kb, versus 2 SANs at 2.5kb. This is data that is sent for every new connection, and nothing can happen until it is successfully received and processed by the client. This isn't a huge overhead, particularly with modern initcwnd settings, but there is a benefit to a smaller SSL handshake payload.
The other part is IPv4 exhaustion. Think of how many IP addresses are currently in use solely for the purpose of SSL virtual hosting. This is why CDNs charge such exorbitant fees for SSL certs, because they a) want to discourage you from doing it and b) have to incur real expenses to maintain their dwindling supply of v4 space.
We're past the point where it's alright to not support SNI. It isn't the server's fault anymore if you can't connect, it is your client's fault now.
I am struck by the irony of juxtaposing this with the fact that Azure Websites still charges the (in my opinion outrageously steep) price of $39 per month per certificate for non-SNI cert support. Maybe it's not that ironic, but it is still striking.
The $600/month becomes pretty reasonable when you understand what's going on behind the scenes. There are 53 CloudFront edge locations, each of which needs to reserve at least one IP address for your SSL cert's exclusive use.
They seem to be able to index sites that use SNI. For example my site https://emailprivacytester.com/ has been using SNI for over a year now and is indexed, and I can see the Bing bot in my access logs.
It looks odd how Bing customer support emphasis on "Patience":
Thank you for your remarkable patience. Have a nice day.
We understand how important this is for you and we appreciate your continued patience as we endeavor to resolve this matter
25 comments
[ 4.2 ms ] story [ 58.0 ms ] thread[1] http://googleonlinesecurity.blogspot.co.uk/2014/08/https-as-...
[2] https://www.cloudflare.com/ssl
We host some sites on Media Temple, and were told by them that they no longer have any dedicated IP addresses to offer, so if we want an SSL cert on a site we must use SNI. So isn't "running out of IPv4" addresses another reason for using it? Or are we/they misinformed about this?
An SSL cert chain with 30 SANs is 4.3kb, versus 2 SANs at 2.5kb. This is data that is sent for every new connection, and nothing can happen until it is successfully received and processed by the client. This isn't a huge overhead, particularly with modern initcwnd settings, but there is a benefit to a smaller SSL handshake payload.
The other part is IPv4 exhaustion. Think of how many IP addresses are currently in use solely for the purpose of SSL virtual hosting. This is why CDNs charge such exorbitant fees for SSL certs, because they a) want to discourage you from doing it and b) have to incur real expenses to maintain their dwindling supply of v4 space.
We're past the point where it's alright to not support SNI. It isn't the server's fault anymore if you can't connect, it is your client's fault now.
That seems like a better option as a fallback when SNI is not available.