Last Modified: Jul 13, 2024
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.4.1, 11.5.0, 11.5.1, 11.5.1 HF1, 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.1 HF10, 11.5.1 HF11, 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, 11.5.10, 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
Fixed In:
12.0.0
Opened: Apr 30, 2015 Severity: 3-Major
The sequence number when using server initiated DTLS renegotiation has changed. Formerly, the ServerHello was sequence number 0, now it is sequence number 1. This corresponds with a change in OpenSSL to become RFC compliant. That means that existing server-initiated DTLS renegotiation cannot complete successfully.
Non-conforming DTLS clients will fail to renegotiate.
Server SSL renegotiation is enabled on DTLS connections.
Do not use Server-initiated renegotiation.
The sequence number when using server initiated DTLS renegotiation has changed. Formerly, the ServerHello was sequence number 0, now it is sequence number 1. This corresponds with a change in OpenSSL to become RFC compliant. The system will retain the previous behavior on the server which is not compliant with RFC. This is required to maintain compatibility with clients that are already deployed. The client behavior now accepts both RFC-compliant and non-compliant re-negotiation requests from the server.
The sequence number when using server initiated DTLS renegotiation has changed. Formerly, the ServerHello was sequence number 0, now it is sequence number 1. This corresponds with a change in OpenSSL to become RFC compliant. DTLS renegotiation: New OpenSSL 1.0.1l+ treats Hello Request message as message sequence to 0, so Server Hello should be 1 when Hello Request is sent for renegotiation. The system will retain the previous behavior on the server which is not compliant with RFC. This is required to maintain compatibility with clients that are already deployed by customers. The client behavior now accepts both RFC-compliant and non-compliant re-negotiation requests from the server.