WEBVTT

00:00.000 --> 00:11.000
Okay, so like everyone else, I'm going to try and raise my voice and hopefully all of

00:11.000 --> 00:12.000
you can hear me.

00:12.000 --> 00:13.000
I'm Sean Coffee.

00:13.000 --> 00:18.000
I work with the Java platform group team in the Dublin Oracle office.

00:18.000 --> 00:23.640
And today I'd like to talk about the JDK flight recorder events and how they can be used

00:23.640 --> 00:29.000
to monitor security operations on your Java applications.

00:29.000 --> 00:34.000
For those that might be familiar with the JDK flight recorder, I'm just going to give a quick overview

00:34.000 --> 00:35.000
of it.

00:35.000 --> 00:37.000
It's better known as the JFR.

00:37.000 --> 00:43.500
It's a low-cost monitoring and profiling framework that ships with the JDK embedded directly

00:43.500 --> 00:51.500
into the JVM ready for production use and would typically have a 1% overhead.

00:51.500 --> 00:56.200
There are many different events from all over the JVM stack and the APIs that are gathered

00:56.200 --> 01:03.200
into a JFR recording and they're building blocks of the data that this framework outputs.

01:03.200 --> 01:06.200
And they would typically be captured to a JFR file.

01:06.200 --> 01:11.200
There's a lot of options to stream this elsewhere, but for the purpose of this presentation,

01:11.200 --> 01:16.200
I'm just going to concentrate on the JFR file that gets captured at the local file system level.

01:16.200 --> 01:23.200
Traditionally, the JFR would be used to capture a low-level events, very low-level events

01:23.200 --> 01:32.200
in the JVM, everything like memory application, memory retention, GC trading, maybe deadlocks

01:32.200 --> 01:35.200
that you might have on your application.

01:35.200 --> 01:42.200
They cannot be studied in great detail using JFR and have been very successful in doing that over the years.

01:42.200 --> 01:47.200
In more recent times, I guess, there's been more and more events added to the JFR stack

01:47.200 --> 01:53.200
that allow developers that use the security and call library APIs to monitor in more detail

01:53.200 --> 01:58.200
of what events are being captured at their application level.

01:58.200 --> 02:04.200
And I'm going to concentrate on some of them today in particular the security crypto events.

02:04.200 --> 02:10.200
Before we go there, I just want to have a few notes on how JFR can be launched into your Java application.

02:10.200 --> 02:13.200
It's quite a trivial task. There are a few different options.

02:13.200 --> 02:17.200
I'm going to highlight some of the main ones here.

02:17.200 --> 02:23.200
The most common way is probably via the command line. You insert an extra VM option,

02:23.200 --> 02:26.200
minus xx, core on start flight recording.

02:26.200 --> 02:33.200
And that will automatically have the JFR stack recording your application at a long time.

02:33.200 --> 02:37.200
That command itself takes sub-options. One option I have here is,

02:37.200 --> 02:43.200
Dumpon exit equals true, which basically signals to the JFR to write out all events

02:43.200 --> 02:47.200
that have been captured to the file on VM exit.

02:47.200 --> 02:52.200
Another way of capturing JFR is via J command or JCMD.

02:52.200 --> 02:55.200
This is a utility that ships in the JDK.

02:55.200 --> 02:59.200
As someone that works with support and enterprise teams,

02:59.200 --> 03:05.200
this is a very powerful attraction of JFR being able to remotely dial into any JDK.

03:05.200 --> 03:09.200
Via JCMD, via the PID identifier.

03:09.200 --> 03:16.200
There's a diagnostic command called JFR.start that will basically start recording events

03:16.200 --> 03:19.200
at any time during the lifetime of your Java application.

03:19.200 --> 03:22.200
There's follow on events, then to actually dump that JFR data

03:22.200 --> 03:26.200
and to stop the JFR recording via JCMD as well.

03:26.200 --> 03:30.200
And of course, there's also the good old graphical tools

03:30.200 --> 03:33.200
to fall back into these actions as well.

03:33.200 --> 03:35.200
I have a mission control.

03:35.200 --> 03:41.200
Better known as JMC is to a very capable of working with JFR by launching it

03:41.200 --> 03:43.200
and reading JFR data.

03:43.200 --> 03:47.200
It can do a whole lot of different diagnostic options on running JVM

03:47.200 --> 03:51.200
starting the JFR is one of those.

03:51.200 --> 03:55.200
Let's just look at high level at some of the core library

