It’s hard to believe but TLS Server Name Indication (SNI) has been around for thirteen years. In our modern times, it’s a dinosaur, yet strangely a little used one; although that is finally changing, and it’s in this blog that we explore how edgeNEXUS advanced load balancers can support this feature. SNI deals with one of the greatest issues many have with SSL/TLS/HTTPS: The need to dedicate a precious IP address to every domain or sub-domain name that needs to be secured. This is necessary as SSL/TLS secures the connection before we can inspect the client’s initial HTTP request, which contains those precious domain name details.
The only way to be sure we provide the correct certificate is to only serve one per IP address and use DNS to ensure requests to a specific domain name are routed to the IP address of a host serving the correct certificate for that domain. In a private enterprise we could perhaps use the same IP address but a different port, but we’re then obliged to make sure everyone knows to use the non-standard port. This isn’t really a viable option when dealing with public, Internet accessible services.
We could use wildcard certificates that protect every sub-domain possible (*.jetnexus.co.uk for instance) but nobody likes them, least of all security types. Whatever you might think of the NO! men and women of the information security world, they probably have a point. Its hard to trust something that, by design, represents literally anything or everything within a domain. How many devices store and how many staff have access to the certificate and key in use?
Server Alternative Name (SAN) Certificates have always been available too, but require knowledge of every specific domain to be protected, at the time they are generated. Any need to remove or add a domain name requires the certificate to be regenerated and all relevant hosts to be updated with it.
That’s the increasingly tough choice we’ve all faced time and time again (our users and clients too); burn an IP address or accept a compromise (in every sense). Increasingly tough because IP addresses are a finite resource that reduce in availability and gain in value every day. Lucky for us, this long standing issue has had a solution for many years. It gives us the best of all worlds yet has had little impact until recently.
SNI Provides a method for the client to indicate to the server (in our case a jetNEXUS) the domain name it is establishing a connection to. This is done by populating an extension field in the client’s first TLS packet (a hello) with that domain name. This is sent ‘in the clear’ so it can be read before the server sends it’s SSL/TLS certificate. This clearly allows the server the ability to send the expected certificate (assuming it has it) out of however many it has been provided with.
Thus, a single Virtual Service (and IP address) can be configured with as many SSL certificates for as many domain names as you’d like it to serve. Each can have a dedicated and valid SSL certificate, correctly provided without error, based on the data provided by the client. Serve www.jetnexus.com and www.loadbalance.co.uk at the same IP address and provide valid certificates for both; no compromise, no fuss and no IP address wastage.
Not only that, you can change the list of domains supported by the Virtual Service whenever you like, with a few clicks in the GUI. Add or remove certificates to add or remove the domains supported by the Virtual Service. Just don’t forget to update your DNS in tandem. Want to use different real servers for one or two high-value domains, no problem, a quick flightPATH rule is a few minutes away. Ditto for HTTP compression, URL rewrites or whatever else you need. A single Virtual Service and IP address for multiple domains are very desirable but it need not restrict any unique handling you might want to apply to traffic for different domains.
I hear you, “what’s the catch?” Well, there certainly used to be one and that’s the reason SNI has been around for so long but is only now appearing in load balancing and other products. That reason? Client support. The longevity of the incredibly popular Windows XP and IE6 combination, which doesn’t support SNI, has prevented most from using it. No one wants to potentially cut off 10-20% of their audience.
Today however, is a much happier place; Windows XP is well past end of support, IE6 is at less than 1% usage on the wild wide web and the free upgrade to Windows 10 is being pushed and adopted rapidly. We can finally be confident that implementing SNI won’t have an impact on our customers and our business. IE 7 upwards (on Vista or later) and nearly all but the most ancient Chrome, Firefox and Safari version support SNI. If you’d like to check and be sure about your specific user-base, there’s a flightPATH rule for that too.
On the question of security, let’s be clear; the client is providing information in plain text. This is information that can be captured from the wire. The client does a plain text DNS query before it connects too. We can’t control that, so it’s not considered a risk to reveal this information for a second time later on. Perhaps you might want to check that the SNI domain name matches that found in the HTTP Host header, with a flightPATH rule or perhaps you don’t care, everyone is different. Does that suggest a security issue? Either way, the client is connected and the connection is secure. Unless you are applying security policy based upon domain name (and you shouldn’t be) then all is well.
If you really want more detail, take a look at the original RFC3546 (section 3.1), the later RFC6066 (section 3) and, if you think it can be trusted: Server Name Indication on Wikipedi. If you need application level security the edgeNEXUS WAF is based on industry-leading, hardened application firewall technology. Available via the edgeNEXUS App Store, and utilising next-gen container technology, the edgeNEXUS Application Firewall delivers comprehensive security protection to meet PCI-DSS and OWASP compliance requirements. As discussed in previous blog posts, flightPATH is a dynamic, event-based rule engine developed by edgeNEXUS to intelligently manipulate and route load balanced IP, HTTP and HTTPS traffic. To understand more about flightPATH traffic management please click here, and to discover how to take full advantage of the rules available please see the edgeNEXUS User Guide.
A single Virtual Service (and IP address) can be configured with as many SSL certificates for as many domain names as you’d like it to serve. Each can have a dedicated and valid SSL certificate, correctly provided without error, based on the data provided by the client.
