SSL Profiles Part 7: Server Name Indication

This is the seventh article in a series of Tech Tips that highlight SSL Profiles on the BIG-IP LTM.  The other articles are:

1. SSL Overview and Handshake
2. SSL Certificates
3. Certificate Chain Implementation
4. Cipher Suites
5. SSL Options
6. SSL Renegotiation
7. Server Name Indication
8. Client Authentication
9. Server Authentication
10. All the "Little" Options

This article will discuss the concept of Server Name Indication (SNI) and how the BIG-IP system allows you to configure it for your environment.

What is Server Name Indication?

SNI (listed in RFC 4366) is an extension to the TLS protocol that allows the client to include the requested hostname in the first message of the SSL handshake (Client Hello). This allows the server to determine the correct named host for the request and setup the connection accordingly from the start.  Prior to the introduction of SNI, the client could not establish secure connections to multiple virtual servers hosted on a single IP address.  This happened because the destination server name can only be decoded from the HTTP request header after the SSL connection has been established.  As you can see from the following diagram (taken from Jason Rahm's first article in this series), the standard TLS handshake involves several messages between the client and the server.  The server sends the certificate (step 3) to the client long before the handshake is complete. 

If a web server is used to host multiple DNS hostnames on a single IP address, the certificate passing between the server and the client could get problematic.  Using the standard TLS protocol, the server might send the wrong certificate to the client because it does not yet know which certificate the client is looking for.  Then, if the client receives a certificate with the wrong name, it will either abort the connection (assuming a Man-in-the-Middle attack) or at least display a warning page to the user stating that there is a problem with the certificate.  This scenario is shown in the following figure.  A client wants to visit https://www.securesite1.com, but the virtual web server doesn't know to pass the certificate for securesite1.com until it finishes the TLS handshake and reads the HTTP request header from the client. 

This is where SNI comes in really handy.  With the introduction of SNI, the client can indicate the name of the server to which he is attempting to connect as part of the "Client Hello" message in the handshake process.  The server then uses this information to select the appropriate certificate to return to the client when it sends back the "Server Hello" packet during the handshake.  This allows a server to present multiple certificates on the same IP address and port number and thus allows multiple secure (HTTPS) sites to be served off the same IP address without requiring all the sites to use the same certificate.

Having this extension available (per RFC 4366) is a great feature, but it does no good if a client is using a browser that doesn't send the correct SNI message to the server.  So, to make SNI practical, the vast majority of your users must use web browsers that support it.  Browsers that do not support SNI will be presented with the server's default certificate and are likely to receive a certificate warning.  According to Wikipedia, the following browsers support SNI:

Internet Explorer 7 or later, on Windows Vista or higher. Does not work on Windows XP, even Internet Explorer 8 (the support of this feature is not browser version dependent, it depends on SChannel system component which introduced the support of TLS SNI extension, starting from Windows Vista, not XP).
Mozilla Firefox 2.0 or later
Opera 8.0 (2005) or later (the TLS 1.1 protocol must be enabled)
Opera Mobile at least version 10.1 beta on Android
Google Chrome (Vista or higher. XP on Chrome 6 or newer. OS X 10.5.7 or higher on Chrome 5.0.342.1 or newer)
Safari 3.0 or later (Mac OS X 10.5.6 or higher and Windows Vista or higher)
Konqueror/KDE 4.7 or later
MobileSafari in Apple iOS 4.0 or later
Android default browser on Honeycomb (v3.x) or newer
Windows Phone 7
MicroB on Maemo
Odyssey on MorphOS

Now that you know the background of SNI, let's dig into how the BIG-IP is set up for SNI configuration.

BIG-IP Configuration

Beginning in v11.1.0, the BIG-IP allows you to assign multiple SSL profiles to a virtual server for supporting the use of the TLS SNI feature.  The TLS SNI feature is not available in previous BIG-IP versions, so you'll want to upgrade if you are not on v11.1.0 or higher!  To support this feature, a virtual server must be assigned a default SSL profile for fallback as well as one SSL profile per HTTPS site.  The fallback SSL profile is used when the server name does not match the client request or when the browser does not support the SNI extensions.  

Using the example from the figures above, suppose you need to host the three domains securesite1.com, securesite2.com, and securesite3.com on the same HTTPS virtual server. Each domain has its own server certificate to use, such as securesite1.crt, securesite2.crt, and securesite3.crt, and each has different security requirements.  To ensure that the BIG-IP presents the correct certificate to the browser, you enable SNI, which sends the name of a domain as part of the TLS negotiation. To enable SNI, you configure the Server Name and other settings on an SSL profile, and then assign the profile to a virtual server.  For SSL profiles (Client and Server), you type the name for the HTTPS site in the Server Name box.  

SNI configuration is found by navigating to Local Traffic > Profiles > SSL > Client | Server.  The following screenshot shows the three settings used for SNI in the BIG-IP.

Server Name specifies the fully qualified DNS hostname of the server that is used in SNI communications. Using the server name, the Local Traffic Manager can choose from multiple SSL profiles prior to the SSL Handshake.  If no value is specified, the system uses the Common Name value from the default certificate.  The default for this setting leaves the name blank.

Default SSL Profile for SNI indicates that the system uses this profile as the default SSL profile when there is no match to the server name, or when the client provides no SNI extension support.  Note that when assigning multiple SSL profiles to a single virtual server, you can enable this setting on one Client SSL profile only and on one Server SSL profile only.  The default for this setting is unchecked.

Require Peer SNI support requires that all network peers provide SNI support as well. If you enable both "Default SSL Profile for SNI" and "Require Peer SNI Support," the system terminates the connection when the client provides no SNI extension.  The default for this setting is unchecked.

Conclusion

I hope this helps with setting up this great feature in your environment.  SNI is a powerful tool, and it could go a long way in saving you precious IP addresses for your secure sites!  As we noted before, this feature is only supported in BIG-IP version 11.1.0 and later.  If you are using a version prior to 11.1.0, you can read this article on DevCentral that shows how you can use an iRule to take advantage of SNI on previous versions.  Finally, you can read more on our DevCentral Wiki about using iRules for SNI .

Well, thanks for reading about SNI.  Be sure to come back for the next article in the SSL series where I will talk about SSL Forward Proxy.  See you then!