Bug ID 1577161: BIG-IP tries to resume SSL sessions when session ID only matches partially

Last Modified: Oct 18, 2025

Affected Product(s):
BIG-IP LTM(all modules)

Known Affected Versions:
12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.5.1, 14.1.5.6, 15.1.10.4, 15.1.10.5, 15.1.10.6, 16.1.3.5, 16.1.4, 16.1.4.1, 16.1.4.2, 16.1.4.3, 16.1.5, 16.1.5.1, 16.1.5.2, 16.1.6, 17.1.1.2, 17.1.1.3, 17.1.1.4, 17.1.2, 17.1.2.1, 17.1.2.2, 17.1.3

Opened: Apr 10, 2024

Severity: 3-Major

Symptoms

After receiving the SSL session ID which partially matches a session ID in the cache VIP with the client SSL profile attempts to resume the session. For example - there is an existing Session ID: session_id[32]= 28 67 9b 30 dc 8a 6e f4 d1 ef 80 f9 04 93 d6 3d fb 2e ea b5 ac c2 be f1 6b e7 42 ef 54 a3 a6 cd When a client sends Client Hello with resume [32]= 12 11 11 12 12 12 12 12 11 11 80 f9 04 93 d6 3d fb 2e ea b5 ac c2 be f1 6b e7 42 ef 54 a3 a6 cd BIG-IP resumes the session.

Impact

The BIG-IP sends a ServerHello with a different Session ID from the one in the ClientHello and then attempts to resume a TLS session.

Conditions

- Create VIP with client SSL profile. - Create a new TLS session (for example with 'openssl s_client') - Try to reuse the existing session with some of the bytes of the session ID altered.

Workaround

None

Fix Information

None

Behavior Change

If a client presents a non-zero session_id, but BIG-IP cannot find a corresponding session in its cache, the 'Session Cache Lookups' counter in the client-ssl profile will not be incremented. This behavior change only affects the statistics and does not alter the actual session resumption functionality. If the client's session_id matches a cached session, session resumption will still occur normally, and the 'Session Cache Lookups' counter will be incremented as expected.

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips