JDK-8027405 : Properly configured LiveConnect Applets must work even on JREs below the baseline by default
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7u25,7u40
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-10-28
  • Updated: 2014-01-16
  • Resolved: 2013-11-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
7u51 b08Fixed 8Fixed

For applets using LiveConnect that:
    - Are properly signed
    - Utilize the permissions attribute
    - Specify caller-allowable-codebase (wildcard or explicit url)

Treat all inbound LiveConnect calls from the allowable codebase(s) as "trusted" even if the current JRE is below the security baseline.


As part of our efforts to secure systems that rely on the Java Plugin we added increased restrictions to the JRE that kick in whenever the JRE falls below the security baseline or expires.  One such restriction is that self-signed and unsigned code can no longer run by default.

LiveConnect calls are always considered ���unsigned��� so even though the applet that handles LiveConnect calls might be properly signed we still treat the application as ���unsigned���.

With the release of 7u45, which drove 7u25 and 7u40 to below the security baseline, calls to LiveConnect ���even to applets that are being properly maintained, signed and with all the new required attributes present (e.g. caller-allowable-codebase is included in the manifest)- are being blocked by default on systems that are not updated to the latest JRE (7u45).   Companies that rely on services provided by LiveConnect applets consumed by users outside of their control are having to ask their end users to update to 7u45 or to lower the security slider for 7u40/7u25 to medium to continue being able to use their services.  

This has already resulted in high-level escalations to which the only answer we can give is you must ���encourage��� your users to update to 7u45, and you will have to do this again with every JRE update that moves the security baseline.

Since we already provide developers with mechanisms for restricting the use of LiveConnect to sites that they trust we can lower the constraints against the use of LiveConnect such that if a developer updates the applet itself with all the required attributes ���for the time being the caller-allowable-attribute, in the future that might include new deployment descriptor- and signs it the applet will be considered ���signed��� even though the JavaScript itself can���t be signed. 

Don't know if this requires backport. If the same restrictions that motivated this enhancement were backported to 6 then this needs to be backported

We assume the enhancement caused a regression in 7u deploy sandbox: https://bugs.openjdk.java.net/browse/JDK-8028292 We need evaluation of the JDK-8028292 before the approval to CPU14_01