11 Replies Latest reply: Apr 16, 2014 1:50 PM by bldsweng RSS

Deployment Rule Set for allowing JavaScript from same host to signed applet independent of codebase?

bldsweng Newbie
Currently Being Moderated

We supply a signed applet to our customers and do not know in advance what codebase will be used. Our applet also interacts with JavaScript through LiveConnect.

 

We would like the applet to be able to run even if the end user has their Java Control Panel Security Slider set all the way to Very High. We have found that even Caller-Allowable-Codebase set to * in the applet jar manifest does not help -- only a deployment rule set seems capable of allowing LiveConnect to work in this scenario.

 

We know the customer can use a rule such as the following to allow any applet signed by us:

  <rule>

  <id>

  <certificate algorithm="SHA-256"

  hash="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" />

  </id>

  <action permission="run" />

  </rule>

 

However, to allow LiveConnect to work with our applet, a rule like the following is required:

 

  <rule>

  <id location="*.acme.com">

  </id>

  <action permission="run" />

  </rule>

 

Questions:

 

1) Is there anything we can do in the manifest to allow LiveConnect to work with Very High security without a deployment rule set? That would be ideal.

 

2) The second deployment rule requires a priori knowledge of the codebase and also appears to allow any applet from "*.acme.com" to run, which is not the intent. Is there any way to grant LiveConnect access to our applet if it originates from the same host (or even anywhere would be acceptable in our case)? Or if not that, is there a way to restrict the second deployment rule to LiveConnect only? We want to avoid opening the security hole where a compromised server or DNS spoofing could allow an applet not signed by us but from *.acme.com domain to run.

 

