Last Modified: Jan 17, 2019
See more info
Known Affected Versions:
14.0.0, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206
Opened: Dec 07, 2017
In TLS v1.3, after initial handshake is established, the encrypted session ticket is encrypted by the back-end server. The SSL Session ID (SSID) parser, being only a passive listener, has no access to the decryption key required to decrypt the encrypted session ticket, and examine whether this is indeed a session ticket that needs to be cached for persistence.
Configurations using SSID Persistence with TLS versions up to and including 1.2, will be impacted. Whenever TLS 1.3 traffic is processed and the SSID filter is enabled: -- The filter switches to pass-through. -- No session ID or session ticket is cached for persistence. As a result: + The CLI command 'tmsh show ltm persistence persist persist-records' does not show any of this information. + No SSID persistence is used to load-balance client traffic on to a back-end server (because there is no persistence record).
This occurs when a client-side virtual server meets all of the following conditions: -- No SSL profile is enabled. -- SSID Persistence is one of the resources (i.e., the SSID is enabled). -- TLS v1.3 traffic is negotiated between the SSL client and the back-end SSL server, with the BIG-IP device acting as a passive listener between the client and the back-end server.
There is no solution possible with TLS v1.3. SSID does not work because of the very nature of the TLS v1.3 protocol. A TMM warning message is logged in the file "/var/log/ltm", in the following format: warning tmm: 01260044:4 SSID is not supported with TLS 1.3.
A TMM warning message is logged in the file '/var/log/ltm', in the following format: warning tmm: 01260044:4 SSID is not supported with TLS 1.3.