Repository navigation
Optimize (D)TLS 1.3 handshakes and disable session tickets - #1654
Open
aronrosenberg wants to merge 1 commit into
Open
aronrosenberg wants to merge 1 commit into
aronrosenberg wants to merge 1 commit into
Conversation
The OpenSSL DTLS and TLS transports offered the P-256 key exchange group only. A (D)TLS 1.3 client sends a key share for its first group only and browsers pick X25519, so a libdatachannel server answered every browser with a HelloRetryRequest, costing a round trip. This already happened for TLS 1.3 WebSockets with OpenSSL 3.x and now happens for DTLS 1.3 with OpenSSL 4.1. In (D)TLS 1.2, the groups also restrict the curve of the server's ECDSA certificate (RFC 8422 Section 5.3), so servers with a P-384 certificate could not be reached at all. Both transports now offer P-256:X25519:P-384, most preferred first. P-256 is a MUST for WebRTC (RFC 8827) and (D)TLS 1.3 (RFC 8446), so leading with it means no compliant peer needs a retry. X25519 is a SHOULD for (D)TLS 1.3 (RFC 8446) and in BCP 195 (RFC 9325), and is what browsers offer first. P-384 covers servers with P-384 certificates under (D)TLS 1.2. If the OpenSSL provider lacks a group, X25519 in FIPS mode for instance, P-256 alone is used as before. The GnuTLS and Mbed TLS defaults already include all three groups. Session tickets and the server session cache are now disabled, since in WebRTC DTLS sessions are never resumed. With OpenSSL 3.x, this removes about 480 bytes from the server's DTLS 1.2 handshake. The handshake log line now includes the negotiated (D)TLS version. A new "Key exchange groups" test runs a Chrome-like configuration (libwebrtc's default groups), the previous P-256-only configuration and the new one against each other as client and server, over (D)TLS 1.2 and 1.3. It checks the negotiated group, where HelloRetryRequests occur, and handshakes with a server whose certificate uses P-384.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Key exchange groups
The OpenSSL transports only offered P-256, unlike the GnuTLS and Mbed TLS backends, whose defaults already offer P-256, X25519, P-384 and more. This has two effects:
Both transports now offer
P-256:X25519:P-384If the OpenSSL provider lacks a group (X25519 in FIPS mode, for instance), the transports fall back to P-256 alone.
Session tickets
Session tickets are now disabled in all backends, and the session cache in OpenSSL, since WebRTC DTLS sessions are never resumed. With OpenSSL 3.x, this removes about 480 bytes from the server's DTLS 1.2 handshake. Disabling session tickets matches libwebrtc's behavior.
Logging
The handshake log line now includes the negotiated version, for example
DTLS handshake finished (DTLSv1.3).Tests
The new Key exchange groups test runs libwebrtc's default groups, the old P-256-only list and the new list against each other, as client and server, over (D)TLS 1.2 and 1.3. It checks the negotiated group, where HelloRetryRequests occur, and handshakes with a P-384 certificate. It runs in memory and skips on non-OpenSSL backends.