Java 7 update 51 (January 2014) changes the deployment requirements for Applet & Web Start applications with two new requirements: use of the Permissions manifest attribute and valid code signatures. These changes will not affect developers of back-end or client applications; the scope is limited only to Applets & Web Start Applications (RIAs).
The following checklist is intended to help development teams track work necessary to accommodate user prompts.
|Permissions Manifest attribute in main JAR file||Required|
|Signed JAR files||Required|
|Timestamped during signing||Optional|
|Codebase Manifest attribute||Optional|
|RIAs using LiveConnect|
|Caller-Allowable-Codebase Manifest attribute||Optional|
|Trusted-Library Manifest attribute||Optional|
The software security industry performs an activity called Threat Modeling that assists in enumerating the attack surface of an application. These distribution changes address two types of threats:
Code signatures, along with timestamps, are also an industry best practice in securing the software supply chain. SSL certificates, used by HTTPS, address the communication channel – i.e. data ‘in motion.’ Code signing certificates, on the other hand, address the contents of data ‘at rest.’ Code signing certificates provide the ability to identify the software publisher on a storage medium and determine that no one has modified the code along the way.
Documentation for the above Manifest attributes is available in Jar File Manifest Attributes for Security. The Permissions attribute is the only one that is required. Other attributes of Codebase and Caller-Allowable-Codebase are optional because many ISVs may not know the ultimate destination. If that information is available to the software publisher, use of qualified names is encouraged.
Instructions for creating a code-signing certificate are available at the tutorial for Signing Code. Many Certificate Authorities provide instructions for using Java’s keytool commands to create a certificate signing request (CSR) to buy a signing certificate.
Certificates signed by a trusted Certificate Authority are accepted by clients without modification. These are recommended for most development organizations to work across a wide number of computers. Self-signed certificates are an option to known communities, but each computer will need to import the certificate into its trust store.
Code signatures can be verified through either of the following commands:
jarsigner -verify filename.jar
If the output does not say "jar verified" then the following command will provide more detail:
jarsigner -verify -verbose -certs filename.jar
Additional information about code signing can be located at Java Applet & Web Start - Code Signing.
By timestamping your artifact at time of signature, you can extend the lifetime of your signature to match the Timestamp Authority. This is strongly recommended for RIAs that will be in use beyond your own certificate’s expiration date. More information about the role of timestamping is available in the post, Signing code for the long-haul.
Although developers are encouraged to update RIAs according to the checklist, there are cases where it is not possible to modify already-deployed RIAs. Examples of this are cases where the RIA has been burned onto unmodifiable firmware, the original publisher is unknown or cannot be reached, or various cases dealing with support agreements.
The primary way for dealing with this is with a Deployment Rule Set.
Since Java 7 update 40 (September 2013), Deployment Rule Set has allowed a desktop administrator to control the level of client compatibility and default prompts across an organization. More information is available at the Deployment Rule Set documentation or the separate blog post, Introducing Deployment Rule Sets.