Quality Outreach Heads-up - JDK 28: Named Group Information Captured in the TLSHandshake JFR Event

The OpenJDK Quality Group is promoting the testing of FOSS projects with OpenJDK builds as a way to improve the overall quality of the release. This heads-up is part of a Quality Outreach update sent to the projects involved. To learn more about the program, and how-to join, please check here.

Observe Named Group Information in jdk.TLSHandshake

JDK Flight Recorder provides a low-overhead way to capture certain security-related information at runtime, including the jdk.TLSHandshake JFR event, which captures details of successful TLS handshakes. This event is disabled by default in the default.jfc and profile.jfc configurations shipped with the JDK, so you must enable it explicitly in a JFR configuration file (*jfc), via jfr configure, or when launching your application:

$ jfr configure jdk.TLSHandshake#enabled=true

$ java -XX:StartFlightRecording:settings=default,duration=60s,+jdk.TLSHandshake#enabled=true

Starting with JDK 28, the jdk.TLSHandshake JFR event records the named group information negotiated between the client and server during key exchange. You can inspect the named group details captured by running jfr print command:

$ jfr print --events "jdk.TLSHandshake" recording.jfr

jdk.TLSHandshake {
  startTime = 16:40:21.915 (2026-08-12)
  peerHost = N/A
  peerPort = -1
  protocolVersion = "TLSv1.3"
  cipherSuite = "TLS_AES_128_GCM_SHA256"
  namedGroup = "X25519MLKEM768"
  certificateId = 5568006
  eventThread = "https-jsse-nio-8443-exec-7" (javaThreadId = 70)
  stackTrace = [
    sun.security.ssl.Finished$T13FinishedConsumer.onConsumeFinished(ServerHandshakeContext, ByteBuffer) line: 1167
    sun.security.ssl.Finished$T13FinishedConsumer.consume(ConnectionContext, ByteBuffer) line: 905
    sun.security.ssl.SSLHandshake.consume(ConnectionContext, ByteBuffer) line: 436
    sun.security.ssl.HandshakeContext.dispatch(byte, ByteBuffer) line: 485
    sun.security.ssl.SSLEngineImpl$DelegatedTask.run() line: 1207
    ...
  ]
}

The output above confirms that the X25519MLKEM768 key-exchange group was negotiated during the TLS handshake, identifying how the client and server established the shared secret that protects the connection.

Call to Action

We encourage you to download the JDK 28 early-access builds, try this feature, and share your feedback through the security-dev OpenJDK mailing list (registration required).