on 11-Jul-2013 15:41 - edited on 24-Mar-2023 18:12 by LiefZimmerman
This is the tenth article in a series of Tech Tips that highlight SSL Profiles on the BIG-IP LTM.
The first nine articles in this series highlighted many important SSL features on the BIG-IP. In this article, I will overview some of the features that were not highlighted in the first nine articles. This article will feature the Proxy SSL option, ModSSL Methods option, Session Caching (size and timeout), Strict Resume (with a little sprinkle of Unclean Shutdown), Session Ticket, and Non-SSL Connections. Many of these are a simple checkbox on the BIG-IP GUI, but they are still important features of the SSL profile! So, sit back, grab a healthy helping of your favorite beverage (mine is Ski), and enjoy this final article in the SSL profile series.
Here's a quick screenshot of the features that we will highlight in this article. As always, you can find these features by navigating to Local Traffic > Profiles > SSL > Client | Server.
When you set up the BIG-IP to process your application data, you might want the destination server to authenticate the client directly instead of relying on the BIG-IP to perform this function. You may have a web application firewall in place to secure the communications between requesting clients and the service. In this case, you might want to implement Proxy SSL. Proxy SSL gives the server the final authority in allowing or denying client access. Retaining direct client-server authentication provides full transparency between the client and server systems. This feature is disabled by default, but in order to enable it you must configure both the Client and Server SSL profiles and check the "ProxySSL" box on each profile. It's important to note that the certificate and key that you specify in the Server SSL profile must match the certificate/key pair that you expect the backend server to offer. If the backend server has more than one certificate/key pair, then you must create a separate Server SSL profile for each one. When all profiles (Client and Server) are created, you assign them to the virtual server that will handle the SSL traffic.
Without the Proxy SSL feature enabled, the BIG-IP establishes separate client-side and server-side SSL connections and then manages the initial authentication of both the client and server systems. With the Proxy SSL feature, the BIG-IP enables direct client-server authentication by establishing a secure SSL tunnel between the client and server systems and then forwarding the SSL handshake messages from the client to the server and vice versa. After the client and server successfully authenticate each other, the BIG-IP system uses the tunnel to decrypt the application data and manipulate (optimize) the data as needed.
ModSSL is an optional module for Apache HTTP servers that provides strong cryptography by using SSL and TLS protocols. This module relies on OpenSSL to provide the cryptography engine. The ModSSL package for Apache servers includes benefits like:
If you are using Apache HTTP servers in your environment, this BIG-IP feature will be nice to have. For more on the Apache ModSSL module, check out this link. To enable ModSSL method emulation, simply check the box. Be aware that it is disabled by default.
The Cache Size setting specifies the number of SSL sessions allowed in the cache. If you want to disable SSL session caching for a profile, you simply set the Cache Size to zero. The SSL session Cache Size limits the number of sessions that are cached for a particular profile. When the cache limit is reached, the oldest SSL session associated with that profile is deleted from the cache and the new SSL session is added to the cache.
SSL caching is beneficial especially when dealing with SSL session resumption. The ability to cache and reuse SSL session IDs can increase transactions per second by limiting processor-intensive key exchange functions.
While the Cache Size can be configured for each SSL profile, it's important to note that the combined total Cache Size of all active SSL profiles on a BIG-IP is limited by the global session cache size, and the global session Cache Size setting is not configurable. The default and global Cache Sizes for an SSL profile differs based on BIG-IP versions:
If you create several SSL profiles, be sure to limit the total Cache Size to a value less than or equal to the global Cache Size value of the BIG-IP version you are running (using the values listed above). If the combined total Cache Size of all SSL profiles is larger than the global limit, you might run into sharing problems where entries on one virtual server may be deleted from cache in favor of another virtual server even if the Cache Size for that profile has not been reached.
Cache Timeout is an easy one...it simply specifies the timeout value (in seconds) of the SSL session cache entries. There are two options for Cache Timeout on the dropdown menu: Specify and Indefinite. The default is set to Specify: 3600. The indefinite setting simply means the cache entries in the SSL session will never time out. If you have an issue with hitting your limit on Cache Size, you will want to avoid the Indefinite setting for Cache Timeout. On that same note, if you have Cache Size limit issues, you can decrease the value of the Cache Timeout setting until you find a happy place for your session cache. Finally, if you are running < v10.1.0, just upgrade and you'll get tons of extra cache space!
The Strict Resume feature is also pretty straightforward. However, I'll warn you...this setting can get into that weird space of double-negatives. So, unless you really want to think through this one, you should just keep the default settings on everything.
If you disable Strict Resume (the default value), the BIG-IP will resume SSL sessions after an unclean shutdown. If you enable this setting, the system will not resume SSL sessions after an unclean shutdown. Essentially, the system is either going to be strict about session resumption or not (enabled / disabled respectively).
So, we've mentioned the term "unclean shutdown" because it is important relative to Strict Resume, but what is it? As you can imagine, a "clean shutdown" is the way the SSL protocol was designed to handle the issue of terminating SSL connections. The SSL protocol performs a clean shutdown of an active SSL connection by sending a close notify alert to the peer system. On the other hand, the "unclean shutdown" closes the underlying connections without sending the SSL close notify alerts. The "Unclean Shutdown" is enabled on the BIG-IP by default because certain web browsers handle SSL shutdown alerts differently. For example, some versions of Internet Explorer require SSL shutdown alerts from the server while other versions do not, and the SSL profile can't always detect this requirement. So, be aware of the way the "Strict Resume" and "Unclean Shutdown" settings interact with one another.
Pop quiz: If "Unclean Shutdown" is disabled, does it matter what you do with the "Strict Resume" setting?
This setting enables or disables the use of SSL session tickets. Session tickets are outlined in RFC 5077. This setting is disabled by default. Session Tickets enable the server to resume SSL sessions and avoid keeping per-client session states. To accomplish this, the server encapsulates the session state into a ticket and forwards it to the client. The client can then subsequently resume a session using the obtained ticket.
This setting enables or disables the acceptance of non-SSL connections. The BIG-IP will still accept SSL connections if this setting is enabled, but it will also accept non-SSL connections. This setting is disabled by default. If enabled, non-SSL connections will pass through the BIG-IP in clear-text. So, obviously, proceed with caution on this one. I'm not saying there's not a reason out there to use this setting, but you should be certain of what you are doing before clicking the box on this one!
Well, that does it for this SSL article. We will continue to post new articles highlighting the SSL profile as new features are introduced. If you have any questions feel free to leave a comment here or Contact DevCentral directly
I have one quest about Mod_SSL.
I want know were I apply this funcion. In client or server SSL profile?
I belive that is in server SSL profile, but what´s benefits?