03:55.200 --> 03:58.200
and security events that are in the JDK today.

03:58.200 --> 04:01.200
I've just got to highlight some of them.

04:01.200 --> 04:05.200
JDK that DCRization was introduced in JDK 17.

04:05.200 --> 04:07.200
And also prizes here.

04:07.200 --> 04:11.200
It records details about objects being DCRized in your application.

04:11.200 --> 04:14.200
That can be useful to developers to know what sort of shapes

04:14.200 --> 04:20.200
and the heuristics and load a DCRization process is putting

04:20.200 --> 04:23.200
on your VM project.

04:23.200 --> 04:27.200
The JDK that process start was brought in in 15.

04:27.200 --> 04:31.200
And records details around use of the process builder

04:31.200 --> 04:33.200
and processes being started there.

04:33.200 --> 04:36.200
And again, that's useful to developers or

04:36.200 --> 04:39.200
DevOps or engineers that need to know what sort of native

04:39.200 --> 04:42.200
processes are being triggered by this API.

04:42.200 --> 04:45.200
JDK that virtual tread start.

04:45.200 --> 04:48.200
JDK that virtual tread end came in in 19.

04:48.200 --> 04:50.200
It's part of the loom preview.

04:50.200 --> 04:53.200
And they will capture details of, you know,

04:53.200 --> 04:57.200
not suppose it again, every virtual tread start and stop

04:57.200 --> 05:00.200
and the calling stacks to those.

05:00.200 --> 05:02.200
JDK dot shutdown.

05:02.200 --> 05:06.200
Since JDK 11 captures details around use of the system

05:06.200 --> 05:08.200
not a exit API.

05:08.200 --> 05:11.200
Light and be adventurous to everyone, but it's a good example of

05:11.200 --> 05:14.200
that tricky moment where your JVM or your application

05:14.200 --> 05:16.200
unexpectedly dies.

05:16.200 --> 05:19.200
Some part of the application is called system not exit.

05:19.200 --> 05:22.200
It can often be hard to track down that case.

05:22.200 --> 05:24.200
We'll do a good job of doing that.

05:24.200 --> 05:27.200
JDK dot the initial environment variable has been in the

05:27.200 --> 05:29.200
start for a long time.

05:29.200 --> 05:31.200
Thought it was worthy of highlighting here.

05:31.200 --> 05:35.200
Environment variables have had to be here if you

05:35.200 --> 05:37.200
change on the JVM that's running.

05:37.200 --> 05:42.200
It's often a very useful event to capture the details.

05:42.200 --> 05:45.200
All of the environment details about the shell or the

05:45.200 --> 05:47.200
environment that the JVM is running in.

05:47.200 --> 05:50.200
And finally, security crypto events have been

05:50.200 --> 05:51.200
added since Java 12.

05:51.200 --> 05:54.200
I'm going to go into more detail on those very shortly.

05:54.200 --> 05:57.200
I will add that most of these events have been backported

05:57.200 --> 06:00.200
to the various JDK update releases.

06:00.200 --> 06:04.200
Before I talk about crypto events, let's just look at

06:04.200 --> 06:07.200
the motivation for why we did this.

06:07.200 --> 06:11.200
They're basically there to help you monitor security

06:11.200 --> 06:14.200
configuration and the actions of the Java runtime on that end.

06:14.200 --> 06:17.200
You might often want or what sort of cryptographic

06:17.200 --> 06:21.200
standards and algorithms are running on your VM and RAD

06:21.200 --> 06:23.200
secure.

06:23.200 --> 06:27.200
Having the JFR layer and allowing one to remotely attach

06:27.200 --> 06:31.200
to these JDKs and collect this data is a pretty attractive

06:31.200 --> 06:34.200
capability.

06:34.200 --> 06:39.200
And it also helps the Oracle run the JDK crypto roadmap program

06:39.200 --> 06:44.200
where we try and keep the JDK secure out of the box.

06:44.200 --> 06:47.200
And for people that might be familiar with our program,

06:47.200 --> 06:50.200
basically security standards evolve over the years.

06:50.200 --> 06:52.200
Some become weaker.

06:52.200 --> 06:56.200
A good example might be TLSB-11.

06:56.200 --> 06:59.200
Ten years ago, a lot of our internet and TLS traffic

06:59.200 --> 07:01.200
was working with our protocol today.

07:01.200 --> 07:04.200
It would be regarded as week deprecators.

