Bug ID 520891: Server initiated DTLS renegotiations behavior fails

Last Modified: Sep 13, 2023

Affected Product(s):
BIG-IP LTM(all modules)

Known Affected Versions:
11.4.1, 11.5.0, 11.5.1, 11.5.2, 11.5.3, 11.5.4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10, 11.6.0, 11.6.1, 11.6.2, 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.1.0 HF1, 12.1.0 HF2, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2

Fixed In:
12.0.0

Opened: Apr 30, 2015

Severity: 3-Major

Symptoms

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.

Impact

Non-conforming DTLS clients will fail to renegotiate.

Conditions

Server SSL renegotiation is enabled on DTLS connections.

Workaround

Do not use Server-initiated renegotiation.

Fix Information

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.

Behavior Change

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.

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips