Java 17 to 21: A Showcase of JDK Security Enhancements

Java
3 Mar 202446:31

Summary

TLDR本次演讲由Oracle的Java团队开发者倡导者Anna主讲,她分享了Java安全领域的最新进展。Anna首先介绍了Java安全组件,包括语言、加密、公钥基础设施、安全服务API等,并强调了Java平台持续改进的重要性。她详细讲解了从JDK 17到JDK 21的安全变化,包括对弱算法的限制、新的加密算法的引入、API的改进以及对量子计算机攻击的防护措施。Anna还提到了Java安全配置文件的更新,以及如何通过这些变化来提高应用程序的安全性。最后,她鼓励开发者关注Java安全相关的资源,并参与到Java社区的贡献中。

Takeaways

  • 🔒 Java 安全性不断进化,以应对算法弱化和潜在的量子计算机威胁。
  • 🌟 JDK 17 引入了新的安全特性,包括对安全算法的增强和对弱算法的限制。
  • 🔐 安全管理器(Security Manager)在 JDK 17 中被弃用,但仍然支持,直到 JDK 18。
  • 🛡️ JDK 18 禁用了 SHA-1 和某些 TLS 算法,以提高安全性。
  • 🔑 JDK 20 和 21 提供了更大的密钥尺寸,默认情况下增强了加密算法的安全性。
  • 🌐 引入了后量子密码学算法,如 SSS-LMS 和 XMSS,以抵抗量子计算机攻击。
  • 🔄 JDK 21 引入了新的密钥封装机制 API(CEM),提高了对称密钥加密的效率。
  • 📝 Java 安全配置文件(java.security 文件)允许开发者自定义安全属性。
  • 🔄 JDK 11 和 17 也支持某些 JDK 21 的安全特性,这些特性被回退(backported)。
  • 🔍 Java 安全工具(如 keytool 和 jarsigner)提供了新的功能和警告,以帮助开发者更好地管理密钥和证书。
  • 📖 Java 安全指南和路线图提供了关于 JDK 安全性变化的详细信息和测试指南。

Q & A

  • 在Java团队中,Anna的主要职责是什么?

    -Anna在Java团队中担任开发者倡导者,她喜欢使用Java进行编程,并且也热衷于与Kubernetes一起工作。

  • Java安全组件包括哪些部分?

    -Java安全组件包括语言层面的安全特性、加密组件(JCA)、公钥基础设施(PKI)、安全服务API(GSS-API)、传输层安全性(TLS/DTLS)以及各种安全工具。

  • 为什么开发者需要关注JDK的安全更新?

    -开发者关注JDK安全更新是因为随着时间的推移,我们使用的算法可能会变弱并被更容易地利用。JDK的持续改进使得开发者能够构建更安全的应用程序。

  • JDK 17之后,有哪些安全相关的变更?

    -JDK 17之后,有多项安全相关的变更,包括对加密算法的增强、TLS和DTLS的改进、安全管理器的废弃等。

  • 什么是SSS-LMS签名系统?

    -SSS-LMS(Lattice-based Multi-signature Scheme)是一种基于哈希的签名方案,它是量子抗性的签名算法之一,已经在OpenJDK中实现。

  • 为什么SHA-1在Java 18中被禁用?

    -SHA-1在Java 18中被禁用是因为NIST在2011年宣布了SHA-1的退役计划,并建议到2030年逐步淘汰其在数字签名中的使用。

  • 在Java 11和Java 17中,有哪些安全相关的API改进?

    -Java 11和Java 17中,安全相关的API改进包括对TLS和DTLS签名方案的自定义API、新的系统属性用于启用或禁用XML签名处理模式等。

  • 如何获取JDK安全配置文件的更多信息?

    -可以通过访问dev.java.net、inside.java以及YouTube上的Java频道来获取JDK安全配置文件的更多信息。

  • 开发者如何为Java社区做出贡献?

    -开发者可以通过撰写文章并提交到dev.java.net的仓库来为Java社区做出贡献,这些文章可以是关于Java的高级概念,也可以是基础概念。

  • 在JDK 21中,如何使用新的密钥封装机制API(CEM)?

    -在JDK 21中,新的密钥封装机制API(CEM)允许发送方使用接收方的公钥创建一个包含随机对称密钥的密文,并发送给接收方。接收方使用私钥解密这个密文以获取共享密钥。

