-
Notifications
You must be signed in to change notification settings - Fork 678
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement client support for TLS 1.3 0-RTT #185
Conversation
Thanks, this is great work! I'd like to keep the early and main application data streams separate though. I'll experiment with some alternative APIs and report back on this PR. |
This adds: - ClientSession::early_data() which may return a WriteEarlyData if early data is possible with the server. WriteEarlyData implements io::Write and also tells how many bytes can be written. - ClientSession::is_early_data_accepted which returns true if early data was signalled as accepted by the server. Update the 0rtt example with some docs for this.
I've pushed a commit which uses your work and presents a slightly different API. Could you review it and make sure it meets your requirements? |
@ctz The new API looks good to me. In particular I like the new |
Thanks. This has been merged now. |
Here's my take at implementing TLS 1.3 0-RTT for resumed client sessions. It passes BOGO and works with Cloudflare's TLS 1.3 0-RTT implementation.
Both Issue #84 and the TLS 1.3 draft discuss about the risk of using 0-rtt data. So 0-RTT is by default disabled. A user who wishes to send 0-RTT data to HAProxy or Cloudflare should set
ClientConfig.enable_early_data
and callClientSession::write_all()
before the handshake starts.Two new Session APIs,
is_in_early_data
andis_early_data_accepted
are added.is_in_early_data
returnstrue
if any early data is in flight or ready to be sent. This implies a handshake is in process andis_handshaking()
must betrue
.is_early_data_accepted
returnstrue
if the server has processed the 0-RTT data and the client has sentEndOfEarlyData
. This API should be called after the handshake is completed.A
max_early_data_size
field is added topersist::ClientSessionValue
to indicate the maximum bytes of plaintext that can be sent as early data. This limit is enforced inSession::send_plain()
.The following BOGO test cases are turned on and passed.
PASSED (TLS13-SendTicketEarlyDataInfo)
PASSED (TLS13-SendTicketEarlyDataInfo-Disabled)
PASSED (TLS13-EarlyData-TooMuchData-Client-Sync)
PASSED (TLS13-EarlyData-TooMuchData-Client-Sync-ImplicitHandshake)
PASSED (TLS13-EarlyData-TooMuchData-Client-Sync-SplitHandshakeRecords)
PASSED (TLS13-EarlyData-TooMuchData-Client-Sync-PackHandshake)
PASSED (TLS13-EarlyData-TooMuchData-Client-Async)
PASSED (TLS13-EarlyData-TooMuchData-Client-Async-ImplicitHandshake)
PASSED (TLS13-EarlyData-TooMuchData-Client-Async-SplitHandshakeRecords)
PASSED (TLS13-EarlyData-TooMuchData-Client-Async-PackHandshake)
PASSED (EarlyData-Client-TLS13Draft23)
PASSED (EarlyData-Reject-Client-TLS13Draft23)
PASSED (EarlyData-HRR-Client-TLS13Draft23)
PASSED (EarlyDataWithoutResume-Client-TLS13Draft23)
PASSED (EarlyDataVersionDowngrade-Client-TLS13Draft23)
PASSED (ServerAcceptsEarlyDataOnHRR-Client-TLS13Draft23)
PASSED (EarlyData-Client-VersionAPI-TLS13Draft23)
PASSED (EarlyData-Client-BadFinished-TLS13Draft23)