Expose TLS session resumption, and answer honestly about 0-RTT - #7
Open
xl32 wants to merge 1 commit into
Open
Conversation
Session tickets were left entirely to OpenSSL's defaults, so an operator had no way to see or change whether the server hands out resumable sessions, and no answer at all about 0-RTT. Add H3SessionTickets (default on, matching the previous behaviour) which maps to SSL_CTX_set_num_tickets, and set a session id context so tickets this server issues are only resumed against its own sessions. Worth knowing when reading the docs: each worker process keeps its own ticket keys, so a client resumes only when it returns to the process that issued its ticket, and otherwise falls back to a full handshake. 0-RTT is the harder question. OpenSSL's own QUIC stack does not accept early data on the server side, so simply wiring a directive to SSL_CTX_set_max_early_data would produce a setting that reads as enabled and does nothing. Instead add an early_data capability bit to quic_caps, which the engines answer for themselves, and have post_config warn -- naming the engine -- when H3EarlyData is on but the engine cannot honour it. The setting is plumbed through quic_settings so an engine that gains server-side 0-RTT needs no further work here, and defaults to off because 0-RTT data is replayable by design.
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
1 participant
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.
Session tickets were left entirely to OpenSSL's defaults, so an operator had no way to see or change whether the server hands out resumable sessions, and no answer at all about 0-RTT.
Add H3SessionTickets (default on, matching the previous behaviour) which maps to SSL_CTX_set_num_tickets, and set a session id context so tickets this server issues are only resumed against its own sessions. Worth knowing when reading the docs: each worker process keeps its own ticket keys, so a client resumes only when it returns to the process that issued its ticket, and otherwise falls back to a full handshake.
0-RTT is the harder question. OpenSSL's own QUIC stack does not accept early data on the server side, so simply wiring a directive to SSL_CTX_set_max_early_data would produce a setting that reads as enabled and does nothing. Instead add an early_data capability bit to quic_caps, which the engines answer for themselves, and have post_config warn -- naming the engine -- when H3EarlyData is on but the engine cannot honour it. The setting is plumbed through quic_settings so an engine that gains server-side 0-RTT needs no further work here, and defaults to off because 0-RTT data is replayable by design.