Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8201133

Security check failure for main jar downlaod with jnlp.versionEnabled and Deployment Rule Set feature

    Details

    • Subcomponent:
    • Resolved In Build:
      b01
    • CPU:
      x86
    • OS:
      other

      Backports

        Description

        FULL PRODUCT VERSION :
        build 1.8.0_161

        ADDITIONAL OS VERSION INFORMATION :
        Windows 10

        A DESCRIPTION OF THE PROBLEM :
        When using the <property name="jnlp.versionEnabled" value="true"/> in a JNLP file with the following naming convention <JAR file name>__V<version number>.jar for binaries, application fails to launch for security reason if JAR files are autosigned.
        @see https://docs.oracle.com/javase/tutorial/deployment/deploymentInDepth/avoidingUnnecessaryUpdateChecks.html
         
        This is always true unless using a specific deployment rule. Indeed, a way for enterprises to continue using JavaWebStart legacy business applications in their environment is to use the Deployment Rule Set feature.
        @see https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/deployment_rules.html

        Unfortunately the version-based download protocol passes through the security check implemented with this Deployment Rule Set feature.
         


        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        A formal DeploymentRuleSet.jar file must be set and properly signed with a valid certificate from a trusted authority

        JAR files referenced in the JNLP sample must be signed with a non valid certificate but defined in the ruleSet.xml

        Disable temporary files in general JAVA settings

        The JAR files repository must not support the classical version-based download protocol like when using a JnlpDownloadServlet
        @see https://docs.oracle.com/javase/8/docs/technotes/guides/javaws/developersguide/downloadservletguide.html

        Instead add <property name="jnlp.versionEnabled" value="true"/> in JNLP file and use the following naming convention <JAR file name>__V<version number>.jar with files in the repository



        EXPECTED VERSUS ACTUAL BEHAVIOR :
        EXPECTED -
        Application should launch normally


        ACTUAL -
        Application is bloqued by a java security dialog

        Note :
        When sniffing TCP request one can see a 6 times try request with URL http://&lt;site&gt;/&lt;main_jar_href&gt;.jar&version-id=&lt;version_value> for the main jar download
        following by http://&lt;site&gt;/&lt;main_jar_href&gt;__V&lt;version_value&gt;.jar

        The first 6 times failure looks normal when download protocol with query parameter &version-id is not handled by the repository server (tomcat jetty etc...)

        But the last request with version naming convention in the URL should have been called instead when using <property name="jnlp.versionEnabled" value="true"/>
        Strangely, this is what happened for all other JAR download request but the main one. It starts trying download with URL like <JAR file name>__V<version number>.jar, then try with the casual &version-id query parameter one.

        Unfortunately it passes through the security check implemented with this Deployment Rule Set feature.

        It behaves normally when a valid certificate is used because a specific RuleSet is not required.



        REPRODUCIBILITY :
        This bug can be reproduced always.

        CUSTOMER SUBMITTED WORKAROUND :
        If temporary file is enable in JAVA settings the failure occurs only once, then application can be launched normally. It sounds logical since there is no need to perform update check with up-to-date files stored in cache.

        Another workaround is to use a JnlpDownloadServlet like to deal with the classical version-based dowload protocol.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  herrick Andy Herrick
                  Reporter:
                  webbuggrp Webbug Group
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: