It’s been a while since we featured the SSL Profile, but some cool new features have emerged and everyone on DevCentral needs to know about them! In this article, we will look at several options that are now available for optimizing TLS connections using the BIG-IP.
This is the eleventh article in a series of Tech Tips that highlight SSL Profiles on the BIG-IP LTM. The first ten articles are:
In version 12.1, the BIG-IP offers dynamic record sizing, SSL signature hash, peer timeout options, and active handshake limits. To configure these options, navigate to Local Traffic >> Profiles >> SSL >> Client | Server. Note: the Client SSL profile offers each of these options, but the Server SSL profile only offers SSL Sign Hash and Max Active Handshakes. Here’s a quick screenshot of the GUI for that portion of the SSL profile screen:
Allow Dynamic Record Sizing
TLS record sizing can have a dramatic effect on the page load time of your web application. In order to optimize TLS record handling, the BIG-IP offers “Dynamic Record Sizing” which allows TLS records to change size so they can most efficiently interact with lower layer protocols like TCP.
A TLS record is typically set to be 16KB in size. The problem occurs when you try to fit a 16KB TLS record into lower layer protocol payloads like TCP segments. You see, TCP segments and TLS records are most often not the same size. So, what do you think happens? You’re right…this sizing problem can cause buffering and will force the TCP receiver to wait for all of the TCP segments to arrive before constructing the original-sized TLS record. Other causes of buffering can include packet loss, packet reordering, or throttling. So, who suffers the most from all this madness? The answer: your browser. Are today’s browsers optimized to handle all this craziness? Absolutely not.
The good news is that we can help our poor browsers by configuring the size of the TLS records we send. That’s where dynamic record sizing comes in. Dynamic record sizing is a TLS performance enhancement that helps prevent bottlenecks caused by the buffering of TLS record fragments. With dynamic record sizing, the BIG-IP dynamically adjusts the size of TLS records based on the state of the connection. For connections that tend to stay idle for a long time, it’s probably best for the BIG-IP to ensure a single TLS record is the same size as the max TCP segment size. However, for very active connections (like video streaming), it probably makes sense for a TLS record to get a little bigger and span multiple TCP segments.
The good news is that, to enable all this goodness, you simply have to check on box. Keep in mind that this option is only available on the Client SSL profile. The default setting for this feature is disabled.
Maximum Record Size
Remember all that dynamic record sizing we just talked about? And, remember how we said it might be good to limit the TLS record size in some cases? Well, you can explicitly limit the size of all TLS records coming out of your BIG-IP to a value that you choose.
The Maximum Record Size setting just exactly what you think it does. It defines the maximum size possible for a TLS record. If you enable dynamic record sizing, then the maximum record size you set is the largest size that the BIG-IP can use for a TLS record when that size is needed. If dynamic record sizing is disabled (the default value), then all record sizes are static and the size of each TLS record is the value of the maximum record size you specify.
To set the maximum record size, simply type a value for the Maximum Record Size setting. The default value (in kilobytes) is 16384. The range of possible values is 128 - 16384.
SSL Sign Hash
When digitally signing data, a hash function is used on the data to create a hash (a reduced, fixed-length form of the data that allows it to be used by the signature algorithm) and then the hash is encrypted with the signer’s private key. The SSL Sign Hash allows you to specify the hash algorithm used for server key exchange with Elliptic Curve ciphers. The possible choices are SHA1, SHA256, SHA384, or Any.
When you select “Any”, the BIG-IP chooses any one of the three hash algorithms, but it will choose SHA1 whenever possible. This configuration option is available on both the Client and Server SSL Profiles.
Peer No-renegotiate Timeout
SSL Renegotiation was covered in the sixth article of this series (so I won’t go into detail here). In the case where you expect a peer system to renegotiate the SSL session but that peer system does not renegotiate the session, you would want to have control over that situation and force a connection reset. The Peer No-renegotiate Timeout setting allows you to specify the number of seconds the BIG-IP will wait before resetting the connection to peer systems that do not renegotiate SSL sessions. You can specify a number of seconds or select “Indefinite”. The default is 10 seconds.
Max Active Handshakes
We all know that the SSL/TLS handshake is a very computationally expensive thing to go through. A system reboot (or other reset actions) can sometimes produce an excessive number of SSL/TLS handshakes, and none of us want excessive SSL/TLS handshakes going on. This can negatively impact the performance of your BIG-IP. To keep these handshakes to a manageable number, you can specify the Max Active Handshakes on a Client SSL or Server SSL profile to limit the number of concurrent handshakes.
When the number of active SSL/TLS handshakes pertaining to that specific SSL profile reaches the specified limit, the BIG-IP terminates the most recent handshake and also displays a message that the specified handshake limit has been reached. The BIG-IP also sends an alert message to other members of the device group.
The default value is “Indefinite”, which means that there is no limit on the number of active handshakes that the BIG-IP allows.
Keep in mind that you can set a limit for active handshakes (or any other setting for that matter) for each SSL profile. Knowing this, you can create several different SSL profiles for your various needs and then associate them accordingly to all your different virtual servers.
Thanks for your interest in this edition of the SSL profile series. We’ll be back with more goodness as the SSL profile features are expanded!