Last Modified: Apr 10, 2019
See more info
Known Affected Versions:
11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9
Opened: Feb 13, 2016
An SSL client can fragment a handshake message into multiple pieces (a fragmented set of handshakes). When BIG-IP receives such an SSL fragmented set of handshakes, it fails to recognize and reassemble the fragments. One of the ways in which this is happening is when Big-IP receives an SSL client certificate chain containing a large number of issuers. BIG-IP receives this as a fragmented set of handshakes and is unable to recognize as such. For RSA-4096, if the certificate chain contains at least 20 issuers, a handshake error is reported from BIG-IP and the connection is aborted.
When receiving fragmented ssl handshake message, the handshake fails, if tmm debug logging is enabled you will see "debug tmm1: 01260009:7: Connection error: ssl_hs_pxy_scan:9143: malformed ssl record (47)"
The condition, below, is one among a few possible cases if the clientssl profile is configured with proxy-ssl enabled. - Client certificate chain has a depth of at least 20, for RSA-4096 client certificates and its issuers. (For RSA-2048, the depth is more. We don't know at the moment how much.) This assumes that all certificates (including issuers) possess the same key-length (4096 for RSA). If the key length differs in any one, the depth threshold may be more (if shorter key length) or less (if larger key length).
One of the ways in which the issue is triggered is with very large client certificates. This particular case can be mitigated. The workaround is to use client certificate chains that have a depth of up to 19 (for RSA-4096). The sub-case mentions the workaround through the removal of advertised certificates.