Hi Neil,
Thanks for your interest in JEP 527.
On 8/20/26 12:57 PM, Neil Wilson wrote:
Hello,
I’m currently working on updating an LDAP directory server with
support for quantum-resistant encryption. This includes support for
TLS-secured connections, and I see that via JEP 527, JDK 27 includes
support for some quantum-resistant hybrid key exchange algorithms. And
because X25519MLKEM768 is being set as the highest-priority curve
group, this is a feature that should basically come for free when
communicating with peers that support that curve group.
However, I can’t seem to find any method that can be used to determine
which curve group was actually selected for a connection during the
TLS negotiation process. This information doesn’t seem to be available
in SSLSession, or anywhere else that I can find. When I run a test
client with -Djavax.net.debug=all, I can see the “named_group” field
in the debug output for the ServerHello message, but there just
doesn’t seem to be any way to gain programmatic access to that.
I think that it’s essential to be able to obtain the negotiated curve
group programmatically to be able to verify whether a given TLS
session is protected with quantum-resistant encryption. I’d like to be
able to log this along with other details like the negotiated TLS
protocol and cipher suite, and potentially to even be able to use this
information to make access control decisions, like only returning
certain sensitive information to clients if I can confirm if the
communication has been secured with quantum-resistant encryption.
Would it be possible to get a method like SSLSession.getNamedGroup()
to be able to determine which named group was selected in the course
of negotiating the session?
Yes, we are working on it. You can track progress in the enhancement :
https://bugs.openjdk.org/browse/JDK-8388519
You can also see the negotiated named group when using JFR. See
https://bugs.openjdk.org/browse/JDK-8386594. This is only in JDK 28
right now, but should eventually be backported to prior releases that
are planned to support TLS 1.3 Hybrid Key Exchange.
--Sean
Thanks!
Neil Wilson