Outlines

00:00

📅 安全讲座介绍

本次安全讲座由Anna主持,她是Oracle Java团队的开发者倡导者。Anna介绍了自己对Java编程和Kubernetes的热爱,以及她在过去的工作中对安全性的重视。她强调了Java平台不断改进的重要性,以确保应用程序的安全性。Anna还提到了Java安全组件,包括语言、加密、PKI、GSS API、TLS/DTLS和签名JAR文件等。

05:01

🔐 Java安全组件详解

Anna详细介绍了Java安全组件,包括Java加密架构(JCA)、公钥基础设施(PKI)、通用安全服务应用程序接口(GSSAPI)和传输层安全性(TLS/DTLS)。她还提到了Java安全工具,如密钥和证书管理工具(keytool)和JAR签名工具(jarsigner)。Anna强调了Java安全不仅仅是API,还包括运行时和工具。

10:04

🔒 加密算法的演进

Anna讨论了随着时间的推移,算法可能会变得脆弱并被利用。她提到了Java开发工具包(JDK)如何通过引入新的加密算法来增强安全性,例如在JDK 20和21中引入了更大的密钥尺寸。她还提到了量子计算机对现有数字签名方案的潜在威胁,以及IT行业如何致力于创建抗量子计算的加密算法。

15:06

🚫 限制和禁用弱算法

Anna解释了Java安全团队如何限制和禁用一些已知的弱算法,以保护用户免受潜在的安全威胁。她提到了SHA-1的禁用,以及在JDK 9中移除弱TLS算法的措施。Anna还提到了如何通过Java安全配置文件来设置限制规则,以及如何通过API来禁用这些弱算法。

20:08

🛠️ API改进和安全管理器的弃用

Anna讨论了JDK中API的改进,特别是与安全相关的API。她提到了安全管理器(Security Manager)在JDK 17中的弃用,并解释了如何通过临时启用来适应这一变化。Anna还介绍了新的API,如用于获取密钥存储属性的API,以及用于自定义TLS和DTLS连接的签名方案的API。

25:10

🔑 对称密钥的新加密技术

Anna介绍了JDK 21中引入的新密钥封装机制API(CAME),这是一种使用公钥加密来安全传输对称密钥的方法。她解释了CAME的工作原理,以及如何使用它来提高数据传输的效率。Anna还提到了XML签名API的改进,以及新的系统属性,用于启用或禁用XML签名处理模式。

30:12

💻 操作系统特定的安全特性

Anna讨论了JDK如何适应不同操作系统的安全特性。她提到了Windows和Mac OS中对密钥存储的改进,以及如何通过JDK提供的工具来管理这些安全特性。Anna还提到了JDK证书文件(keytool)的更新,以及如何使用这些工具来提高安全性。

35:16

🔍 监控和社区贡献

Anna强调了监控Java应用程序安全属性的重要性,并介绍了如何使用JDK飞行记录器(Flight Recorder)来跟踪这些属性的变化。她还提到了Java社区的贡献,鼓励开发者分享他们的知识和经验。Anna提供了一些资源链接,以便开发者可以了解更多关于Java安全的信息。

Mindmap

Keywords

💡Java安全

Java安全指的是Java平台提供的安全特性和机制,包括加密、认证、授权等,以保护应用程序和数据。视频中提到Java安全组件,如Java加密架构(JCA)、公钥基础设施(PKI)等,这些都是确保Java应用安全的关键部分。

💡JDK版本

JDK(Java Development Kit)版本指的是Java开发工具包的不同迭代,每个版本都可能包含新的功能、性能改进和安全增强。视频中提到了从JDK 17到JDK 21的安全变化,展示了Java平台如何不断进化以提供更好的安全性。

💡加密算法

加密算法是用于保护数据安全的数学方法,它们可以对数据进行编码,使得只有拥有正确密钥的人才能解码。视频中提到了现代加密算法的引入,以及对弱化算法的限制,这些都是为了提高Java应用的安全性。

💡量子计算机

量子计算机是一种利用量子力学原理进行计算的设备,其计算能力远超传统计算机。视频中提到量子计算机可能对现有的数字签名方案构成威胁,因此Java平台正在研究和集成后量子加密算法。

💡安全配置文件

安全配置文件是Java安全机制的一部分,它允许开发者和管理员配置和调整Java运行时的安全策略。视频中提到了如何通过安全配置文件来限制或启用特定的安全特性。

💡API改进

API(应用程序编程接口)改进指的是对现有API进行的更新和优化,以提供更好的功能、性能或安全性。视频中提到了Java安全API的一些改进,这些改进使得开发者能够更高效地使用Java安全特性。

💡密钥封装机制

密钥封装机制(Key Encapsulation Mechanism, KEM)是一种加密技术,它允许安全地传输对称密钥。在视频中,提到了JDK 21引入的新KEM API,这有助于提高对称密钥交换的效率。

💡安全事件

安全事件是指在Java应用运行过程中发生的与安全相关的事件,如安全属性的加载、安全提供者的实例请求等。视频中提到了如何通过JDK Flight Recorder监控这些安全事件。

💡安全工具

安全工具是用于帮助开发者和管理员管理Java应用安全性的工具,如密钥和证书管理工具。视频中提到了Java安全工具的改进,这些工具可以帮助用户更安全地管理密钥和证书。

💡安全社区贡献

安全社区贡献指的是Java开发者社区成员对Java安全文档、指南和工具的贡献。视频中鼓励开发者参与到Java安全内容的创作和改进中,以帮助整个社区。

Highlights

Anna, a developer advocate at Oracle, discusses Java security enhancements from JDK 17 to 21.

Java security is crucial for building secure software and keeping end users happy.

Java platform continuously improves to allow developers to build secure applications.

JDK releases introduce new features every 6 months, including security enhancements.

The Security Manager was deprecated for removal in JDK 17 due to its brittle permission model and poor performance.

JDK 20 and 21 introduced larger key sizes for stronger encryption by default.

Post-quantum cryptographic algorithms like SSS-LMS and XMS are being incorporated into Java security components.

Java security components include language features, cryptography, PKI, GSS API, TLS, and various tools.

JDK security configuration files allow developers to customize security properties and restrictions.

Weak algorithms like SHA-1 and weak TLS algorithms have been restricted or disabled in recent JDK releases.

New APIs for key encapsulation mechanism (KEM) and XML signatures have been introduced in JDK 21.

JDK security roadmap provides advanced notice of changes, allowing developers to test and prepare for updates.

Some JDK security changes are backported to earlier versions like JDK 8, 11, and 17.

Java security tools like keytool and jarsigner have been improved for better security practices.

Developers can contribute to the Java community by sharing their knowledge on dev.java.net.

Java security resources include the Java security guide, Java security standard algorithm names, and Java security roadmap.

Transcripts

00:00

[Music]

00:07

thank you everyone for joining a

00:09

security talk at 400

00:11

p.m. it's a little late in the afternoon

00:14

for some security topics um however I'm

00:17

grateful that you're here hope you will

00:19

enjoy this presentation until the end

00:21

that you will learn some useful things

00:24

that you can take in your daily

00:26

job and I'm looking forward to your

00:28

questions um at the end of the

00:32

presentation first of all I'm Anna

00:34

currently working as a developer

00:36

advocate in the Java team at Oracle I

00:39

enjoy programming with Java probably

00:41

like many of you since you are in this

00:43

room today and of course I enjoy working

00:46

with kubernetes as well now apart from

00:49

these two passions um I also like

00:52

security um in my past roles I like

00:56

security because I had to because it's

00:58

great to build secure software you have

01:00

your end users happy when they can

01:02

safely use their

01:04

applications uh so kind of security like

01:07

for many of you is embedded in the

01:10

practices that I have when I

01:13

code now when we talk about Java we I

01:17

hope that all of us in this room are

01:19

familiar with the new release Cadence or

01:22

you get to see many features delivered

01:25

every 6 months that you can try uh that

01:29

you can give uh um a feedback on and

01:32

these features are from multiple areas

01:34

many of them on language others on

01:37

performance and someone security yet

01:41

while these features get like Prime Time

01:45

your daily life can be impacted by those

01:47

many many enhancements that are not

01:50

necessarily formulated in a Jeep and

01:53

this presentation will show some of

01:55

those significant changes from 17 to 21

02:00

so if I am to ask you and because this

02:03

is a big room I cannot see all of you

02:06

but if I to ask you the question in the

02:08

slide can you shout at

02:11

me what do you think changed a change

02:14

that happened after jdk

02:16

17 with the security and jdk

