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

[Anthony Scarpino]

The property can get loaded very early and it can be hard to get ahead of it. 

The only suggestion I can think of is your option 1 isn't doing what you expect. To append to the existing java.security properties, you use one equals, “=“. To override you use 2, “==‘.  So you may want something like:
> java-vm-args="-Djava.security.properties==override_file" 

Tony

> On May 21, 2018, at 7:48 PM, Tom Hood <tom.w.hood at gmail.com> wrote:
> 
> 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/7ccbb80e/attachment.htm>