You probably don’t want to hear that, but now is a good time to convert this JNLP App into a stand alone Installer (possibly with updater).that will not only allow you to ship a pre-configured and matching JRE, but it will also solve the problem that you do not get javaws updates starting on January (easily) anymore.
JNLP does not allow to overwrite random properties for the started app. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: security-dev <security-dev-boun...@openjdk.java.net> on behalf of Tom Hood <tom.w.h...@gmail.com> Sent: Tuesday, May 22, 2018 4:31:31 PM To: Anthony Scarpino Cc: security Dev OpenJDK; Smith, M'Lissa (Mission Systems) Subject: Re: JNLP launched legacy app needs to override jdk.tls.disabledAlgorithms Clarification. When I said for option (1) "none had the desired effect", I mean at the start of main I confirmed with System.getProperty that the java.security.properties property isn't getting set thru the JNLP launch, so I doubt "==" will make any difference compared to "=". As far as "override" vs. "append" either one in theory could be made to work for our use case. The goal is to be able to change the value of the "jdk.tls.disabledAlgorithms" property so it no longer has 3DES_EDE_CBC at the start of the jvm. On Mon, May 21, 2018 at 8:56 PM, Anthony Scarpino <anthony.scarp...@oracle.com<mailto:anthony.scarp...@oracle.com>> wrote: 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<mailto: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