02:22

anything just shout

02:24

it

02:26

records records that's a language

02:28

feature

02:32

security manager Bingo that's a very

02:34

good one the application for removal

02:37

we're going to talk a bit about it

02:39

anything else crypto

02:42

crypto that's a broad area we're going

02:44

to talk about it too anything

02:49

else

02:51

what I didn't understand you can you

02:54

please shout it h there TS TLS yes TLS

02:58

enhancements yes all great

03:01

answers and many more because we have 50

03:04

minutes for this presentation so I had

03:06

to fill it with something but the reason

03:09

why we care so much about jdk security

03:11

as developers is because over time the

03:15

algorithms that we are that we're using

03:18

in our applications weaken and can be

03:20

exploited more easily and it happens

03:23

that a GDK release take for example GDK

03:26

8 can Outlast the lifetime when these

03:30

algorithms are viable I mean jdk8

03:34

there's still many applications running

03:35

on those so what happens is that the

03:38

Java platform the jdk gets continuously

03:42

improved so that you can build secure

03:44

applications You're Building modern

03:45

applications but still they have to be

03:47

secured you're choosing Java to evolve

03:50

your applications because you know it's

03:52

secure that's one of the main things

03:54

that comes to your mind besides the

03:56

beautiful language there are many

03:58

beautiful languages that you can utilize

04:00

but you're also choosing them because

04:01

choosing Java because of security and of

04:04

course it's good to say to the business

04:07

Java is

04:08

secure so throughout time I've seen that

04:12

well people can think of java

04:15

security um as was some broad term so

04:19

what is Java security well Java security

04:21

has many components and since I'm going

04:23

to reference them in the presentation I

04:25

just want you to have a picture in your

04:27

head when I'm talking about them so here

04:30

they are the Java security components

04:33

are in the slide and of course they

04:36

start somebody said records of course it

04:39

starts with the

04:40

language um well but in the case of

04:43

security itself that is in the jdk the

04:46

higher level abstractions like you can

04:48

see here in the slide they are built on

04:51

top of lower layer Concepts so this is

04:54

why it's this like a brick wall

04:56

diagram and of course at the bottom the

04:58

Java language anguage is designed to be

05:01

type safe and easy to use so it has many

05:05

features that you probably use in your

05:07

application but the foundation of java

05:09

security well is based on

05:13

cryptography so the cryptography

05:15

component the Java cryptography

05:17

architecture

05:18

jca um or JC the Java cryptography

05:22

extension enables you to encrypt and

05:25

decrypt data in Java manage Keys sign

05:28

and authenticate message

05:30

and much more now we have also pki that

05:34

contains apis and implementations for

05:37

validating and building certification

05:39

paths or certification chains for only

05:41

many of your applications use

05:43

certificates and of course a way to

05:45

store those keys and

05:47

certificates next we go with how the

05:50

programs can access Security Services

05:53

via this lovely acronym which I'm not

05:56

going to read from the slide because I'm

05:57

terrible reading that acronym but we can

05:59

talk afterwards what it means it stands

06:02

for generic Security Service application

06:04

program interface that's why GSS upy and

06:08

the jdk contains such a GSS up

06:10

implementation of curve Ross now the

06:14

transport layer security which was

06:16

mentioned

06:17

earlier that

06:19

component is containing apis for TLS and

06:23

dtls and of course we're signing jars so

06:28

sign jars allow you to apply digital

06:30

signatures to the jar files in order to

06:33

ensure that you're sharing those with

06:35

some data integ the data you have in

06:37

those is shared with data integrity and

06:40

authenticity now the next components

06:43

they're

06:44

together because there are a series of

06:46

Frameworks and apis that are meant for

06:49

authentication and

06:51

authorization and of course probably

06:53

some of you have worked with XML

06:55

signatures which are a component uh well

06:58

this component that contains an API

07:00

implementation for generating and

07:02

validating XML

07:05

signatures but Java security is more

07:09

than just apis built on top on the

07:13

runtime it's also tools because

07:16

sometimes you need tools in your tool

07:18

chains to maybe I don't know validate

07:20

your certificates or and of course if

07:23

the jdk comes with them why not use them

07:25

since they're there so you get a small

07:27

set of tools that can help you set

07:29

security

07:30

policies probably many of you have

07:32

utilized in this lifetime key tool at

07:35

least

07:36