07:04.200 --> 07:09.200
And the crypto roadmap program would have been part of the

07:09.200 --> 07:15.200
steps of ensuring the TLS-11 was disabled in the JDK by default.

07:15.200 --> 07:19.200
The program itself publishes a roadmap of upcoming changes

07:19.200 --> 07:23.200
that helps developers assess whether future changes might impact

07:23.200 --> 07:25.200
their applications.

07:25.200 --> 07:29.200
And of course, the binary nature of JFR files is very attractive

07:29.200 --> 07:32.200
set up as well.

07:32.200 --> 07:36.200
It helps engineers run efficient queries over large data

07:37.200 --> 07:39.200
stacks.

07:39.200 --> 07:42.200
Okay, let's go over the crypto events.

07:42.200 --> 07:45.200
There was six in the stack today.

07:45.200 --> 07:48.200
JDK, that security property modification.

07:48.200 --> 07:51.200
JDK, that TLS handshake.

07:51.200 --> 07:53.200
JDK, that X509 certificate.

07:53.200 --> 07:55.200
JDK, X509 validation.

07:55.200 --> 07:57.200
And two more recent ones.

07:57.200 --> 07:59.200
They were all added in JDK 12.

07:59.200 --> 08:02.200
Two more recent ones in Java 20 were JDK.

08:02.200 --> 08:06.200
The security property and JDK that security provider service.

08:06.200 --> 08:10.200
You will notice that most of these are disabled by default.

08:10.200 --> 08:15.200
So it's up to the end user to enable them via the configuration file.

08:15.200 --> 08:19.200
And again, many of these events have been back ported to the various

08:19.200 --> 08:22.200
JDK update releases.

08:22.200 --> 08:26.200
On the note of enabling JFR crypto events, it's actually

08:26.200 --> 08:28.200
a trivial enough task again.

08:28.200 --> 08:30.200
It's a configuration step.

08:30.200 --> 08:35.200
The default file that the JFR will use is in the JDK itself.

08:35.200 --> 08:39.200
It's in the JDK home lib JFR directory.

08:39.200 --> 08:43.200
There is another file in the same directory called profile.jfc.

08:43.200 --> 08:47.200
That's to rush up the number of events and the data

08:47.200 --> 08:51.200
collectives in the running JVM for those moments where you might need to

08:51.200 --> 08:54.200
home in a problem application.

08:54.200 --> 08:58.200
So specifically the configuration file when you're

08:58.200 --> 09:00.200
starting a launching JFR.

09:00.200 --> 09:04.200
I've included an example here for the settings.

09:04.200 --> 09:07.200
You know, command can be used to indicate

09:07.200 --> 09:10.200
where the configuration file is located.

09:10.200 --> 09:14.200
The same can be done in the graphical tools very easily.

09:14.200 --> 09:18.200
The configuration file itself is of XML format.

09:18.200 --> 09:20.200
And it's quite easy.

09:20.200 --> 09:22.200
Again, you can do it to the graphical tools.

09:22.200 --> 09:25.200
Or you can do it to file edits.

09:25.200 --> 09:31.200
It's quite easy to flip any disabled event over to the two

09:31.200 --> 09:33.200
status.

09:33.200 --> 09:35.200
So let's go up to those events.

09:35.200 --> 09:39.200
I just highlight the data points that each event captures

09:39.200 --> 09:41.200
and why they may be useful.

09:41.200 --> 09:46.200
For those not familiar with JFR, I'm using the CLI tool that

09:46.200 --> 09:48.200
ships in the JDK.

09:48.200 --> 09:52.200
It's, again, in the JDK home bin directory and it's capable of

09:52.200 --> 09:56.200
passing JFR files and taking options to, you know,

09:56.200 --> 10:01.200
delve into certain events of interest in that file.

10:01.200 --> 10:06.200
The first one up here is security property modification.

10:06.200 --> 10:10.200
That records details of all API calls to the security dots

10:10.200 --> 10:13.200
that property API.

10:13.200 --> 10:18.200
Given that the JVM, you know, security, you know,

10:18.200 --> 10:21.200
behavior is impacted by security properties.

10:21.200 --> 10:25.200
It's important to perhaps capture such details going on at the VM

10:25.200 --> 10:26.200
level.

10:26.200 --> 10:30.200
As part of the JFR event, one gets the stack trace on the event

10:30.200 --> 10:31.200
time.

