Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Java security evolution and concepts, Part 5

J2SE 1.4 offers numerous improvements to Java security

By Raghavan N. Srinivas, JavaWorld.com, 12/21/01

Page 2 of 6

Next, strong cipher support is available via JCE and JSSE, albeit with some important control restrictions. In JCE, the cryptographic strengths are limited through the jurisdiction files by default. JSSE, for its part, now restricts the replacement of the default SSLSocketFactory and SSLServerSocketFactory classes.

Moreover, you'll find support for dynamic policies. Prior to J2SE 1.4, the security policy was associated at the time of class loading. In 1.4, the security policy association is deferred until the security check becomes necessary.

In addition, J2SE 1.4 includes some changes to the functionality of the security classes. As an example, the javax.security.cert class is available only for backward compatibility, with its functionality carried forward by the java.security.cert class. Newer applications should use this class.

Finally, applet security as enforced by 1.4 is different, which we'll look into in the next section.

Java Plug-in enhancements

You'll see some changes in security between the J2SE 1.3 Java Plug-in and the 1.4 Java Plug-in (for more, see Sidebar 1: Java Plug-in Primer). Since we are interested in security, I explore the changes by revisiting the signed applets developed in Part 3.

Security in the J2SE 1.3 Java Plug-in

To illustrate how the J2SE 1.3 Plug-in handles applet security, let's first look at the writeFile applet from Part 3 of this series. Execute the writeFile signed applet under the J2SE 1.3 Java Plug-in. Make sure that the policy files do not allow the temp file (/tmp/foo on Unix systems and c:\tmpfoo on Windows) to be modified. If the clock on your system is set correctly, the signed applet's signature should not validate because it has expired; therefore, the applet will not initialize. If you set your system's clock back to a date between December 13, 2000 and December 21, 2001 (that is, to a time when the certificate is valid), the signature validates, and you should see a dialog box asking whether the applet should run or not.

As another example, run the signed applet discussed in "JDK 1.2 -- Signed Applet Example" under the J2SE 1.3 Java Plug-in. The applet has been signed by a key -- Duke -- whose public key has been self-certified. That means the Certification Authority (CA) used to sign the certificate is not trusted by default in the environment. As a result, the signature validation fails again, and the dialog box again fails to pop up.

Security in the J2SE 1.4 Java Plug-in

Now, let's run the same applet examples under the J2SE 1.4 Java Plug-in.

When executing the example from Part 3, the signed applet with the expired certificate, the user sees a dialog box clearly indicating that the certificate is expired, as shown in Figure 1. Here, the ultimate decision to execute the applet is left to the user's discretion.

Figure 1. Signed applet with an expired certificate

Likewise, in the second example of the signed applet with the untrusted certificate, the user sees a dialog box, this time indicating that the CA cannot be trusted. The applet can still be executed if the user so chooses, as seen in Figure 2.