Is it safe to use SSL SNI in production?

Thanks to SNI technology you can now host multiple SSL certificates on a single IP address. But what is SNI? How does it work its magic? What are the disadvantages? Let’s take a closer look and decide together if you should use SNI for your production websites.

Two announcements that shook the Internet

Could the Internet be reaching its last days? Surely it could never happen? Ok, perhaps slightly melodramatic, but a few recent incidents clearly demonstrated the impact IPv4 address shortages are starting to have on everyday Internet operations.

One of the largest outages in Internet history recently shook the online community. Major Internet Services Providers like BT and Virgin in the UK and AT&T, Time Warner and Verizon in the US went down. It appears that these outages were all caused by growth of the BGP routing table – a knock-on impact of the increasing scarcity of available IPv4 addresses.

Our friends over at Microsoft Azure also had their own problems when they ran out of spare IPv4 addresses earlier this year.

Add to that the fact that Google have started giving a ranking boost to secure https/SSL sites, and intends to accelerate the prominence of this factor in future. So Google are at it again – shaping the lives of SEO experts and their clients the world over. This time there’s a catch due to the implications this has for excessive IPv4 address consumption!

Technical background

When hosting multiple sites on a single server, they share the same IP address and make use of named-based virtual hosts to identify which site should be displayed. When the browser makes a request for the site, it includes a special HTTP header (the ‘Host’ header) stating which site it’s trying to access. The server matches this header to its configuration and displays the corresponding website.

However, this same technique cannot be applied for sites delivered over HTTPS, because the Host HTTP header is only sent after the TLS handshake is completed.

The server is left with a classic chicken vs. egg dilemma: it needs HTTP headers to determine which website (hence which matching SSL certificate should be provided), but it can’t get that without first completing the TLS handshake with the browser (requiring it to present an SSL certificate first).

This means, prior to SNI, the only way for a server to present different SSL certificates depending on the site being requested was to host each site a different IP address. This enables the server to select the appropriate SSL certificate based on the IP address the request is received on. The server admin must ensure that the DNS for each site is configured accordingly so that everything matches up.

In extreme cases a single server can host thousands of domains, so it’s not hard to see how if each of those sites are compelled to transition from sharing a single IP to using their own unique IPs (due to Google’s prompt for all sites to use SSL) IP address consumption will accelerate rapidly!

There were 1,022,954,603 active sites online in September 2014 (Netcraft) – yes, over 1 billion. But it’s also estimated that 39% of the world’s 7 billion strong population are connected to the Internet; each requiring an IP address (of some description) at the client end of their connection to enable them to access those websites / servers. Stop and think for a moment how many Internet-connected devices you use on a daily basis; probably several? It’s not hard to see why IPv4 address space is running low, given its maximum of just over 4 billion unique address representations.

The long term solution to this issue is IPv6 (providing about 340 undecillion – I promise you that’s a real word – unique addresses), but realistically all serious websites will need to remain accessible via IPv4 for at least the next few years. So IPv6 is no silver bullet to the problems faced by website owners today.

With IPv4 running short, but a necessity here to stay for the foreseeable future, we need another answer to enable SSL certificates on all of the world’s websites and services.

SNI technology can do just that. Could it emerge as a likely superhero?

SNI – here to save the day?

Server Name Indication (SNI) is an extension to the TLS protocol that indicates (no, really!) what hostname the client is attempting to connect to. TLS is just the ‘proper’ name for modern day SSL (history lesson: SSL 1 -> SSL 2 -> SSL 3 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2).

SNI inserts the requested hostname (website address) within the TLS handshake (the browser sends it as part of ‘Client Hello’), enabling the server to determine the most appropriate SSL certificate to present – removing the need for your server to possess psychic powers and guess which SSL certificate it should present.

Using SNI the server can safely host multiple SSL certificates for multiple sites, all using a single IP address.

SNI superpowers in production web hosting

SNI helps the global Internet community make the most efficient use of scarce IPv4 address resources – this is exactly what a superhero should do – help the community!

As any good superhero, SNI also looks out for your personal well-being – in this case by saving you money:

1. You no longer need a separate IP address for each SSL certificate; a single IP address does the job

2. SNI is much more scalable; since most providers now limit the maximum number of IP addresses per server, you’re not forced to buy additional servers just to be able to run SSL-enabled sites!

But wait…

Superhero weaknesses (why SNI may not be production ready – yet)

Every superhero has their weakness. That one achilles heel for their nemesis to exploit. Our brave SNI’s is simply a matter of support; SNI is not yet supported by all browsers and web servers – most notably, no version of Internet Explorer on Windows XP works with SNI (these users will see certificate errors).

Whether or not this renders a crippling blow to SNI’s immense strengths is a matter of opinion. It all depends on who your users are.

