Last Modified: Dec 03, 2018
See more info
Known Affected Versions:
12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124
14.0.0, 13.1.1, 126.96.36.199
Opened: Jan 11, 2018
SSL handshake fails if the client initiates the handshake with TLS false start (specifically, client SSL sends the SSL record data to the server before the Server sends out the CSS is FINISHED notification).
The BIG-IP system sends the RST to tear down the connection in TLS false start.
1. Client initiates the SSL handshake with False Start. 2. The BIG-IP system has SSL hardware acceleration enabled (which is default for for non-virtual edition (VE) versions).
There are no true workarounds. You must disable one of the conditions to workaround the issue: -- Disable TLS False Start. (Note: this might not be feasible because it needs to be done on all clients.) -- Disable SSL acceleration. -- Disable AES-GCM ciphers in the client SSL profile. Without AES-GCM, clients do not try to use TLS false start and still be able to use (EC)DHE.
The system no longer processes application data before verifying that the finished message arrives and handshake is complete.