10:31.200 --> 10:34.200
The extra events here on top of that are,

10:34.200 --> 10:37.200
our event data, I should say, is the key in the value.

10:37.200 --> 10:40.200
Very, very simple event in itself.

10:40.200 --> 10:42.200
Let's move on to the next one.

10:42.200 --> 10:44.200
JDK.TLS handshake.

10:44.200 --> 10:48.200
This records details of every successful TLS handshake

10:48.200 --> 10:51.200
made by the default JSSE provider.

10:51.200 --> 10:55.200
Quite a powerful event perhaps for admins and audits

10:55.200 --> 10:58.200
where one needs to know about every outgoing TLS connection

10:58.200 --> 10:59.200
being made.

10:59.200 --> 11:03.200
And indeed, the same is true for servers receiving requests.

11:03.200 --> 11:06.200
They get to record the JFR event as well.

11:06.200 --> 11:10.200
The interesting event fields in these,

11:10.200 --> 11:15.200
in this event are perhaps the peer host, the peer host,

11:15.200 --> 11:19.200
port, the protocol version in use, the Cypher Suite,

11:19.200 --> 11:23.200
the certificate ID, which would be a reference to the server

11:23.200 --> 11:25.200
search certificate.

11:25.200 --> 11:28.200
And again, the calling stack trace which can help anyone

11:28.200 --> 11:32.200
identify where those connections are coming from.

11:32.200 --> 11:36.200
JDK.x509 certificates.

11:36.200 --> 11:37.200
No surprises here.

11:37.200 --> 11:43.200
Record details of every search that's generated at the JVM level.

11:43.200 --> 11:49.200
The interesting fields here would be the serial number of the search,

11:49.200 --> 11:53.200
the subjects of the search who issued that certificate,

11:53.200 --> 11:56.200
the signature type on the search, the key link,

11:56.200 --> 12:00.200
and I think the signature algorithm is also captured.

12:00.200 --> 12:03.200
And the all important validity of the certificate.

12:03.200 --> 12:07.200
So valid from, valid to, I think we've all seen services

12:07.200 --> 12:10.200
over the years, major services that that which may have failed

12:10.200 --> 12:14.200
because of a mismatch in dates or an expired certificate.

12:14.200 --> 12:18.200
This may be a useful kind of data event to capture

12:18.200 --> 12:21.200
to help all the servers know our DevOps know

12:21.200 --> 12:25.200
if there's any upcoming search that need modification.

12:26.200 --> 12:29.200
JDK.x509 validation.

12:29.200 --> 12:33.200
This event requires details around the

12:33.200 --> 12:35.200
successful search path operations.

12:35.200 --> 12:40.200
So it's coupled closely with the x509 certificates event.

12:40.200 --> 12:43.200
And for those familiar with TLS, there's a chain of

12:43.200 --> 12:46.200
trust that has to be built for every successful connection.

12:46.200 --> 12:48.200
Starting with the server certificate.

12:48.200 --> 12:51.200
A chain of trust has to be built all the way back to the client,

12:52.200 --> 12:55.200
which will have hopefully a root certificate,

12:55.200 --> 12:59.200
a certificate from a root certificate authority

12:59.200 --> 13:03.200
that matches the request coming in.

13:03.200 --> 13:06.200
This is basically an event to capture those details.

13:06.200 --> 13:09.200
It captures the certificates used,

13:09.200 --> 13:12.200
and the position of products certificate was

13:12.200 --> 13:15.200
in the successful TLS connection.

13:15.200 --> 13:18.200
Position one being the server certificate

13:19.200 --> 13:21.200
and the last position being the root CA.

13:21.200 --> 13:22.200
You're all fine.

13:22.200 --> 13:26.200
That is intermediate certificates in play here as well.

13:26.200 --> 13:28.200
JDK.x509.

13:28.200 --> 13:29.200
Initial security property.

13:29.200 --> 13:32.200
This was added in Java 20.

13:32.200 --> 13:35.200
And what it basically is,

13:35.200 --> 13:38.200
it's a binary dump of all the security properties

13:38.200 --> 13:41.200
that are in the Java security file at start-up.

13:41.200 --> 13:44.200
Again, as someone that works in helping

13:45.200 --> 13:47.200
the bulk situations, it's very useful to know

13:47.200 --> 13:49.200
if an application has made modifications

13:49.200 --> 13:51.200
in this this area,

13:51.200 --> 13:55.200
being able to capture all those security details,