However, we should point out that reports indicate operating system usage of Windows XP dropped from 13.5% in September 2013 to a slight 5.9% by September 2014. It’s been widely reported that Windows XP hit its ‘End of extended support’ back in April 2014, so it’s fully expected that its usage would continue to plummet. (Though a note of caution here: there are also some holdouts, including various governments and corporate enterprise users who have purchased expensive commercial support packages from Microsoft because they could not or would not meet that date).

It’s also worth considering that Windows XP users can still enjoy the benefits of SNI by using alternative browsers. Google Chrome 6 or later, Opera 8.0 or later, Mozilla Firefox 2.0 or later are all example mainstream browsers which enjoy SNI functionality on Windows XP. So the ‘Windows XP problem’ as we’ll call it, is really only limited to people using (any version of) Internet Explorer.

You should analyse your own stats to determine what % of your users are still using Internet Explorer on Windows XP – for this blog, it’s 3.17%. However, to get a general sense of the Internet population at large, we can consider data from StatCounter, and in particular the good people at “Can I use” have a nice usage table visualisation of it.

The last version of IE to support Windows XP was version 8. So based on this data you can see a maximum of 4% of users might be affected – if all of those users using IE 8 and earlier are also using Windows XP, and visiting your site. On this blog we actually see 13.78% of our traffic using Internet Explorer 8 or earlier (but as above, a far lower % are on XP as well).

Mobile browser support

Let’s not forget that in today’s world there’s more than just the desktop! Internet Explorer users on Windows XP are not the only thorn in the side for SNI – mobile makes up a growing portion of Internet traffic.

Android’s default browser in Gingerbread (2.3) doesn’t support SNI either; though thankfully Chrome and other browsers are reported to support SNI on Gingerbread and later. Android’s default browser in Honeycomb (3.0) supports SNI, as does Chrome (which later became the default browser for Android devices).

Although Gingerbread was first released in 2011, it’s known that many handset manufacturers still continued to sell new devices running this version for a while after Ice Cream Sandwich (4.0) became available due to hardware specification requirements. That also means those older / lower spec’d devices may still not be capable of running a more recent Android version – so if they’re still in use, they probably still don’t have SNI support by default.

On the fruity side of the mobile fence, iOS fares slightly better; it supported SNI on its default (Safari) browser starting with iOS 4.0 (released in 2010).

Java Application Servers

Servers also have their share of shortcomings; although Java introduced client support for SNI in Java 7, server support is not available until Java 8. That means that servers such as Tomcat 8 (due to still supporting Java 7 as an option) do not yet have SNI support.

Every superhero has a friend

Not convinced that SNI is ready to be your superhero just yet?

Batman and Robin, Iron Man and Mr. Fantastic, Iceman and Beast: all the best superheros have a dependable companion to help them out in the stickiest of situations.

SNI’s companion – of sorts – is the multi-domain certificate. Whilst not quite as glamorous as his superhero buddy, the multi-domain certificate still has the same ambitions to curb your excessive IP address thirst. Unlike SNI, multi-domain certificates don’t have any browser (or server) hang-ups. They’re installed and configured as a perfectly normal SSL certificate; all commonly used browsers already know exactly how to work with them without any special magic.

This little known certificate can cover up to 200 domains (minimum 3) within a single SSL certificate. The only significant caveat, and reason why SNI is broadly a better solution, is these domains all need to be added to the same certificate (not individual certificates) – this in turn means they must all use the same type of certificate (domain control, org validated, or EV), which of course reduces your flexibility a bit.

Our SSL team will be happy to help you with discounted pricing for multi-domain certificates for your project.

Layershift servers support SNI

If SNI is your superhero du jour and you feel now is the right time for you to start using SNI in production, you’ll be pleased to know:

Not wanting to be presumptuous, all of our servers are set by default to work in standard SSL (dare we even say legacy?) mode – just in case those ~4% of users represent an important visitor segment on your sites.

If you want to start using SNI on your Layershift Cloud VPS, just contact our friendly 24×7 support team and they will make the necessary configuration adjustments for you.

Our Jelastic PaaS Apache and Nginx servers support SNI by default, but adding the certificate using the ‘Custom SSL’ option in the dashboard does not configure SSL in this way. You must instead configure it by direct configuration file edits – please contact our friendly 24×7 support team if you require any assistance.

As noted above, Java servers do not yet offer SNI support, but you can still take advantage of SNI by applying the certificate to a load balancer (SSL offload) in front of your application server. You can add a load balancer to your environment even if you only have a single application server.

Should you use SNI on production sites?

This is a judgement call each website owner must make for themselves. It really depends on who your clients are and how up to date (or otherwise) their devices are, but we hope the detailed information above has helped improve your understanding of the issues and potential pitfalls, and will guide you to the most appropriate decision for your situation.

Remember, our 24×7 support team are always here ready to assist if you need any further help or clarification.