Last Modified: Nov 07, 2022
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 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, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6
Fixed In:
13.0.0, 12.1.3.7
Opened: Dec 10, 2016 Severity: 3-Major Related Article:
K46042053
Clients are unable to establish an SSL session. If the backend server sends a Certificate Request with Signature Hash Algorithms set to SHA256, the server SSL profile responds with Certificate and Certificate Verify containing a signature signed by SHA1 when ssl-sign-hash in that profile is set to 'ANY'. Because the backend server does not expect SHA1, the handshake fails. If the BIG-IP server SSL profile advanced configuration setting for SSL sign hash is set to SHA-256 (and not ANY), the handshake fails with the following error: Connection error: ssl_hs_rsaprivenc:8528: no shared hash algorithm (40).
BIG-IP systems sign the TLS handshake with the SHA1 algorithm, which fails on the server. Note that this issue is orthogonal to the issue of hash algorithm in X.509 certificates, e.g., 'SHA1 in X.509 certificates'.
* BIG-IP system is communicating with a TLS server (applies to server SSL profiles). * TLS server is requesting client authentication (this is less common). * TLS client is using the supported_signature_algorithms extension (this is very common) * TLS 1.2 is likely needed. TLS 1.0 does not support extensions. * SSL sign hash for the server SSL profile is set to either 'any' or 'sha-256'.
No mitigation is known.
BIG-IP now properly parses the following extension in CertificateRequest by a TLS server.: SignatureAndHashAlgorithm supported_signature_algorithms<2^16-1>. This allows the existing logic to work, in particular, to learn that the server supports SHA2 family of hash algorithms and use them with the signature in the TLS handshake.