13:55.200 --> 13:57.200
security property details,

13:57.200 --> 14:00.200
and don't promote to a JFR file is quite useful.

14:00.200 --> 14:03.200
So when someone can couple this event

14:03.200 --> 14:07.200
with the earlier JDK security modification event,

14:07.200 --> 14:10.200
you have a good picture of what an application is doing

14:10.200 --> 14:13.200
at the security property level.

14:14.200 --> 14:17.200
Final event,

14:17.200 --> 14:20.200
possibly one of the more useful events I believe

14:20.200 --> 14:23.200
is the JDK security provider service.

14:23.200 --> 14:27.200
That is sitting at the JACJSA layer,

14:27.200 --> 14:31.200
and it captures every event coming into every provider

14:31.200 --> 14:34.200
in terms of crypto requests.

14:34.200 --> 14:40.200
And the fields of interest here are the type of service being requested

14:41.200 --> 14:43.200
to the algorithm on that service,

14:43.200 --> 14:45.200
and the provider.

14:45.200 --> 14:48.200
And again, the calling structure is quite a powerful bit

14:48.200 --> 14:51.200
of data to have if you're perhaps debugging

14:51.200 --> 14:54.200
a cryptographic issue,

14:54.200 --> 14:57.200
or a CPU issue,

14:57.200 --> 15:00.200
but cooperation that's gone wrong,

15:00.200 --> 15:03.200
this can be useful data to indicate

15:03.200 --> 15:06.200
what providers and what layers were replayed.

15:06.200 --> 15:08.200
Let's take this one into a bit more detail.

15:08.200 --> 15:12.200
I have a graphical format of this event.

15:12.200 --> 15:15.200
This is a snapshot from the GMC.

15:15.200 --> 15:18.200
Two that I spoke about earlier,

15:18.200 --> 15:20.200
which I have a mission control.

15:20.200 --> 15:21.200
As we can see here,

15:21.200 --> 15:24.200
we have a view of the different types of service,

15:24.200 --> 15:26.200
the different number of accounts that was made,

15:26.200 --> 15:28.200
and the events,

15:28.200 --> 15:32.200
timestamps and the event data in each one of those.

15:32.200 --> 15:35.200
More interesting for this kind of event

15:35.200 --> 15:37.200
is the fact that you can group this data,

15:37.200 --> 15:39.200
there's a group by feature in GMC,

15:39.200 --> 15:43.200
and that probably is of more interest for security developers,

15:43.200 --> 15:49.200
where the typical request coming into the JCA provider framework

15:49.200 --> 15:53.200
will be a request for a certain service,

15:53.200 --> 15:55.200
but a certain algorithm name within that service.

15:55.200 --> 15:56.200
So here,

15:56.200 --> 16:02.200
we can see that the shot 256 messages I just are on high demand,

16:02.200 --> 16:04.200
the X5 online certificate factory,

16:04.200 --> 16:05.200
no surprises here,

16:05.200 --> 16:10.200
which is a simple demo app that is making several different TLS connections,

16:10.200 --> 16:12.200
and the list goes down.

16:12.200 --> 16:17.200
Every single crypto operation made by your application is recorded by this event.

16:17.200 --> 16:21.200
Given that each stack trace can be associated with each one of these events,

16:21.200 --> 16:26.200
we're now in a position to know where every crypto call is actually coming from,

16:26.200 --> 16:27.200
and again,

16:27.200 --> 16:32.200
very useful for determining the source of crypto requests.

16:33.200 --> 16:38.200
Let's try that one back to the crypto roadmap then.

16:38.200 --> 16:41.200
So with the events that I've just spoken about,

16:41.200 --> 16:46.200
I'm hoping people can see how they can use those events now to actually

16:46.200 --> 16:50.200
gauge whether upcoming events in the crypto roadmap.

16:50.200 --> 16:53.200
Impact the applications are not an impact,

16:53.200 --> 16:55.200
even past changes.

16:55.200 --> 16:57.200
I'm going to take a few examples here.

16:57.200 --> 16:59.200
These are the most recent ones that run the roadmap,

16:59.200 --> 17:01.200
as of a week or two ago.

17:01.200 --> 17:04.200
Back in October 24,

17:04.200 --> 17:08.200
we took the decision to disable the TLS ECD H.

17:08.200 --> 17:12.200
It was already done in the JDK feature releases,

17:12.200 --> 17:15.200
but it's been extended to update releases.

