TLS 1.3 server: Parsing of the early data indication extension

Mbed-TLS / mbedtls

An open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.

https://www.trustedfirmware.org/projects/mbed-tls/

Other

5.56k stars 2.61k forks source link

TLS 1.3 server: Parsing of the early data indication extension #6331

Closed ronald-cron-arm closed 9 months ago

ronald-cron-arm commented 2 years ago

This issue tracks the up-streaming on server side of the parsing of the early data indication extension

Source: https://github.com/hannestschofenig/mbedtls/tree/tls13-prototype

PLEASE READ THOROUGHLY section 4.2.10 of the specification

[x] Parse the early data indication extension in the ClientHello and note down its reception in ssl->handshake->extensions_present.
[ ] Abort the handshake if an early data indication extension is received in a second ClientHello (in response to the server sending an HRR)

Testing: test (ssl-opt.sh test) with a GnuTLS client (not possible with an OpenSSL client I think) that a "resumption" ClientHello containing an early data indication extension is successfully parsed by the MbedTLS server. The resumption handshake is expected to fail at this stage.

Depends on #6330

yuhaoth commented 2 years ago

Parse the early data indication extension in the ClientHello and note down its reception in ssl->handshake->extensions_present.

This can be resolved by #6170

yuhaoth commented 2 years ago

https://github.com/Mbed-TLS/mbedtls/pull/6486#discussion_r1017966532 , reference this thread. That includes an idea about internal state machine.

Below is the idea

That is about internal states on server side.

NOT_RECEIVED: Initial state
REJECTED: Reject the following up early app data. In this state, decrypt error will be ignore.
ACCEPTED: Accept the following up early app data. In this state, early_data indication will sent.

State machine

NOT_RECEIVED -> REJECTED : early_data extension is received (ClientHello)
REJECTED->ACCEPTED: If early data is allowed(valid ticket, early_data_enabled and so on), otherwise do not change it. this step should be done in post_client_hello.

For client side, I guess 3 states are enough.

NOT_SENT: Initial state
REJECTED(or SENT): If early data indication is sent, change to it. Early app data can be sent in this state before CLIENT_FINISHED. RFC8446 A.2
ACCEPTED: If early data is received in EE, change to it.

ronald-cron-arm commented 2 years ago

Only one PR out of three merged so far.

yuhaoth commented 1 year ago

Abort the handshake if an early data indication extension is received in a second ClientHello (in response to the server sending an HRR)

This point should be resolved in #6361. If the 0-RTT data is not ignored, server will raise unexpected message before 2nd client hello arrived.We can workaround it with current code, but HRR case will be covered by two issues.

mpg commented 9 months ago

@ronald-cron-arm I guess this should still be open (two PRs in but one more pending), and then merging #8727 will close it for real?

mpg commented 9 months ago

(Re-opened by mistake, #8727 is addressing #6361 not this.)