BCJSSE: Add Java Flight Recorder TLS events

[marnix]

(This question is not specific to to BCFIPS / BC-FJA, and I imagine you would first want to add this in your 'regular' bctls-jdk18on.jar. But we would adopt this suggested feature once it landed in bctls-fips-2.0.x.jar.)

We are running our application JVMs with BCJSSE as a security provider, instead of the shipped SunJSSE. Now when switching to Java 17, we discovered that in JDK 12+, SunJSSE has been instrumented with some Java Flight Recorder (JFR) events (specifically: SecurityPropertyModificationEvent, TLSHandshakeEvent, X509CertificateEvent and X509ValidationEvent). See Jira issue ¹, release notes ², and code changes ³.

This is very interesting since we are trying to get a good visibility of the rate at which our code is doing TLS handshakes, because over time it is used everywhere and the cost of setting up a secure connection makes us want to keep an eye on them).

As we have replaced the SUN stack by the BC stack ("SunJSSE" provider → "BouncyCastleJsseProvider") these events do not show up in our flight recordings. The cause is that the adoption of these new events is in the SunJSSE code. Most related code (like the definition of the events) is in code that is shared among the JCA/JCE providers, but the pieces that mark the start and end of the JFR event (instantiate & commit) are inside the SunJSSE provider code. The place where this code entered the JDK shows what code is specifically in the SunJSSE side.

For example, for the 'TLSHandshakeEvent' the code that is specific to SunJSSE is in src/java.base/share/classes/sun/security/ssl/Finished.java in the method private static void recordEvent(SSLSessionImpl session) accompanied by a few local calls into this new method. Something similar goes for X509CertificateEvent and X509ValidationEvent.

Our question is: Can these events be adopted in BouncyCastleJsseProvider? As they would be very useful to keep an eye on TLS negotiations and to make improvements in this area (i.e. tune connection pooling). For us the most interesting of these events is the 'TLSHandshakeEvent', so a phased approach with a limited initial scope would be great already.

Thanks in advance for looking into this!

(References below.)

Footnotes

1. Bug ID: JDK-8148188 Enhance the security libraries to record events of interest ↩

2. JDK 12 Release Notes (going forward adoption for 17+ in BC would nowadays be a great choice in our opinion). ↩

3. jdk/jdk: f7309a1491d9 ↩

[peterdettman]

In principle we'd be happy to record JFR events. I suppose we would want only an optional dependency on the jdk.jfr module.

For convenience, the github openjdk commit: openjdk/jdk@73ad9c4#diff-6fcb6ccf38f77d1a943ad82829a7b70a3d28ace92e895897963a474222675ed4 .

Are you sure the event classes are "shared among the JCA/JCE providers"? Although the ones in jdk.jfr.events are public they are not exported from the module. I think they may only exist as "mirror events" for use from java.base.