cancel
Showing results for 
Search instead for 
Did you mean: 

1. Preliminary Information

In one of my discussions with a couple of community members, we discussed the use of TLS caching as a powerful way to improve performance, TLS-wise. With the increase of Internet traffic globally due to COVID-19, this is an important concept to grasp.

This is the topology I used to perform the tests:

0151T000003WG9WQAW.png

Both client and server SSL profiles have cache-size set to 1:

0151T000003WG9gQAG.png

If you just want to know how TLS Caching works, move straight to Lab Test Results section.

2. What we need to know upfront

First off we should learn that there is a global db variable for tmm's cache size with min and max values:

0151T000003WG9hQAG.png

TMM is BIG-IP's forwarding plane daemon.

The other things we should be aware of:

  • tmm.ssl.cache is the global value enforced per TMM, not split among all tmms.
  • cache-size is a local value per virtual server
  • Setting SSL Profile's Cache Size option (cache-size in tmsh) to zero (0) disables SSL session caching
  • SSL Profile's Cache Size is also enforced per TMM
  • When either Cache Size or the value of tmm.ssl.cache limit is reached on a given tmm (whichever is reached first), oldest entry is removed (evicted) from SSL cache to give room to new entry (reference: https://support.f5.com/csp/article/K6767).
  • tmm.ssl.cache is configurable from 11.5.0+ (reference: https://support.f5.com/csp/article/K16303).

3 Lab Test Results

  • For Client SSL profile, BIG-IP uses Session ID or Session Ticket to look up TLS session entries in local SSL cache.
  • If Session ID or Session Ticket is changed, it is a cache miss.
  • For Server SSL profile, BIG-IP uses back end server's IP address and destination port for the lookup in order to find corresponding Session ID or Session Ticket to be presented to back-end server so session can be resumed.

Note: To learn about the difference between Session ID and Session Ticket, please refer to this article here.

4. Client SSL behaviour

In the beginning cache is clear:

0151T000003WG8JQAW.png

I then send first request making sure I save session information locally:

0151T000003WG8KQAW.png

New TLS Cached Session

We then see first cache entry populated with 1 lookup but no hits yet since this is new cache entry:

0151T000003WG8OQAW.png

TLS Cache Hit

Next, I send 2nd request reusing the same SSL session using OpenSSL:

0151T000003WG8TQAW.png

And fair enough we see our first cache hit (note that lookup also increases):

0151T000003WG8PQAW.png

TLS Cache Overflow

I'm now going to create a new TLS session with no session reuse:

0151T000003WG8YQAW.png

And now we see first overflow because it is a cache miss and as the max cache size is set to 1.

The new cache entry overwrites oldest cache entry:

0151T000003WG8dQAG.png

Now let's move on to Server SSL profile.

5. Server SSL behaviour

New TLS Cached Session

Sent first request:

0151T000003WG8eQAG.png

The usual entry added to cache and 1 lookup:

0151T000003WG8iQAG.png

TLS Cache Hit

Sent 2nd request intentionally using curl again (not reusing previous TLS session information):

0151T000003WG8nQAG.png

But we still see a cache hit!

0151T000003WG8LQAW.png

The reason is because on Server SSL side BIG-IP no longer uses Session ID/Session Ticket information to to retrieve cached entry. Remember, on Server SSL side, BIG-IP is the client!

Instead, BIG-IP uses destination server and port to retrieve previously stored session ID/Session ticket and send it over to back-end server in Client Hello message in order to resume session.

That's why we had a cache hit here!

TLS Cache Overflow

For this particular overflow test, I've added a 2nd pool member to our pool (172.16.199.32) because Server SSL profile uses destination IP and port to retrieve cached TLS session, which wouldn't change if we use the same pool member, would it?

0151T000003WG9lQAG.png

Now I've issued a 3rd request (load balanced to new pool member this time):

0151T000003WG9qQAG.png

And now we see overflow because pool member is a different one:

0151T000003WG9rQAG.png

This should give enough insight to understand how TLS caching works and to troubleshoot any related issues.

Version history
Last update:
‎16-Apr-2020 08:20
Updated by:
Contributors