Server Name Indication (SNI) and SSL VPN

Been working a lot around PCI Citrix initiatives for the last couple of months.  After speaking with some very smart Citrix NetScaler folks, they were kind enough to provide a lot of information to me around security and SSL VPN which I am sharing with you.  Take notice that Windows XP and IE 7 is not supported and it puts so many companies at risk.

Many People are unfamiliar with Server Name Indication (SNI).  In a nutshell, when client computer browsers or SSL based VPNs are negotiating encryption with a server, there is no information which can be gleaned by the server in order to determine which virtual host the client is actually requesting.  This is due to the fact that the HOSTNAME of the subsequent request is contained in the encrypted header which would not be visible until after the received data was decrypted as it made its way down the stack.  This is problematic with respect to virtual hosting since each server or appliance can serve many hosts through the same address.  If it is desired to secure the data of that host through SSL, then a 1:1 mapping of hostname to IP address is currently required (not so good)

Client: (TLS Handshake) Hello, I support XYZ Encryption.
: (TLS Handshake) Hi There, Here is my Public Certificate, and lets use this encryption algorithm.
: (TLS Handshake) Sounds good to me.
: (Encrypted) HTTP Request
: (Encrypted) HTTP Reply

What about ‘STARTTLS’ or TLS ‘Upgrade’ in HTTP/1.1?

STARTTLS is another standard which is commonly used by protocols such as SMTP, POP, IMAP, and LDAP.  Back in the day, it was common practice to have parallel secure ports for most protocols.  For example,  with SMTP, POP, IMAP, and LDAP, and HTTP you have 25/465 110/995 145/993 389/636, and 80/443 respectively. The idea of  STARTTLS was born when the IETF which governs internet assigned numbers and ports decided back in 1997 at some meeting that the issuing of paralell “secure” ports for all protcols should be depricated.   With STARTTLS, when the connection to the server host is established, the client sends a plantext command with the virtual host name.  This has enough information for the server to decide which certificate to offer for the SSL/TLS handshake.

Client: (TLS Handshake) Hello, I support XYZ Encryption.
Client: (Cleartext) I am using server ‘
Server: (Cleartext) By The Way, I also support TLS Encryptionn.
Client: (Cleartext) Lets use Encryption, aka ‘STARTTLS’.
Client: (TLS Handshake) Hello, I support XYZ Encryption.
Server: (TLS Handshake) Hi There, Here is my Public Certificate, and lets use this encryption algorithm.
Client: (TLS Handshake) Sounds good to me.
Client & Server: (Encrypted) Exchange Data
 A similar method for web browsers, and SSL VPN clients was derived in the HTTP/1.1 specification and is called TLS Upgrade. HTTP/1.1 TLS Upgrade method can be applied to upgrade an open HTTP connection. In a nutshell, the client would include this in a request:
Upgrade: TLS/1.0
Connection: Upgrade
The server in turn might respond with:
HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
The main benefit with these methods are that you can have both naked and secure traffic traversing through the same  port.  Main problems to this and likely why these methods have not been adopted are that all methods would require that any proxy servers in between the client and server also support this method.  A proxy server that did not acknowledge it or perhaps strips the command (could also happen on a legacy firewall), would potentially present a man-in-the-middle attack.  A lesser issue might be that you have a user perception issue as there is a certain familiarity with port 443 being the “secure” port.  On the server end of things, you would also need to have the unsecure port open for the application in question which may not be the case.

The Solution

An extension to SSL/TLS called Server Name Indication (SNI) addresses this issue by sending the name of the virtual host as part of the SSL/TLS negotiation. This enables the server to bind the correct virtual host early and present the browser with the certificate containing a CN matching that in the SNI header.  This method also has far fewer complications associated with it as compared to TLS Upgrade or STARTTLS.  The SNI extension is described in gross detail here. With SNI, you would have a sequence like:

Client: (TLS Handshake) Hello, I support XYZ Encryption, and I am trying to connect to‘.
Server: (TLS Handshake) Hi There, Here is my Public Certificate, and lets use this encryption algorithm.
Client: (TLS Handshake) Sounds good to me.
Client: (Encrypted) HTTP Request
Server: (Encrypted) HTTP Reply

But Don’t Browser’s and Servers need to support this extension in order for this to work?

Yup, that is the idea.  As with any RFC, extension, or modification you have to have adoption by the software developers, and hardware vendors which in turn are driven by the adoption or request of the technology by the IT community.  The latter is only done through education and practical application examples which is one of my main drivers for writing this blog post.  At the time of this writing, there are no known Remote Access Appliances which support this RFC extension.  Below is the list of known browsers, servers, and SSL application libraries which do support the SNI extension:



  • Apache with mod_gnutls or mod_ssl
  • Cherokee if compiled with TLS support
  • New versions of lighttpd 1.4.x and 1.5.x
  • Nginx with an accompanying OpenSSL built with SNI support
  • OS X 10.5.6


  • Mozilla NSS
  • OpenSSL
    • 0.9.8f – not compiled in by default, can be compiled in with config option ‘–enable-tlsext’.
    • Unreleased 0.9.9 is likely to include SNI compiled in by default.

Unsupported Operating Systems Browsers, and Libraries

The following combinations do not support SNI.

  • Windows XP and Internet Explorer 6 or 7
  • Konqueror/KDE in any version
  • Microsoft Internet Information Server IIS
  • Sun Java System Web Server
  • Microsoft.Net
  • Sun Java JSEE

What SNI could add to SSL-based VPN Solutions?

So what does this mean with respect to Remote Access Solutions such as Citrix Access GatewayF5 Firepass, or Juniper Secure Access remote access solutions?  The benefits of adopting support for SNI are wide an varying, but here is my first pass at a few:

  • Since the SNI would be presented to the access appliance before the SSL negotiation finalized, specific SSL policies such as supported cipher suites, could be bound to the session.   This would be useful where you needed to meet more stringent security requirements such as FIPS level 1/2 for specific hosts, or where you had a client application which used a specific type of encryption that you needed to utilize.
  • As cloud computing is becoming more prevalent, service providers are going to need a means to offer customers secure access to their applications and content.  Since many cloud services are based on anycast addresses (floating IP), CNAME records, and also servicing 1000′s of users, a 1:1 option for customer:IP is not practical or possible. SNI presents a cheap, workable alternative to having no secure offering.
  • Enterprises who wish to publicly expose their intranet or line of business applications securely may want to do so through a remote access appliance, but not want to allocate multiple public IP addresses.
  • Businesses who have only been allocated a single IP address and are using Port Address Translation (PAT) to serve up multiple applications.  This is actually pretty common since many businesses are provisioned with ADSL which uses DHCP assign IP addresses. Most companies use a remote access device as an all-in-one solution for outbound RNAT, inbound VPN, and line of business applications, and firewall.

About CyberRuiz
Highly motivated with over 12 years experience on Citrix/VMWare/Microsoft/technologies. Exceptional communication skills and team player. CCIA – Citrix Certified Integration Architect. CCEA – Citrix Certified Enterprise Administrator. VCP – VMWare Certified Professional in ESX 2.x, VI3, VI4 MCSE – Microsoft Certified Systems Engineer

One Response to Server Name Indication (SNI) and SSL VPN

  1. awanflufy says:

    Boommm….this is what i call superb!

    Tnx for the great share mate…

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: