JNLP launched legacy app needs to override jdk.tls.disabledAlgorithms

[Tom Hood]

Hi,

Our legacy app will no longer launch with JNLP as of Java 8u171 and 8u172
due to the addition of "3DES_EDE_CBC" to the global java.security file's
"jdk.tls.disabledAlgorithms" property.

Schedule constraints do not allow us to upgrade our application to a
stronger cipher suite at this time and our customer is okay with continuing
to run with a compromised cipher suite in the near term for our legacy app.

Problem is we cannot (and probably should not) simply edit the global
<installdir>/lib/security/java.security file.  Also, we would prefer not to
edit "Runtime Parameters" in the java control panel on each user's PC to
specify an override property file.  We would like a way to override in a
JNLP launch.  Is this possible?

Other info about the app:
- JNLP has security element:  <security><all-permissions/></security>
- SSL connection that uses the compromised cipher suite is coming from
inside the guts of an antiquated, unsupported ORB implementation
(Visibroker 5.2.1).  Its source code is not available.  It does not support
a stronger cipher suite.

Things I've tried:

(1) add an overrides file with System property "java.security.properties"

It doesn't appear there is a way to do this for a JNLP launch.  I tried
each of the following individually and none had the desired effect:

<j2se version="1.6+" java-vm-args="-Djava.security.properties=override_file"
.../>
<property name="java.security.properties" value="override_file"/>
<property name="jnlp.java.security.properties" value="override_file"/>

None of them have any effect except the last one which sets the system
property before main() starts, but that doesn't help, because it has the
"jnlp." prefix which isn't what the Security class expects.

Since "-D" is not listed as a secure arg for "java-vm-args", it looks like
this is not possible by design, despite the jnlp file having
<security><all-permissions/></security>.  Reference doc:
https://docs.oracle.com/javase/8/docs/technotes/guides/javaws/developersguide/syntax.html#resources

(2) At start of app's main(), call
Security.setProperty("jdk.tls.disabledAlgorithms",
newvalue)

JNLP launch: no change; fails same way
Eclipse run as regular Java app: now works

This leads me to believe the old value for the property is used and/or
cached in places other than the Security class *before* main starts for a
JNLP launch compared to when run as a regular Java app.

(3) At start of app's main, use reflection as follows:

(a) with reflection: force loading of
sun.security.ssl.SSLAlgorithmConstraints class via Class.forName
(b) call Security.setProperty("jdk.tls.disabledAlgorithms", newvalue)
(c) with reflection: SSLAlgorithmConstraints.tlsDisabledAlgorithms = new
sun.security.util.DisabledAlgorithmConstraints(PROPERTY_TLS_DISABLED_ARGS)
(d) call Security.setProperty("jdk.tls.disabledAlgorithms", oldvalue)

JNLP launch: no change; fails same way
Eclipse run as regular Java app: now works; without substep (c) it fails
same way

The old value must have been used and/or cached elsewhere besides
SSLAgorithmConstraints for a JNLP launch compared to running as a regular
java app.

Unfortunately, I'm not sure I have the source code for sun.* that matches
up with 8u172, otherwise I would try to find where else that property is
read.  Even if I could get the reflection to work, it seems all too fragile
and likely to break in future Java updates.  I'd prefer a different
approach.

Any suggestions?

Thank you,
-- Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20180521/e932b57d/attachment.htm>