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

[Tom Hood]

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.scarpino at 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.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/20180522/ec52f93e/attachment.htm>