What to do if your applet is blocked or warns of “mixed code”?
By Erik Costlow-Oracle on Oct 15, 2013
Recent security changes, including the October 7u45 critical patch update, for RIAs (Applets & Web Start applications) have affected several audiences in different ways. Other types of applications (such as back-end server applications, web applications, middleware, client-installed applications, and others) are unaffected by these changes.
Two notable changes are:
- In the future, Java 7 update 51 (January 2014) will introduce a code-signing requirement for RIAs.
Affected RIAs should be patched and updated immediately by their developers. Sometimes this is not feasible, such as cases of an application purchased from a vendor, an RIA is burned into device firmware, or the RIA has been in use for years and nobody knows the maintainer. In those situations, System Administrators can take steps to adapt to these changes if they prefer not to be notified.
<rule> <id location="https://www.example.com/program" /> <action permission="run" version="SECURE" /> </rule>This is an important step because web pages are often made of many components, such as analytics, image hosts, and other pieces. Whitelisting your domain prohibits others from calling in to your Java application.
- If the RIA is hosted at a different location, such as a content delivery network, you can whitelist it separately with the hash of its certificate.
<rule> <id> <certificate algorithm="SHA-256" hash="794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6" /><!-- Oracle's public certificate hash. Having this will allow things like the Java.com secure version check applet. --> </id> <action permission="run" /> </rule>
System Administrators or Developers can overwrite the application’s signature and add the appropriate Manifest entries. While it does not involve code changes, modifying a JAR file will break the digital signature and requires generating a new one. If you take someone else’s signed document and make changes – your changes invalidate the document they signed, so you need to white-out their signature and apply your own.
- Identify the appropriate JAR file by looking at the JNLP deployment descriptor file. There is a JAR resource specification inside that looks like:
<jar href="JavaDetection.jar" />
- Extract the MANIFEST.MF file:
jar -xf JavaDetection.jar META-INF/MANIFEST.MF
- Open META-INF/MANIFEST.MF in a text editor. Modify the entries that you need, following the Security Manifest Properties documentation:
- Permissions – either sandbox or all-permissions. Sandbox is recommended unless the RIA needs further permissions.
e.g. Permissions: sandbox
- Codebase – the original developer often does not have enough information to supply this optional attribute because they do not know where it will be deployed. Provide your hosting location and domain.
e.g. Codebase: https://www.example.com
- Caller-Allowable-Codebase – If your RIA requires a calling web page to make LiveConnect calls into the RIA, providing this optional attribute will allow those calls without additional user prompts. The original developer may not have this information because they might not know where it will be deployed. For LiveConnect, this must be provided even if it is the same as the Codebase.
e.g. Caller-Allowable-Codebase: https://www.example.com https://customers.example.net
- Place your MANIFEST.MF file back into the JAR file:
jar -ufm JavaDetection.jar META-INF\MANIFEST.MF
- The final step is to sign the JAR file using your own certificate.
- Optional: If you want to verify that these modifications invalidated the previous signature :
jarsigner -verify JavaDetection.jar
- Apply your own signature to the file:
jarsigner -verbose -keystore "c:\Users\ecostlow \javakeystore_keepsecret.jks" -signedjar JavaDetection.jar -tsa http://timestamp.verisign.com your-certificiate-alias