TLS 1.3 compliance

[sbordet]

The TLS 1.3 implementation landed in JDK 11-ea+21.

We need to make sure that SslConnection works well with TLS 1.3.

In particular:

• After ClientHello and ServerHello, all other TLS handshake messages are now encrypted, so they appear as "Application Data" in wireshark. This may not be a problem in SslConnection, but needs to be verified
• Verify that the 0-RTT feature of TLS 1.3 works with SslConnection (i.e. verify we don't assume that we cannot send application data until we read TLS handshake bytes from the server)
• Verify that if the server rejects 0-RTT, we handle the case correctly
• Verify that the new session resumption mechanism in TLS 1.3 works, and that SslHandshakeListener are properly notified

[sbordet]

0-RTT seems to be very delicate, as in only usable for idempotent requests such as GET: https://www.youtube.com/watch?v=grRi-aFrbSE

However, too big of a win to ignore it, but requires APIs to tell the TLS stack that the application data is idempotent - doubt that these APIs are present in JDK, not sure about OpenSSL.

[sbordet]

In TLS 1.3 renegotiation is not possible, so we need to make sure that if we enter a code path that handles renegotiation it does not get executed for TLS 1.3.

[sbordet]

@gregw I have pushed to branch jetty-9.4.x-2711-tls_13_compliance my work in progress, see commit message for d26e196.

There is one failing test in jetty-client, NeedWantClientAuthTest.
Reason for failure is that in TLS 1.3 client authentication is done post-handshake, while in TLS 1.2 is done during the handshake. The test fails because it expects the handshake to fail, but it does not fail because the client authentication (which fails) is done after the handshake.

That almost all of jetty-client (and all of jetty-server) passes is a good step forward, but there is more to do.

Meanwhile I filed another couple of bugs to the JDK, but I guess it's unlikely they will be fixed for JDK 11.

[gregw]

@sbordet for completeness can you add links to the jdk11 bugs you have opened here?

[sbordet]

Bugs opened since JDK 11+21 came out, reported by me and others:

https://bugs.openjdk.java.net/browse/JDK-8207004

https://bugs.openjdk.java.net/browse/JDK-8207009

https://bugs.openjdk.java.net/browse/JDK-8207029

https://bugs.openjdk.java.net/browse/JDK-8207177

https://bugs.openjdk.java.net/browse/JDK-8207317

https://bugs.openjdk.java.net/browse/JDK-8209840

https://bugs.openjdk.java.net/browse/JDK-8209893

[mpfau]

Have all issues around TLS 1.3 been resolved / can this issue be closed?

I am asking because it has been announced as fixed for the latest release (9.4.12, see VERSION.txt).

[sbordet]

Jetty 9.4.12 supports TLS 1.3 with JDK 11.
This is live on https://webtide.com.

$ bin/openssl version
OpenSSL 1.1.1-pre9 (beta) 21 Aug 2018

$ bin/openssl s_client -tls1_3 -CAfile /etc/ssl/certs/ca-certificates.crt webtide.com:443
...
SSL handshake has read 3474 bytes and written 640 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_128_GCM_SHA256
    Session-ID: ...
    Session-ID-ctx: 
    Resumption PSK: ...
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket: ...
    Start Time: 1535810340
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---

[sbordet]

Note that ssllabs does not seem to recognize TLS 1.3, see ssllabs/ssllabs-scan#651.

[ijuma]

Thanks for testing this before the Java 11 release, seems like TLS 1.3 will actually work due to this. :)

[sbordet]

@ijuma you're welcome 😃
Let's spread the word about this!