experimentally it's for managing key

07:38

stores keys and certificates of course

07:42

we have jar signer the one that we

07:43

talked a little bit earlier for sign

07:45

jars that helps of course signing those

07:48

jars and the last tab are actually the

07:51

tools for working with

07:54

kbros um but since Kos is not so touched

07:59

uh I'll leave them in peace for the

08:02

moment so hope you're feeling happy to

08:06

explore what happened with jdk

08:10

security and we're going to start with

08:12

the happy Parts modern cryptographic

08:15

algorithms now I started this

08:17

presentation telling you that over time

08:19

most or all algorithms weaken so they

08:22

can be exploited more easily now if you

08:24

get strong args you can continuously um

08:28

benefit of a stronger foundation for

08:30

your

08:32

application larger key sizes have been

08:36

delivered in jdk um 20 and 21 so you can

08:42

benefit of larger key sizes by default

08:45

like in case that when you're relying

08:47

for on the defaults and you're just

08:50

instantiating something um instantiating

08:52

a key without specifying the size

08:53

although that many examples over the

08:55

internet can have the size but if you

08:57

forget about that you don't need to

08:59

worry because the GDK can build that

09:02

securely at its best for you so you can

09:04

have here a table of what changed over

09:08

time this is good because this change

09:11

protects your data and communication by

09:14

using mathematical techniques that

09:16

ensure confidentiality integrity and

09:18

authenticity

09:20

better yet the tides of security threats

09:24

increase with the advancement of

09:26

technology and if you were the Kino this

09:28

morning

09:29

you probably saw the very nice keynote

09:31

about AI how AI can help us but those

09:35

were the good parts Ai and of course

09:39

computers that have large powerful cap

09:42

and large powerful

09:44

capabilities well they can be

09:46

instrumented for the wrong as well so if

09:49

large scale quantum computers are ever

09:52

built just this is a

09:54

hypothesis all widely used digital

09:57

signature schemes like

09:59

DSA RSA ecdsa and so on have the

10:03

potential to be broken that's because

10:05

the power of computation increased so

10:08

the IT industry has worked towards the

10:11

goal of creating postquantum

10:13

cryptographic algorithms that are

10:16

designed to be safe against such

10:19

powerful capabilities to

10:21

compute so as these postquantum

10:24

cryptographic algorithms progress and

10:27

mature of course they become standards

10:30

and are gradually Incorporated with the

10:32

Java security

10:33

components so we got the first post

10:38

Quantum cryptographic algorithms in open

10:41

jdk and you have here the explanation on

10:44

the slide so that you would know what it

10:46

stands for when you read

10:48

SSS

10:50

LMS so the lat Malla signature system is

10:56

one of the um one of these algorithms

11:00

and is the stateful health uh is a

11:02

stateful hash based algorith it's all

11:04

based on the hash based signature scheme

11:07

HPS that's what it's coming from the

11:09

hierarchical signature system is the

11:11

multi- three variant of the previous one

11:13

that's why it's SSS

11:15

LMS and most importantly it's one of the

11:18

two Quantum resistant signature

11:20

algorithms that have been standardized

11:22

there is another one it's called

11:24

XMS uh s it's similar but it's last

11:29

popular so the popular variant was

11:32

chosen um for the use case of such an

11:35

algorithm uh well it's used for software

11:38

and or firware

11:41

signing um and requires for the key and

11:44

signature generation to be performed in

11:46

Hardware cryptographic modules so that

11:50

they because those they do not allow

11:51

secret keying material to be exported

11:54

even in encrypted form that's why it

11:56

makes it quantum resistant it's hard to

11:59

export that from the

12:01

hardware so if we take a step back what

12:04

was done in the jdk right if um the um

12:09

signature generation happens on Hardware

12:12

what's happening in the jdk so when in

12:14

the jdk side the signature verification

12:17

implementation was

12:19

done so while the generation happens on

12:21

Hardware you can verify that signature

12:24

in the

12:25

jdk um and of course

12:29

you can have here in the slides the

12:30

explanations on why these this algorithm

12:33

is very great another thing that I need

12:35

to tell you is that this belief that the

12:38

security of LMS because it depends on

12:41

the security of the underlying hash

12:44

functions well it is believed that this

12:47

security is will never be broken by the

12:50

development of large scale computer

12:52

quantum computers hence why it's so

12:54

