Thanks. It's not what I wanted to hear, but is what I expected. It looks like java reflection might be the only solution for us in the short-term. I will dig into the code to see if I can figure out what's needed.
Re: "stand alone installer" -- The support timeline for our legacy app is unlikely to extend past Oracle's Java 8 + Webstart stated commercial support date of 3/2025 <http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf>, so unless our app needs to be supported longer, it'll remain a JNLP app. On Tue, May 22, 2018 at 11:19 AM, Bernd Eckenfels <e...@zusammenkunft.net> wrote: > 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> 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> 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 >> >> >
