Add support for exporting TLS Keying Material

[sanjerai]

Jetty version(s)
Jetty 11.0.20+

Enhancement Description
RFC5705 defines and RFC8446 updates keying material exporters for TLS:

• https://www.rfc-editor.org/rfc/rfc5705.html
• https://www.rfc-editor.org/rfc/rfc8446#section-7.5

Many other TLS implementations already support it:

• https://pkg.go.dev/crypto/tls#ConnectionState.ExportKeyingMaterial
• https://docs.openssl.org/1.1.1/man3/SSL_export_keying_material
• https://downloads.bouncycastle.org/java/docs/bctls-jdk18on-javadoc/org/bouncycastle/tls/TlsContext.html#exportKeyingMaterial-java.lang.String-byte:A-int-

5G mobile specs mandate the use of TLS session at app level for JWE:

• https://www.tech-invite.com/3m33/toc/tinv-3gpp-33-501_zk.html#e-13-2-4-4-1

We have a Spring + jetty client code base communicating over TLS1.3 and HTTP2. We have a use case to export TLS keying material or the master secret. We need this information to further derive keys for JWE tokens ciphering.

[sbordet]

@sanjerai OpenJDK does not provide any API to access the TLS exporters, so there is nothing that Jetty can do.

You may want to open an OpenJDK issue, and I would gladly support this, since it is required also for QUIC+TLS, which is currently not possible to implement using OpenJDK APIs.

[sanjerai]

@sbordet enhancement has been raised for open jdk https://bugs.openjdk.org/browse/JDK-8341346.
Once complete we can track jetty changes with this current issue.

[sbordet]

@sanjerai thanks for the link to the OpenJDK bug.

Just to set expectations, realize that that issue will be fixed in Java 25 or later, and it will take a while (years) before adoption widespreads, so do not hold your breath 😄

[sanjerai]

@sbordet netty seems to have such functionality added in netty project https://netty.io/4.1/api/io/netty/handler/ssl/SslMasterKeyHandler.html
do you think we can have something similar for jetty as well?

[sbordet]

I looked at the Netty implementation and it uses deep reflection on JDK classes, which is forbidden in modern JDK unless opening up the java.base module.

I'm not really keen to do that.

Seems strange that you have a requirement to export the key material or the master secret of a TLS connection, seems like this would open up for vulnerabilities.

Can you detail why you need this feature?
Seems to me you don't need the key material, but just access to the HKDF-Expand function (which is necessary for QUIC too), but while the JDK has an implementation, it is not public.

[sanjerai]

@sbordet we need this to derive key at client and server side as per 5G mobile specs. we have to directly use the master key and a known salt to generate a single HMAC output, from which we will extracts the required length. this is to make sure as per 5G specs both networks client server use same derived key.

[sbordet]

@sanjerai there might be hope, see https://openjdk.org/jeps/478.

I'm hoping that along with the KDF APIs there will be API additions to extract the master key from the SSLSession without using deep reflection.

If that is true, then what you need would be doable in Java 24.

If it is doable, then we can have a Jetty class that uses those new APIs via non-deep reflection, and expose this feature.

If you're willing to do it, can you check JEP 478 and see if this new API would be enough for you to implement your use case?