17:15.200 --> 17:17.200
The second one here,

17:17.200 --> 17:23.200
we began distrusting TLS server certificates issued by the interest authority.

17:23.200 --> 17:28.200
All this information is publicized via the roadmap and good time frame.

17:29.200 --> 17:32.200
The third one is disabling of TLS 1.0.

17:32.200 --> 17:35.200
That was done earlier in 2024.

17:35.200 --> 17:37.200
With those events that we just saw,

17:37.200 --> 17:42.200
I'm hoping that people can now match the data items up with an actual event

17:42.200 --> 17:46.200
that can be used to understand whether their applications will be impacted.

17:46.200 --> 17:47.200
So the first one here,

17:47.200 --> 17:49.200
we can use TLS handshake.

17:49.200 --> 17:51.200
Since it records its life for sweet,

17:51.200 --> 17:54.200
we can do a very simple aquarium match.

17:55.200 --> 17:59.200
JDK.x509 certificates.

17:59.200 --> 18:03.200
You can basically scan every certificate that's been generated

18:03.200 --> 18:05.200
and query on the issue of field,

18:05.200 --> 18:11.200
and pick out certificates that might be of impact in this loan item.

18:11.200 --> 18:13.200
And the last day,

18:13.200 --> 18:16.200
the disabling of TLS 1.0 again,

18:16.200 --> 18:19.200
we've all acted at TLS handshake event.

18:19.200 --> 18:21.200
We can very easily look at the protocol version

18:22.200 --> 18:28.200
and find problem applications that might be still using TLS 1.0.

18:28.200 --> 18:30.200
There are probably more trivial cases.

18:30.200 --> 18:33.200
Let's look at a slightly more complex case.

18:33.200 --> 18:34.200
If chosen this one,

18:34.200 --> 18:38.200
which was made in October 22,

18:38.200 --> 18:43.200
the JDK itself ships with the ability to create key stores.

18:43.200 --> 18:46.200
By default, they use the pick as 12 formats.

18:46.200 --> 18:50.200
Some of the internal algorithms inside the generation of a key store,

18:50.200 --> 18:52.200
they're not well exposed.

18:52.200 --> 18:54.200
They're hard to see in the blog blogs.

18:54.200 --> 18:58.200
But the math algorithm used for creating key stores was upgraded

18:58.200 --> 19:00.200
with this line item.

19:00.200 --> 19:03.200
And for an end user,

19:03.200 --> 19:05.200
that's hard to determine.

19:05.200 --> 19:10.200
It's hard to determine whether the key stores that are used by the applications

19:10.200 --> 19:17.200
would actually be impacted or would be a factor in this change.

19:17.200 --> 19:20.200
So let's just delve into a bit more detail on this one.

19:20.200 --> 19:23.200
We're going to use the security provider service to determine

19:23.200 --> 19:26.200
whether applications are actually using weak key stores or not.

19:26.200 --> 19:29.200
So here, I've turned on crypto,

19:29.200 --> 19:34.200
the provider service event for this application.

19:34.200 --> 19:38.200
We have a simple algorithm called McRecrest

19:38.200 --> 19:41.200
with the algorithm of H McPB-Shout1.

19:41.200 --> 19:43.200
By itself, that might look okay.

19:43.200 --> 19:47.200
But if you can couple of that with the actual stack trace,

19:47.200 --> 19:49.200
we're now in a more interesting position.

19:49.200 --> 19:54.200
We know that using weak algorithm on a key store is not longer deemed appropriate.

19:54.200 --> 20:00.200
And we now have evidence that this Java application is after loading from a weak key store.

20:00.200 --> 20:04.200
So one can deduce that that's a weak crypto operation.

20:04.200 --> 20:09.200
And action should be taken for applications that might have interest in this area.

20:09.200 --> 20:15.200
The flip side, I have another key store I used by the same application here.

20:15.200 --> 20:20.200
We see that the algorithm this time is H McPB-Shout256.

20:20.200 --> 20:25.200
With a very similar stack trace, that's a lot of data.

20:25.200 --> 20:28.200
We have a lot of data.

20:28.200 --> 20:31.200
Shout256.

20:31.200 --> 20:36.200
With a very similar stack trace, that's evidence of a key store.

20:36.200 --> 20:40.200
It has been generated with stronger crypto from the get-go.

20:40.200 --> 20:44.200
And that can be considered more safe.

