Okay, so like everyone else, I'm going to try and raise my voice and hopefully all of
you can hear me.
I'm Sean Coffee.
I work with the Java platform group team in the Dublin Oracle office.
And today I'd like to talk about the JDK flight recorder events and how they can be used
to monitor security operations on your Java applications.
For those that might be familiar with the JDK flight recorder, I'm just going to give a quick overview
of it.
It's better known as the JFR.
It's a low-cost monitoring and profiling framework that ships with the JDK embedded directly
into the JVM ready for production use and would typically have a 1% overhead.
There are many different events from all over the JVM stack and the APIs that are gathered
into a JFR recording and they're building blocks of the data that this framework outputs.
And they would typically be captured to a JFR file.
There's a lot of options to stream this elsewhere, but for the purpose of this presentation,
I'm just going to concentrate on the JFR file that gets captured at the local file system level.
Traditionally, the JFR would be used to capture a low-level events, very low-level events
in the JVM, everything like memory application, memory retention, GC trading, maybe deadlocks
that you might have on your application.
They cannot be studied in great detail using JFR and have been very successful in doing that over the years.
In more recent times, I guess, there's been more and more events added to the JFR stack
that allow developers that use the security and call library APIs to monitor in more detail
of what events are being captured at their application level.
And I'm going to concentrate on some of them today in particular the security crypto events.
Before we go there, I just want to have a few notes on how JFR can be launched into your Java application.
It's quite a trivial task. There are a few different options.
I'm going to highlight some of the main ones here.
The most common way is probably via the command line. You insert an extra VM option,
minus xx, core on start flight recording.
And that will automatically have the JFR stack recording your application at a long time.
That command itself takes sub-options. One option I have here is,
Dumpon exit equals true, which basically signals to the JFR to write out all events
that have been captured to the file on VM exit.
Another way of capturing JFR is via J command or JCMD.
This is a utility that ships in the JDK.
As someone that works with support and enterprise teams,
this is a very powerful attraction of JFR being able to remotely dial into any JDK.
Via JCMD, via the PID identifier.
There's a diagnostic command called JFR.start that will basically start recording events
at any time during the lifetime of your Java application.
There's follow on events, then to actually dump that JFR data
and to stop the JFR recording via JCMD as well.
And of course, there's also the good old graphical tools
to fall back into these actions as well.
I have a mission control.
Better known as JMC is to a very capable of working with JFR by launching it
and reading JFR data.
It can do a whole lot of different diagnostic options on running JVM
starting the JFR is one of those.
Let's just look at high level at some of the core library
and security events that are in the JDK today.
I've just got to highlight some of them.
JDK that DCRization was introduced in JDK 17.
And also prizes here.
It records details about objects being DCRized in your application.
That can be useful to developers to know what sort of shapes
and the heuristics and load a DCRization process is putting
on your VM project.
The JDK that process start was brought in in 15.
And records details around use of the process builder
and processes being started there.
And again, that's useful to developers or
DevOps or engineers that need to know what sort of native
processes are being triggered by this API.
JDK that virtual tread start.
JDK that virtual tread end came in in 19.
It's part of the loom preview.
And they will capture details of, you know,
not suppose it again, every virtual tread start and stop
and the calling stacks to those.
JDK dot shutdown.
Since JDK 11 captures details around use of the system
not a exit API.
Light and be adventurous to everyone, but it's a good example of
that tricky moment where your JVM or your application
unexpectedly dies.
Some part of the application is called system not exit.
It can often be hard to track down that case.
We'll do a good job of doing that.
JDK dot the initial environment variable has been in the
start for a long time.
Thought it was worthy of highlighting here.
Environment variables have had to be here if you
change on the JVM that's running.
It's often a very useful event to capture the details.
All of the environment details about the shell or the
environment that the JVM is running in.
And finally, security crypto events have been
added since Java 12.
I'm going to go into more detail on those very shortly.
I will add that most of these events have been backported
to the various JDK update releases.
Before I talk about crypto events, let's just look at
the motivation for why we did this.
They're basically there to help you monitor security
configuration and the actions of the Java runtime on that end.
You might often want or what sort of cryptographic
standards and algorithms are running on your VM and RAD
secure.
Having the JFR layer and allowing one to remotely attach
to these JDKs and collect this data is a pretty attractive
capability.
And it also helps the Oracle run the JDK crypto roadmap program
where we try and keep the JDK secure out of the box.
And for people that might be familiar with our program,
basically security standards evolve over the years.
Some become weaker.
A good example might be TLSB-11.
Ten years ago, a lot of our internet and TLS traffic
was working with our protocol today.
It would be regarded as week deprecators.
And the crypto roadmap program would have been part of the
steps of ensuring the TLS-11 was disabled in the JDK by default.
The program itself publishes a roadmap of upcoming changes
that helps developers assess whether future changes might impact
their applications.
And of course, the binary nature of JFR files is very attractive
set up as well.
It helps engineers run efficient queries over large data
stacks.
Okay, let's go over the crypto events.
There was six in the stack today.
JDK, that security property modification.
JDK, that TLS handshake.
JDK, that X509 certificate.
JDK, X509 validation.
And two more recent ones.
They were all added in JDK 12.
Two more recent ones in Java 20 were JDK.
The security property and JDK that security provider service.
You will notice that most of these are disabled by default.
So it's up to the end user to enable them via the configuration file.
And again, many of these events have been back ported to the various
JDK update releases.
On the note of enabling JFR crypto events, it's actually
a trivial enough task again.
It's a configuration step.
The default file that the JFR will use is in the JDK itself.
It's in the JDK home lib JFR directory.
There is another file in the same directory called profile.jfc.
That's to rush up the number of events and the data
collectives in the running JVM for those moments where you might need to
home in a problem application.
So specifically the configuration file when you're
starting a launching JFR.
I've included an example here for the settings.
You know, command can be used to indicate
where the configuration file is located.
The same can be done in the graphical tools very easily.
The configuration file itself is of XML format.
And it's quite easy.
Again, you can do it to the graphical tools.
Or you can do it to file edits.
It's quite easy to flip any disabled event over to the two
status.
So let's go up to those events.
I just highlight the data points that each event captures
and why they may be useful.
For those not familiar with JFR, I'm using the CLI tool that
ships in the JDK.
It's, again, in the JDK home bin directory and it's capable of
passing JFR files and taking options to, you know,
delve into certain events of interest in that file.
The first one up here is security property modification.
That records details of all API calls to the security dots
that property API.
Given that the JVM, you know, security, you know,
behavior is impacted by security properties.
It's important to perhaps capture such details going on at the VM
level.
As part of the JFR event, one gets the stack trace on the event
time.
The extra events here on top of that are,
our event data, I should say, is the key in the value.
Very, very simple event in itself.
Let's move on to the next one.
JDK.TLS handshake.
This records details of every successful TLS handshake
made by the default JSSE provider.
Quite a powerful event perhaps for admins and audits
where one needs to know about every outgoing TLS connection
being made.
And indeed, the same is true for servers receiving requests.
They get to record the JFR event as well.
The interesting event fields in these,
in this event are perhaps the peer host, the peer host,
port, the protocol version in use, the Cypher Suite,
the certificate ID, which would be a reference to the server
search certificate.
And again, the calling stack trace which can help anyone
identify where those connections are coming from.
JDK.x509 certificates.
No surprises here.
Record details of every search that's generated at the JVM level.
The interesting fields here would be the serial number of the search,
the subjects of the search who issued that certificate,
the signature type on the search, the key link,
and I think the signature algorithm is also captured.
And the all important validity of the certificate.
So valid from, valid to, I think we've all seen services
over the years, major services that that which may have failed
because of a mismatch in dates or an expired certificate.
This may be a useful kind of data event to capture
to help all the servers know our DevOps know
if there's any upcoming search that need modification.
JDK.x509 validation.
This event requires details around the
successful search path operations.
So it's coupled closely with the x509 certificates event.
And for those familiar with TLS, there's a chain of
trust that has to be built for every successful connection.
Starting with the server certificate.
A chain of trust has to be built all the way back to the client,
which will have hopefully a root certificate,
a certificate from a root certificate authority
that matches the request coming in.
This is basically an event to capture those details.
It captures the certificates used,
and the position of products certificate was
in the successful TLS connection.
Position one being the server certificate
and the last position being the root CA.
You're all fine.
That is intermediate certificates in play here as well.
JDK.x509.
Initial security property.
This was added in Java 20.
And what it basically is,
it's a binary dump of all the security properties
that are in the Java security file at start-up.
Again, as someone that works in helping
the bulk situations, it's very useful to know
if an application has made modifications
in this this area,
being able to capture all those security details,
security property details,
and don't promote to a JFR file is quite useful.
So when someone can couple this event
with the earlier JDK security modification event,
you have a good picture of what an application is doing
at the security property level.
Final event,
possibly one of the more useful events I believe
is the JDK security provider service.
That is sitting at the JACJSA layer,
and it captures every event coming into every provider
in terms of crypto requests.
And the fields of interest here are the type of service being requested
to the algorithm on that service,
and the provider.
And again, the calling structure is quite a powerful bit
of data to have if you're perhaps debugging
a cryptographic issue,
or a CPU issue,
but cooperation that's gone wrong,
this can be useful data to indicate
what providers and what layers were replayed.
Let's take this one into a bit more detail.
I have a graphical format of this event.
This is a snapshot from the GMC.
Two that I spoke about earlier,
which I have a mission control.
As we can see here,
we have a view of the different types of service,
the different number of accounts that was made,
and the events,
timestamps and the event data in each one of those.
More interesting for this kind of event
is the fact that you can group this data,
there's a group by feature in GMC,
and that probably is of more interest for security developers,
where the typical request coming into the JCA provider framework
will be a request for a certain service,
but a certain algorithm name within that service.
So here,
we can see that the shot 256 messages I just are on high demand,
the X5 online certificate factory,
no surprises here,
which is a simple demo app that is making several different TLS connections,
and the list goes down.
Every single crypto operation made by your application is recorded by this event.
Given that each stack trace can be associated with each one of these events,
we're now in a position to know where every crypto call is actually coming from,
and again,
very useful for determining the source of crypto requests.
Let's try that one back to the crypto roadmap then.
So with the events that I've just spoken about,
I'm hoping people can see how they can use those events now to actually
gauge whether upcoming events in the crypto roadmap.
Impact the applications are not an impact,
even past changes.
I'm going to take a few examples here.
These are the most recent ones that run the roadmap,
as of a week or two ago.
Back in October 24,
we took the decision to disable the TLS ECD H.
It was already done in the JDK feature releases,
but it's been extended to update releases.
The second one here,
we began distrusting TLS server certificates issued by the interest authority.
All this information is publicized via the roadmap and good time frame.
The third one is disabling of TLS 1.0.
That was done earlier in 2024.
With those events that we just saw,
I'm hoping that people can now match the data items up with an actual event
that can be used to understand whether their applications will be impacted.
So the first one here,
we can use TLS handshake.
Since it records its life for sweet,
we can do a very simple aquarium match.
JDK.x509 certificates.
You can basically scan every certificate that's been generated
and query on the issue of field,
and pick out certificates that might be of impact in this loan item.
And the last day,
the disabling of TLS 1.0 again,
we've all acted at TLS handshake event.
We can very easily look at the protocol version
and find problem applications that might be still using TLS 1.0.
There are probably more trivial cases.
Let's look at a slightly more complex case.
If chosen this one,
which was made in October 22,
the JDK itself ships with the ability to create key stores.
By default, they use the pick as 12 formats.
Some of the internal algorithms inside the generation of a key store,
they're not well exposed.
They're hard to see in the blog blogs.
But the math algorithm used for creating key stores was upgraded
with this line item.
And for an end user,
that's hard to determine.
It's hard to determine whether the key stores that are used by the applications
would actually be impacted or would be a factor in this change.
So let's just delve into a bit more detail on this one.
We're going to use the security provider service to determine
whether applications are actually using weak key stores or not.
So here, I've turned on crypto,
the provider service event for this application.
We have a simple algorithm called McRecrest
with the algorithm of H McPB-Shout1.
By itself, that might look okay.
But if you can couple of that with the actual stack trace,
we're now in a more interesting position.
We know that using weak algorithm on a key store is not longer deemed appropriate.
And we now have evidence that this Java application is after loading from a weak key store.
So one can deduce that that's a weak crypto operation.
And action should be taken for applications that might have interest in this area.
The flip side, I have another key store I used by the same application here.
We see that the algorithm this time is H McPB-Shout256.
With a very similar stack trace, that's a lot of data.
We have a lot of data.
Shout256.
With a very similar stack trace, that's evidence of a key store.
It has been generated with stronger crypto from the get-go.
And that can be considered more safe.
On a final note, there is Oracle have the Java Management Service,
which is using these JFR events today.
They are able to absorb and manage dedicated deployments.
There's a crypto robot in part analysis as part of that product,
which is using the JFR events that I've just highlighted.
A couple of the kind of a rule book that will determine what's good crypto or what is bad crypto.
And it also has the ability to advise the end users what the best course of action would be in terms of correcting any sightings of weak crypto in their application.
And that's pretty much eight for today.
I'm just going to quickly show the Java mission control and where one can find these.
I'll start in your window.
That's going to be tricky.
Let me just do a change here.
Okay, so hopefully you can see GMC here.
So on a normal launch of a JFR recording,
you will get automated analysis at the very front pane.
One is able to delve down to the various events that are captured as part of a JFR recording.
If one is interested in the crypto events themselves,
they can go to the event browser.
There's a kind of a tree effect where each event is recorded under a certain component.
The crypto events themselves fall into under the Java development kit.
And security and here your one can literally just take a view of every event that's been generated at that level.
And you know, associated with a with a calling stack trace as well, which can be handy for identifying, identifying problem issues.
That's about it from me.
If you have any questions, I'm happy to take them now.
Or we can more than happy also.
We can discuss on security dash there.
Open, open, communicate at all.
Okay.
Is there a JFR recording on the page?
Remote detach?
Could be.
Well, this is only the start of some of the events at the higher level.
I think we are getting more and more conscious of adding events.
For these kind of remote operations.
Yep.
Sorry.
It was a vocal was asking was there a JFR event for remote detachability.
From the JFR side or the.
Yep.
Anything else?
No.
Sorry.
Do you trace scheduling the events for friends?
I guess that would be at the JFR level for JVM events itself.
There's.
Yeah.
I believe so on the JFR JVM level.
This is only snapshot of what the JFR can do at the.
The security API level.
But at the at the JVM level, there's a much more detail.
You've each tried on their state.
But definitely watch this check and out.
Okay.
Thank you.