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.h...@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 >