20:44.200 --> 20:49.200
On a final note, there is Oracle have the Java Management Service,

20:49.200 --> 20:52.200
which is using these JFR events today.

20:52.200 --> 20:56.200
They are able to absorb and manage dedicated deployments.

20:56.200 --> 21:00.200
There's a crypto robot in part analysis as part of that product,

21:00.200 --> 21:03.200
which is using the JFR events that I've just highlighted.

21:03.200 --> 21:08.200
A couple of the kind of a rule book that will determine what's good crypto or what is bad crypto.

21:08.200 --> 21:21.200
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.

21:21.200 --> 21:25.200
And that's pretty much eight for today.

21:25.200 --> 21:35.200
I'm just going to quickly show the Java mission control and where one can find these.

21:35.200 --> 21:39.200
I'll start in your window.

21:39.200 --> 21:42.200
That's going to be tricky.

21:42.200 --> 21:45.200
Let me just do a change here.

21:52.200 --> 21:56.200
Okay, so hopefully you can see GMC here.

21:56.200 --> 22:00.200
So on a normal launch of a JFR recording,

22:00.200 --> 22:03.200
you will get automated analysis at the very front pane.

22:03.200 --> 22:08.200
One is able to delve down to the various events that are captured as part of a JFR recording.

22:08.200 --> 22:12.200
If one is interested in the crypto events themselves,

22:12.200 --> 22:14.200
they can go to the event browser.

22:14.200 --> 22:20.200
There's a kind of a tree effect where each event is recorded under a certain component.

22:20.200 --> 22:24.200
The crypto events themselves fall into under the Java development kit.

22:24.200 --> 22:34.200
And security and here your one can literally just take a view of every event that's been generated at that level.

22:34.200 --> 22:43.200
And you know, associated with a with a calling stack trace as well, which can be handy for identifying, identifying problem issues.

22:43.200 --> 22:46.200
That's about it from me.

22:46.200 --> 22:48.200
If you have any questions, I'm happy to take them now.

22:48.200 --> 22:50.200
Or we can more than happy also.

22:50.200 --> 22:52.200
We can discuss on security dash there.

22:52.200 --> 22:54.200
Open, open, communicate at all.

22:54.200 --> 22:55.200
Okay.

22:55.200 --> 22:58.200
Is there a JFR recording on the page?

22:58.200 --> 23:00.200
Remote detach?

23:00.200 --> 23:02.200
Could be.

23:06.200 --> 23:11.200
Well, this is only the start of some of the events at the higher level.

23:11.200 --> 23:15.200
I think we are getting more and more conscious of adding events.

23:15.200 --> 23:17.200
For these kind of remote operations.

23:17.200 --> 23:19.200
Yep.

23:19.200 --> 23:20.200
Sorry.

23:20.200 --> 23:26.200
It was a vocal was asking was there a JFR event for remote detachability.

23:26.200 --> 23:29.200
From the JFR side or the.

23:29.200 --> 23:30.200
Yep.

23:30.200 --> 23:33.200
Anything else?

23:33.200 --> 23:34.200
No.

23:34.200 --> 23:35.200
Sorry.

23:35.200 --> 23:40.200
Do you trace scheduling the events for friends?

23:40.200 --> 23:44.200
I guess that would be at the JFR level for JVM events itself.

23:44.200 --> 23:45.200
There's.

23:45.200 --> 23:46.200
Yeah.

23:46.200 --> 23:53.200
I believe so on the JFR JVM level.

23:53.200 --> 23:56.200
This is only snapshot of what the JFR can do at the.

23:56.200 --> 23:58.200
The security API level.

23:58.200 --> 24:01.200
But at the at the JVM level, there's a much more detail.

24:01.200 --> 24:04.200
You've each tried on their state.

24:04.200 --> 24:09.200
But definitely watch this check and out.

24:09.200 --> 24:10.200
Okay.

24:10.200 --> 24:11.200
Thank you.

24:12.200 --> 24:13.200
Thank you.

24:13.200 --> 24:14.200
Thank you.

24:14.200 --> 24:15.200
Thank you.

24:15.200 --> 24:16.200
Thank you.

24:16.200 --> 24:17.200
Thank you.

24:17.200 --> 24:19.200
Thank you.

24:19.200 --> 24:20.200
Thank you.

24:20.200 --> 24:21.200
Thank you.

24:21.200 --> 24:22.200
Thank you.

24:22.200 --> 24:23.200
Thank you.