With the release of Java Runtime Environment (JRE) 7 update 45 new security measurements are introduced. Oracle describes the impact of the updated security baseline in this blog. While security is an important topic (especially when web applications are involved) breaking applications due to raised security could result in the opposite.
In case you’re running JRE 7u51, please read this article with an update.
At the moment of writing there are two features that need to be disabled to enable the Java Applets of the Citrix NetScaler (as described by Barry Schiffer in this article):
- Disable Temporary Internet Files
- Lower Security
While this solves the problem (of not being able to administer a Citrix NetScaler) is potentially creates a new: the security level is lowered for the entire JRE. While Oracle was trying to increase the security for Java Applets with this update the opposite is achieved . Fortunately there is a way to lower the security for specific addresses
Disable Temporary Internet Files
As described earlier it is required to disable temporary internet files in Java. This can be done by opening the Java Control Panel, click on Settings and unchecking Keep temporary files on my computer
Disabling temporary internet files does not lower the security of the machine but will slow down the performance of Java (as its no longer caching files).
Barry described in his article that the following security features needs to be set:
- Mixed code (sandboxed vs trusted) security verification = Disable verification (default is Enable – show warning if needed )
- Perform certificate revocation checks on = Do not check (default is All certificates in the chain of trust)
In general, the certificates used to sign the JAR files of the Citrix NetScaler are no longer verified and the revocation is not checked, While this fixes the problem I’m having trouble to accept that I need to lower the security of the entire machine as it might compromise my computer due to the lowered security.
Deployment Rule Set
In Java 7 update 40 a new feature was introduced called “Deployment Rule Set”, designed to address the issue of security and compatibility in browser applets without affecting normal back-end Java programs (introduction article) aha!.
So apparently administrators can create a policy where they apply actions based on certain rules. Nice! Right? Well kind of, there are some pitfalls:
- Administrative access is required (the file is stored in C:\Windows\Sun\Java\Deployment);
- The configuration is stored in a JAR file, you need the Java SE Development Kit (JDK) for that;
- The JAR file needs to be signed with a certifcate that’s trusted by the client;
- Potentially (if you configure the file wrong) you deny all other Java Applets.
If you want to use the deployment rule set there are a number of steps that need to be followed.
1. Create self signed certificate
If you don’t have a certificate (with private key) that’s trusted by your client you can create a self signed certificate. This certificate is, by default, trusted by no one. It is meant for (local) testing purposes.
There are three activities involved, two of them use the keytool executable that’s part of the Java SE Development Kit (JDK).
a) Generate a keystore
keytool.exe -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048
b) Extract the certificate from the keystore
keytool.exe –exportcert –keystore keystore.jks –alias selfsigned –file SelfSigned.cer
c) Add to Java client
Open Java Control Panel, open tab Security and click on Manage Certificates. Select the Certificate Type Signer CA and import the certificate you exported in the previous activity (SelfSigned.cer).
2. Create a rule set
A rule set needs to be created where you configure which hosts (or applets) are allowed to run the Rich Internet Applications (RIA). The file ruleset.xml is a plain text XML file which consists of a number of rules. Each rule consists of:
- an identifier: to who does this rule apply;
- a certificate: to which applet does this rule apply;
- an action: what should be done if the rule applies;
- a message : An optional message that’s displayed when the RIA is blocked
Identification can be done based on a location (an URL), title or a certificate. These rules also have some pitfalls:
- Wildcards (asterisk) cannot be used for hostnames (that includes IP addresses). In other words, you need to specify the address of each Citrix NetScaler you need to administrator individually.
- Currently, only security hash algorithm SHA-256 is supported. The certificate of Citrix Systems Inc uses the signature algorithm SHA1withRSA, so this feature can’t be used. Fortunately the validity of the certificate ends soon (May 24 2014);
- All examples end with a “block” action. If you apply this rule set all RIA’s are blocked
The action that’s applied to the rule consists of a permission and a version. The permission is either run, block or default (where the default processing rule is applied). With the version identifier the version of the JRE that’s used to run the RIA. Since the 1.6 JRE did not include the certificate checks like certifcate revocation the applets of the Citrix NetScaler work when this version is used.
Here’s an example of the ruleset.xml I used
<ruleset version="1.0+"> <rule> <id location="http://10.0.0.1" /> <action permission="run" version="SECURE-1.6" /> </rule> <rule> <id location="http://10.0.0.2" /> <action permission="run" version="SECURE-1.6" /> </rule> <rule> <id location="http://NS01" /> <action permission="run" version="SECURE-1.6" /> </rule> <rule> <id location="http://NS02" /> <action permission="run" version="SECURE-1.6" /> </rule> <rule> <id /> <action permission="default"/> </rule> </ruleset>
In this example I allow Java to run the RIA using JRE version 1.6 on the hosts NS01 and NS02 using their hostsname and IP address. All other RIA’s that I run use the default processing rule (so it doesn’t change the default behavior).
3. Create JAR file
I would recommend storing the ruleset.xml file in the same folder as where jar.exe resides (in my example C:\Program Files\Java\jdk1.7.0_45\bin). Why? Because JAR uses the absolute path when you add files to a JAR file.
A JAR can be created using the jar executable that’s part of the Java SE Development Kit (JDK). A JAR file is an archive file (like ZIP) that contains one or more files. In this case a JAR file needs to be created that only contains the file ruleset.xml
jar -cvf DeploymentRuleSetUS.jar ruleset.xml
I created the JAR file DeploymentRulesetUS.jar because its unsigned.
4. Sign JAR file
The JAR file that’s created previously needs to be signed with a certificate. Keep in mind that the certificate needs to be trusted by JRE! A JAR file can be signed using the jarsigner executable that;s part of the Java SE Development Kit (JDK).
A JAR file with the name DeploymentRuleSet.jar is created using the unsigned DeploymentRuleSetUS.jar. In my example I’m using a self signed certificate.
jarsigner -keystore keystore.jks -storepass password -signedjar DeploymentRuleSet.jar DeploymentRuleSetUS.jar selfsigned
5. Copy the JAR file
The signed JAR file containing the rule set needs to be placed in the folder C:\Windows\Sun\Java\Deployment. Access to this folder requires administrative access to the system.
In the Java Control Panel you can verify if the rule set is detected and loaded correctly. This can be done by opening the Java Control Panel, open the tab Security and clicking on View the active Deployment Rule Set.
And you’re done