Early Data(0-RTT) support?

[love4taylor]

Hi, I wonder if it is possible to support 0-RTT detection??

[drwetter]

To do it properly one needs to handle the encryption keys which is in sockets at minimum not easy.

In openssl 1.1.1 that seems easy:

prompt% openssl s_client -tls1_3 -sess_out openssl.sess -connect  testssl.net:443 -servername testssl.net  </dev/null
prompt% openssl s_client -tls1_3 -sess_in openssl.sess -early_data /dev/null -connect  testssl.net:443 -servername testssl.net </dev/null

If you look at the output in the second call you should see "Early data was accepted".

Another possibility could be just to fingerprint the server but I haven't looked at it yet and it would be more of a guess and it would be server depended. We would detect e.g. the TLS extension 42 but it doesn't work with https://testssl.net as we don't send the extension in the first place.

OpenSSL 1.1.1 sends it only if you provide session data and early data (add -trace to the commands above).

@dcooper16 might have more insights.

[dcooper16]

Hi Dirk,

I'm not very familiar with how 0-RTT works, but from my understanding of RFC 8446, it may not be possible to reliably test for 0-RTT. It may be possible to write a test that will generally work in practice (using OpenSSL), but not one that is guaranteed to always work.

According to RFC 5077, for TLSv1.2 and earlier the client can request a session ticket in the ClientHello, and if the server is going to provide one it provides it "during the TLS handshake before the ChangeCipherSpec message." The server also includes a session ticket extension in the ServerHello.

The situation is very different for TLSv1.3, however, if I understand correctly. There doesn't seem to be anything in the initial ClientHello or ServerHello, and the server can send the NewSessionTicket "At any time after the server has received the client Finished message."

Perhaps in practice all TLSv1.3 servers that send session tickets will send a NewSessionTicket message immediately after receiving the client Finished message, but unlike with RFC 5077, we can't assume that just because a NewSessionTicket hasn't been received that the server doesn't support session resumption (and possibly early_data).

I tried the test that you did above, but did not get the same results. When I ran

prompt% openssl s_client -tls1_3 -sess_out openssl.sess -connect  testssl.net:443 -servername testssl.net  </dev/null

I did not receive a new session ticket and "openssl.sess" was not created. If I remove the "</dev/null", however, then I do receive a new session ticket.

I think the "</dev/null" causes the connection to be closed immediately after it has been created, which is before the server has a chance to send a NewSessionTicket.

So, my guess would be that we could use OpenSSL (1.1.1 or later) to test for 0-RTT that would usually work, but we couldn't definitively say the server doesn't support 0-RTT if a NewSessionTicket isn't received in the first call to $OPENSSL s_client.

[drwetter]

Hi David,

as said, I am with you on most points, including the familiarity ;-)

I wouldn't look primarily at the session tickets though. Strategically we

A. could consider a later OpenSSL LTS version for then next development stage, likely 1.1.1, we need to know the catches before though :-) .
B. do a educated guess on an indicator. My first hope is the extension 0x2A (42) could be such an indicator if we send it and the server replies or does not reply with this extension. For this however we need to be somewhat sure that the extension really is a good indicator.

For the latter I tried to setup a docker container. Picking the right one turned out to seem not that easy as Nginx supports ssl_early_data as of 1.15.3. Official Debian containers aren't there yet. OTOH Nginx provides 1.15.8 but only OpenSSL 1.1.0 (nginx/docker-nginx#309 (comment)).

So what I was planning was just sending TLS extension 42=0x2A and inspect the return for the same extension (B).

More certain would be A but B is a low hanging fruit to grab and taste :-)

[drwetter]

The low hanging fruit seems to hang higher: To send the extension via sockets was very easy. That was very low hanging but worth a try. The server didn't indicate the extension back (checked with testssl.sh and wireshark).

Secondly, if I use OpenSSL 1.1.1 and attach session information so that the server somehow -- depending on the validity of the session information -- responds with an extension. The catch is in this case: also if I see the extension in the server reply or any rejection of session data with openssl -trace: It seems to be always hidden in the application data (wireshark) which would mean that we would have to decrypt application data. (This might be similar for TLS 1.3-only servers too)

Maybe I overlooked something which can be used as an oracle to tell whether the server side supports early_data but I doubt that this will be a clear indicator.

[sverrevh]

The Dutch NCSC added checking for 0-RTT to their TLS1.3 recommendations. Is this check still considered to be added to testssl.sh?
https://www.ncsc.nl/binaries/ncsc/documenten/publicaties/2025/juni/01/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2025-05/Publication_TLS-Security+guidelines-2025-05_ENG.pdf

[drwetter]

Yes, it is planned but somehow fell off the table...

Shouldn't be too difficult:

prompt$ openssl s_client -tls1_3 -sess_out sess.pem -brief google.com:443 >\!ed.txt <<< Q 2>/dev/null
prompt$ openssl s_client -tls1_3 -sess_in sess.pem -early_data ed.txt google.com:443 </dev/null | grep -i 'Early Data'
Connecting to 142.251.209.131
Early data was accepted
DONE
    Max Early Data: 14336
    Max Early Data: 14336
prompt$ 

Still no idea how reliable the detection is.