Message was edited by: bldsweng

  • 1. Re: Deployment Rule Set for allowing JavaScript from same host to signed applet independent of codebase?
    bldsweng Newbie
    Currently Being Moderated

    According to https://bugs.openjdk.java.net/browse/JDK-8021826:

     

    I believe we need to document 3 main points: (1, 2a and 2b)

     

    1. java <-> java mixed code. this is bug https://jbs.oracle.com/bugs/browse/JDK-8021232. To avoid mixed code dialog for pure java case, you need a DRS rule that covers the code being called in a mixed code case.

     

    e.g a.jar -> b.jar, where a.jar and b.jar runs in different permissons, to avoid mixed code dialog, you need a run rule that covers b.jar.

     

    2. javascript -> java case. this is bug https://jbs.oracle.com/bugs/browse/JDK-8021299.

     

    a. For javascript calling into applet methods directly, to avoid mixed code dialog, you need a run rule that covers the applet method JAR that is being called into.

     

    b. For javascript calling into Java code directly, to avoid mixed code dialog, you need a run rule that covers the location of the javascript.


    And presumably this was the case of 7u40.


    According to 2a., if I am only making LiveConnect calls to direct applet methods, any deployment rule covering the applet should also cover any LiveConnect calls to/from it.


    I have a properly signed (not self-signed) deployment rule set deployed properly:

     

    • <ruleset version="1.0+">
    •   <!-- Accept applets signed by our company -->
    •   <rule>
    •     <id>
    •       <certificate hash="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" />
    •   </id>
    •     <action permission="run" />
    •   </rule>
    •   <!-- Because this is both blank and shown last, it will be the default policy. -->
    •   <rule>
    •     <id />
    •     <action permission="default"/>
    •   </rule>
    • </ruleset>

     

    When the Security Slider is set to the default of 'High' -- the applet runs without any warnings.

    But when I set the Security Slider set to 'Very High', No matter what the Security Slider is set to,

    the applet silently fails to load. In the console log, I can see that the JNLP matches the certificate hash rule:

     

    ruleset: finding Deployment Rule Set for

            title: My Applet

            location: http://myhost.com/MyApplet.jnlp

            main location: http://MyApplet.jar

            main version: 1.0

            isArtifact: true

    ruleset: Rule title: null matches artifactId:My Applet

    ruleset: Rule location: null matches artifactId: http://myhost.com/MyApplet.jnlp

    security: SHA-256Certificate finger print: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    ruleset: Rule hash matches certificate hash

    ruleset: Matching Rule ID:

            title: null

            location: null

            certificate algorithm: null

            certertificate hash: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

            isArtifact: false

    ruleset: found matching id, using rule: Rule:

        id:

            title: null

            location: null

            certificate algorithm: null

            certertificate hash: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

            isArtifact: false

        action:

            permission: run

            version: null

            message: null

     

    But then later on I see that the web page containing JavaScript for the LiveConnect calls to the applet do not match that same rule:

     

    ruleset: finding Deployment Rule Set for

            title: null

            location: http://myhost.com

            isArtifact: false

    ruleset: Rule location: null doesn't match docbase location: http://myhost.com

    ruleset: Matching Rule id for docbase only:

            title: null

            location: null

            isArtifact: false

    ruleset: found matching id, using rule: Rule:

        id:

            title: null

            location: null

            isArtifact: false

        action:

            permission: default

            version: null

            message: null

    security: LiveConnect (JavaScript) blocked due to Deployment Rule Set.


    Given that the LiveConnect codebaseis falling onto the default rule, I still would have expected it to run with the Security Slider set to High or Medium. But it doesn't.


    The only thing that works is to add a specific rule that matches the codebase:


    •   <rule>
    •     <id location="myhost.com"/>
    •     <action permission="run"/>
    •   </rule>

     

    But again that opens the door for any applet at that same codebase as well.

     

    More 7u45 regressions??

  • 2. Re: Deployment Rule Set for allowing JavaScript from same host to signed applet independent of codebase?
    bldsweng Newbie
    Currently Being Moderated

    https://bugs.openjdk.java.net/browse/JDK-8022007

     

    is specifically for "DRS: Mixed code dialog for javascript to java call should be suppressed if DRS run rule is in effect for called artifact" backported to 7u45 and the comment says "RT waived verification of sync fixes."

     

    Oops! I think there was big regression here that slipped through QA.

  • 3. Re: Deployment Rule Set for allowing JavaScript from same host to signed applet independent of codebase?
    costlow Newbie
    Currently Being Moderated

    What you've done is right. You need two rules for this due to the unsigned nature of JavaScript, where TLS authenticates the transportation layer but not the contents of what's being transported. The CA Browser Forum has some info about their involvement with code signatures (as opposed to ssl certificates).

    Are you looking for something more like certificate pinning for the location? Like saying "from location https://example.com and I know ahead of time that their certificate hash is XXXXXXXX"

  • 4. Re: Deployment Rule Set for allowing JavaScript from same host to signed applet independent of codebase?
    bldsweng Newbie
    Currently Being Moderated

    Costlow,

     

    Based on my read of https://bugs.openjdk.java.net/browse/JDK-8021826, I think that your assertion that two rules are required is incorrect.


    Item 2a referenced in JDK-8021826 tells me that a rule covering the JAR containing the applet methods in question should also cover LiveConnect calls directly to those methods. In my case, the one rule is one based on the certificate signature hash without regard to the location. That rule definitely works to load the applet itself without any warnings -- it's the LiveConnect calls that subsequently fail (no matter what the Security Slider is set to -- which seems doubly wrong).


    I was hopeful that this was a regression in 7u45 (since the JDK bug reports seem to indicate that this was done and tested in 7u40 but not tested in 7u45) --  there really does need to be a way to allow LiveConnect from the same codebase/location calls to a signed applet without needing to know that codebase/location in advance.


    Further, I don't understand why a Deployment Rule Set is even necessary if I have Caller-Allowable-Codebase set to '*' in my signed applet's manifest.

  • 5. Re: Deployment Rule Set for allowing JavaScript from same host to signed applet independent of codebase?
    bldsweng Newbie
    Currently Being Moderated

    And to be clear, I am not getting a "mixed code dialog" (perhaps the Caller-Allowable-Codebase manifest attribute is doing its job there) -- it's just that the LiveConnect calls fail with only a trace message in the console log:

     

    security: LiveConnect (JavaScript) blocked due to Deployment Rule Set.

  • 6. Re: Deployment Rule Set for allowing JavaScript from same host to signed applet independent of codebase?
    bldsweng Newbie
    Currently Being Moderated

    Sadly, the Oracle blog dealing with this issue is now closed for comments. https://blogs.oracle.com/java-platform-group/entry/liveconnect_changes_in_7u45 And there hasn't been any further feedback here. Reporting bugs in the JDK seems to be a black hole as well. We are trying to work through our Oracle sales rep to get a support contract in place to escalate many of these JRE security bugs -- but at the same time feel it should not be necessary to do that.


    I have yet to see this or any of the numerous issues we've raised with JRE 7u45 show up on the official bug list.

  • 7. Re: Deployment Rule Set for allowing JavaScript from same host to signed applet independent of codebase?
    bldsweng Newbie
    Currently Being Moderated

    Costlow, any further feedback on this please?

  • 8. Re: Deployment Rule Set for allowing JavaScript from same host to signed applet independent of codebase?
    Mr. S Newbie
    Currently Being Moderated

    I am chiming only to confirm that I (and my organization) too am having the same results (security windows prompting to block/unblock) after appending "Caller-Allowable-Codebase: *" to the manifest file when signing the jar with self-issued cert for testing purposes.  The need to call signed methods from javascript is essential.

     

    I feel we are bobbing for apples

     

    And, with the end-of-year celebrations, it seems we will have to hope that release 51 will address THIS issue and not break anything else...

     

    On a another note, if anyone has the workaround, I'm sure Oracle has an open position for you

  • 9. Re: Deployment Rule Set for allowing JavaScript from same host to signed applet independent of codebase?
    user9146454 Newbie
    Currently Being Moderated

    Like many others out there, I'm in this same predicament.  Java 7 Update 45 provides no way to white-list an RIA unless you know the codebase it will be running from.  This prevents software vendors from providing any assurance to their customers going to Java 7 Update 51 (expected this Tuesday).  This means legitimate commercially supported software -- the stuff that *should* still run in Java  -- will stop functioning if it requires JavaScript/LiveConnect for proper functionality.

     

    The recommendation from Oralce to use the DeploymentRuleSet on Oracle's own tutorial is incorrect and does not work (to the OP's point.  Oracle's own example states "If you want to allow multiple RIAs from multiple locations to run, and all RIAs are signed with the same certificate, you can use the certificate element".  Nope, it won't run from "multiple locations".  Not in any testing I've done, and not in the OP's testing. To see the example click here, scroll to the very bottom).  This has caused a lot of grief for RIA developers and means ISVs will have to build separate custom rulesets for all of their customers including a valid "location" parameter that matches the codebase (Alternately, Desktop Administrators working for said customers would need to understand code signing, code timestamping as well as RIA ruleset quirks, and this likely won't happen).

     

    I too contacted Oracle to purchase support on this issue and I was told by the sales representative that support "would likely not help in [my] case".  In addition, Oracle Java support starts at $20,000 USD annually (which seems steep compared to most support contracts I've paid) and the sales representative linked me to YET ANOTHER way to whitelist the RIA (which STILL doesn't solve this problem, and which won't be available until Java 7 Update 51).

     

    Like others reading (and most probably lurking this thread), I have NO solution to this issue.  My best work-around for now is to catch the Exception and explain to the end-user why the applet won't work.

     

    try {

      applet.getVersion(); // Some internal function that LiveConnect will block

    } catch(err) { // LiveConnect error, display a detailed meesage

      alert("ERROR:  \nThe applet did not load correctly.  Communication to the " +

      "applet has failed, likely caused by Java Security Settings.  \n\n" +

      "CAUSE:  \nJava 7 update 25 and higher block LiveConnect calls " +

      "once Oracle has marked that version as outdated, which " +

      "is likely the cause.  \n\nSOLUTION:  \n  1. Update Java to the latest " +

      "Java version \n          (or)\n  2. Lower the security " +

      "settings from the Java Control Panel.");

    }

     

    I find myself asking...  Should the end user read this message?  My answer is: absolutely not. However, when LiveConnect fails silently and trained IT staff can't figure out why, notifying the end user is a last-ditch effort at establishing a communication channel to resolve this issue.  The customer is suffering business productivity loss due to one more botched, poorly implemented, poorly documented "security measure" and Java as a business solution loses even more credibility from both IT support perspective as well as an end user perspective.  Will it get worse before it gets better?  I see no "light at the end of the tunnel".

    -Tres

  • 10. Re: Deployment Rule Set for allowing JavaScript from same host to signed applet independent of codebase?
    bldsweng Newbie
    Currently Being Moderated

    A properly signed RIA with the appropriate manifest entries and wildcard codebase in 7u51 can now apparently run the LiveConnect calls without issue if a Deployment Rule Set is not in play. Unfortunately, the Deployment Rule Set feature still requires a rule that matches the location for LiveConnect calls. Even more egregiously, a RIA requiring LiveConnect that would have otherwise run without a deployment rule set in 7u51 will still have its LiveConnect calls blocked by a deployment rule set that looks like:

     

    <ruleset version="1.0+">

      <!-- Accept applets signed by Guidewire -->

      <rule>

        <id>

          <certificate hash="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" />

      </id>

        <action permission="run" />

      </rule>

      <!-- Because this is both blank and shown last, it will be the default policy. -->

      <rule>

        <id />

        <action permission="default"/>

      </rule>

    </ruleset>

     

    This is ridiculous -- because even if LiveConnect calls fall through to the lowest rule, the "default" permission for them should be "allow" since they would have been allowed without the deployment rule set at all. But the real issue is that if a deployment rule set rule matches the applet, either through location or certificate hash, the deployment rule set should only be consulted for the LiveConnect calls if the matching applet has not given enough information to permit them.

  • 11. Re: Deployment Rule Set for allowing JavaScript from same host to signed applet independent of codebase?
    bldsweng Newbie
    Currently Being Moderated

    Sigh.

     

    7u51 improved things by allowing a wildcard '*' for Caller-Allowable-Codebase in the manifest -- thus bypassing the security warning for JavaScript invoking the applet, But 7u55 has now brought that warning back. See JDK-8033707 and the 7u55 release notes.

     

    Oracle, why do you keep making life hard by changing things from release to release?! The deployment codebase is not always known a priori as many users have pointed out. There has to be a way for a signed applet to allow RIA calls without prompting from the same domain regardless of what that domain might be.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points