Score:0

How to disable lines in java.security to avoid javax.net.ssl.SSLHandshakeException?

ng flag

I need to disable the following lines in the java.security file (java 8 SE):

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
   include jdk.disabled.namedCurves

in windows

Image in Windows.

Windows path: Program Files\Java\jre1.8.0_301\lib\security\java.security

The purpose of disabling these lines is to avoid the following error message:

Error: javax.net.ssl.SSLHandshakeException: No appropriate protocol 
(protocol is disabled or cipher suites are inappropriate)

And the solution proposal published here (which is to comment on these lines).

I'm not sure if putting a comment at the beginning of the line (#) will disable them for both operating systems. Because this oracle document say is //

whichever one is used to comment out the lines, I also don't know if it is necessary to comment out all 3 lines, or just commenting out the first disables all 3. Example:

this way:

# jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
   include jdk.disabled.namedCurves

or that way?

# jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
#   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
#   include jdk.disabled.namedCurves

Question:

How to comment out (disable) the previous lines in java.security file on Windows and Linux to avoid "Error: javax.net.ssl.SSLHandshakeException", or someone explain to me if there is another solution, different from the one published

in flag
What do you want to achieve by disabling this line(s)? May be your approach is simply wrong or there is a simpler alternative.
vn flag
Enabling these broken algorithms will have significant security impact.
acgbox avatar
ng flag
I know and thanks for the clarification, however the question is not related to the security impact that disabling these lines can cause. The question is only related to "how to disable these lines correctly for windows and linux"
dave_thompson_085 avatar
jp flag
**Yes the comment character is `#` on all systems.** The document you link is about security _policy_ files, for the SecurityManager (originally designed for applets and now little-used); java.security is not a security policy file. Note as an alternative to changing JRE/lib/security/java.security which affects all JVMs, you can set _system property_ `java.security.properties` to point to a different (modified) file separately for each/any JVM e.g. with `-D` on commandline, or you can call `Security.setProperty()` in your code sufficiently near the beginning.
acgbox avatar
ng flag
@dave_thompson_085 please post this answer to select it as correct. and publish the lines of the example that I gave, commented, because I don't know if the first line or the 3 are commented. thanks for the clarification
Score:1
jp flag

Yes the comment character is # on all systems. The webpage you link is about security policy files, for the SecurityManager (originally designed for applets and now little-used); java.security is not a security policy file.

Yes do all 3 lines. The continuation syntax (backslash-eol) only works on uncommented lines, so to comment an item continued over multiple (physical) lines, comment each line.

However, since you now make clear the error is on the protocols, it would be safer to only delete the offending protcol(s) (almost certainly TLSv1(.0) and/or TLSv1.1 -- SSLv3 has been disabled since 8u31 in 2015 after it was catastrophically broken by POODLE) and leave the rest.

Are you by chance trying to use an old version of javamail? There was a (mis)feature for a while which defaulted secure mode to TLSv1(.0) (only) and triggered this symptom when 8u291 and several other versions came out; we have several existing Qs about it, just search "javamail no appropriate protocol". While removing or reducing the disabledAlgorithms setting (or regressing below 8u291) will allow the client to attempt a TLS1.0 connection, many servers today will not accept it because TLS1.0 is considered broken; that's why Java is now changed to disable it by default. In this case it would be better to upgrade javamail or to explicitly configure mail.{smtp,imap,pop3}.ssl.protocols to a value suitable today probably TLSv1.2,TLSv1.3.

(Other) Alternatives: in general instead of changing things in JRE/lib/security/java.security which affects all JVMs, you can set system property java.security.properties to point to a different (modified) file separately for each/any JVM e.g. with -D on commandline, or you can call Security.setProperty() in your code sufficiently near the beginning.

acgbox avatar
ng flag
a couple of things: Your answer answers my question, but partially or incomplete (It is not javamail, but an openbravo derivative called unicenta opos). And i would like if you could expand the last part "(Other) Alternatives" with a configuration example, because i can't find `java.security.properties` file into java folder. Thank you
dave_thompson_085 avatar
jp flag
@acgbox: `java.security.properties` is not a filename. As I said, it is a _system property_ whose _value_ can be the pathname (formally URL) of a file you create, which can be any name in any location you consider appropriate. This is _described_ at the top of the java.security file; look there, but note it only shows the basic way of setting the system property with `-D` whereas in some environments there are other ways hence my 'e.g.'.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.