loved and

12:55

adopted now how does that look in your

12:58

code so how how do you verify a

13:00

signature with this new algorithm a

13:03

little bit of code in the slide just to

13:05

show you how it looks like you can use a

13:07

key Factory implementation available

13:10

from a provider now in this case if

13:12

you're running it with open jdk

13:13

distribution it probably will choose the

13:15

sound provider because that's the first

13:17

one that it finds it matches it and that

13:20

one will read an SSS LMS public key from

13:22

a stem a serialized

13:25

format so that's Reading part and of

13:29

course you need to verify the validity

13:30

and probably you've wrote this kind of

13:32

code sometimes to verify the validity of

13:35

a signature that uses SSS slms so the

13:38

thing that changed of course is the

13:40

algorithm being supported something

13:42

that's coming in 22 Key tool can also

13:45

operate with this one as well right now

13:47

it's available at the API level but in

13:50

22 jk22 it will have ke tool will have

13:53

that as a feature too so this one was

13:56

was one of the Breakthrough changes of

13:57

21

14:01

but besides the modern cryptographic

14:04

algorithms bringing new on the jdk

14:08

restricts the algorithms that are

14:10

weakened however there are multiple ways

14:13

to limit the usage of vulnerable

14:16

algorithms either the jav Java limits or

14:20

disables them to ensure that you are

14:22

running on a robust environment for your

14:25

not only for your own development but

14:26

also for your end users so what was

14:31

restricted some people probably saw that

14:34

kind of message when they tried to

14:36

validate a jar that was signed with

14:40

shaan and that it was having its

14:43

signature uh generated before 2019 1 of

14:47

January in 2019 so that's get a you get

14:50

a warning on that what's the story

14:52

behind it why Shawan jars were disabled

14:55

by default in Java 18 as the slide says

14:58

well it happens that in

15:00

2011 the National Institutes of

15:02

standards and Technology nist formally

15:06

dicated shaan usage and kind of told the

15:09

people well you know by

15:12

2030 you should kind of phased out the

15:15

usage from digital signatures that news

15:18

came two years later in

15:20

2013 so in consequence shaan was

15:23

disabled in TLS server certificates and

15:25

XML signatures was not just here now in

15:29

order to make sure that people are not

15:30

using this any

15:32

further jdk security team thought it

15:35

would be better if your

15:37

chars if you try to sign your chars with

15:39

this algorithm well to get the warning

15:42

that well um it's not good for you so

15:47

there's a a way to maintain uh backwards

15:49

compatibility of course for some of the

15:52

JS so if your jar was time stamped prior

15:55

to

15:57

20190101 We Shall one you get kind of

16:00

get away with it but uh if you have like

16:04

a very strict security team they can

16:06

alter a little bit the security rules

16:08

for you and they can impediment it so

16:11

I've seen cases when people went even

16:13

stricter given the threat of Shawan

16:15

usage so they restricted their security

16:18

properties even more we're going to talk

16:20

about that in a little

16:21

while so this was

16:24

one um another one delivered a lot

16:28

actually more delivery in 19 and 20

16:31

we're disabling weak TLS algorithms so

16:33

somebody mentioned TLS yes there were

16:35

enhancements but also disabled things

16:37

were disabled with the

16:39

TLs so in order to make it harder to use

16:44

week 3 3D Cipher suits they have been

16:47

removed from uh the TLs Cipher suits in

16:51

jk9 next 3s and arc4 they're also not

16:55

very safe um and because they were not

16:58

very safe also their Amon thls

17:02

ecdh ecdh Cipher suit also was disabled

17:07

because it doesn't preserve forward

17:09

secrecy and also it was rarely used in

17:12

practice sometimes these algorithms

17:14

they're not just insecure but they also

17:16

used in practice so disabling them is

17:18

not that difficult and well tls1.0 T and

17:23

TLS 1.1 they were disabled from April

17:26

2021 but as of J K2 dtls 1.0 is also

17:33

disabled because applications by the way

17:35

should use dtls 1.2 protocol which is

17:38

more secure and supported by the jdk but

17:42

in case that you have

17:45

issues yes you can also enable the one

17:49

that has been disabled you can reenable

17:51

it in the Java security configuration

17:53

file but that's something that you do at

17:54

your own risk so there's always a way to

17:56

alter the Java security file

17:59

but that's at your own risk when the um