Java Applet & Web Start Code Signing
Starting with Java SE 7 Update 21 in April 2013 all Java Applets and Web Start Applications are encouraged to be signed with a trusted certificate. And starting with 7u25, all files must be added to JARs prior to signing.
Overview
During the February 19, 2013 Java Critical Patch Update (CPU)1, Oracle announced its intentions to deliver a new Java CPU release, Oracle Java SE 7 Update 21 (Java SE 7u21), on April 16, 2013. Along with delivering security remediation, Java SE 7u21 will also deliver some key security features. Most significant is a new requirement that all Java applets and Web Start Applications using the Java plug-in to run in browsers be signed with a trusted certificate for the best user experience. Java supports code signing, but until Java SE 7u21 it was an optional feature. Application code signing provides numerous security benefits to users.
Java SE 7u21 will introduce changes to security levels on the security slider within the Java Control Panel. Authors and vendors of applications deployed using either Java applets or Java Web Start technology – applications distributed to end users at runtime via the web browser or network - should sign their code using a trusted certificate for the best user experience. Specifically, all Java code executed within the client’s browser will prompt the user. The type of dialog messages presented depends upon risk factors like, code signed or unsigned, code requesting elevate privileges, JRE is above or below the security baseline, etc. Low risk scenarios present a very minimal dialog and include a checkbox to not display similar dialogs by the same vendor in the future. Higher risk scenarios, such as running unsigned jars, will require more user interaction given the increased risk.
Even the smallest changes in user experience are sometimes troublesome. We have considered how changes affect user experience. Given the current climate around Java security in the browser, code signing is a valuable security control for protecting Java users.
What changes are being introduced?
Java SE 7u21 will introduce changes to Java browser plug-in behavior, encouraging application authors and vendors to sign code with a certificate from a trusted Certificate Authority. Developers are strongly encouraged to sign code now in preparation for this release and future releases. Details of the new security prompts can be found in this java.com article.
These steps will significantly lower risks to desktop users. We are also removing the “low” security settings in the Java Control Panel (e.g., low/custom), to prevent users to from inadvertently opting-out entirely from the security remediation we are building into Java. Users will be better protected by maintaining up-to-date versions of the JRE on their systems, combined with requiring code that is signed by a Trusted Certificate Authority (rather than self-signed or unsigned code).
Why are these changes important?
Java operating in the browser is a popular target for attackers. Starting with 7u10 in late 2012, Oracle introduced user configurable settings that can be used to only allow ‘trusted’ applets to be executed. Trusted applets are those that are signed by certificates issued by trusted certificate authorities, and finally approved by end-users. Code signing improves user confidence in the identity of the applet providers, and helps enforce accountability of the provider for the safety of the applet they provide.
Will these changes break my applications?
The changes in 7u21 should not break your application, but developers are strongly encouraged to verify the proper operation of all applications with every update release. The platform will not deny the execution of Java applications, however in high-risk scenarios the user is provided an opportunity to abort execution if they choose. Future update releases may include additional changes to restrict unsafe behaviors like unsigned and self-signed applications.
What does code signing mean to desktop users?
Signing code with a trusted certificate will provide a better user experience and more information to help prevent against attackers.
What does code signing mean for application authors and vendors?
To present the best user experience, authors and vendors of Java applications deployed using either Java applets or Java web start technology are encouraged to sign their code before the April CPU release of Java SE 7u21. Further, all software code should be kept up to date with the latest versions of Java. Discouraging users from upgrading to the latest releases of Java will change the users experience since Java will be operating below the security baseline. All users are strongly encouraged to upgrade to the most recent Java versions to ensure the security of their systems.
What should application authors and providers do to prepare?
In general, the recommended deployment advice for all Java applets and web start applications is:
Deploy using JNLP for both applets and web start:
Specify "all permissions" in the deployment descriptor if you need elevated permissions.
Sign the application using a code signing certificate from a trusted Certificate Authority.
Always test your applications using the most recent Java versions.
Communicate changes in user experience to your customers.
How do I sign my code?
Code signing certificates are widely available from a number of commercial Certificate Authorities, or via self-signing tools. We recommend searching online for "Certificate Authorities" or "self signed certificate tools" to find solutions that will meet your needs. Most Certificate Authorities will also provide step-by-step instructions on how to sign your applications, and there are many online examples of how to do self-signing. Please note that self-signing is primarily of value to developer and intranet applications as it also requires managing the keystore for Java. For more information, please see the Key and Certificate Management Tool documentation.
How has this changed the underlying security model of Java applications in the browser?
As of 7u21, signing no longer automatically equates to privileged execution, all Java applets and web start applications should be signed. Applications deployed using JNLP (Java Web Start and JNLP Applets) use JNLP to specify whether the application will run in the sandbox or will request full permissions from the user. This is the recommended approach. Applets deployed using the older HTML tag approach (applet, embed or object tags in an html page) also should be signed. Because the legacy practice was that signing applets indicated an intention to run with permissions, that will be the default behavior for signed html-tag-deployed applets. If you have an applet that is deployed in this way, and it does not require asking users for full permissions, add the following parameter to the tag: <param name="permissions" value="sandbox" />
Please see the "Deploying with the Applet Tag" documentation for more information.
Does the code signing requirement impact "mixed code" environments?
Potentially, yes. In situations where signed and unsigned components (usually Javascript in the browser) are mixed, users may be presented with a dialog "Java has discovered application components that could indicate a security concern." Developers can manage this by configuring an attribute in the manifest file, and is documented in the "Mixing Signed and Unsigned Code" documentation. Instructions for home users facing this warning can be found at this java.com support note.
Starting with 7u25, why is a signed JAR that previously worked fine now being flagged as unsigned?
Prior to 7u25, some components such as the index.list entry were allowed to be unsigned. As of 7u25, all contents of a JAR must be signed. Failure to do so will trigger the unsigned code warning. To properly sign a jar, index entries must be created before the jar is signed. For more information see 8016771.
What additional steps can I take to ensure the security of systems running Java applications in the browser?
Java users, system administrators and developers are strongly encouraged to keep systems up-to-date with the latest Java versions. The Java auto-update mechanism is designed to keep Java users up-to-date with the latest security fixes; if you have previously turned auto-update off we encourage you to turn it back on to ensure you have the latest and most secure Java versions on your system. See the Java 6 Auto-Update to Java 7 FAQ for additional information.
For enterprises, desktops should be updated according to your enterprise's policies. Enterprises should inventory any plug-in applications and sign them with a trusted certificate.
Java Security - Additional Resources For:
Developers Java SE Security Secure Coding Guidelines for the Java Programming Language Java SE 7 Security Documentation Enterprise Oracle Java SE Advanced and Oracle Java SE Suite products provide enterprise features that minimize the costs of deployment, monitoring, and maintenance of Java-based IT environments. System Administrators Deployment Best Practices Java Plug-in Guide for System Administrators Tutorial: Security Features in Java SE End Users Java - Help (Java.com) Security level settings in the Java Control Panel