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

[Tom Hood]

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 <ecki at 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-bounces at openjdk.java.net> on behalf of
> Tom Hood <tom.w.hood at 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.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/29590c8d/attachment.htm>