A Brief History of Applet Security

Alex — Wed, 10 Oct 2007 20:23:00 GMT

A vast amount of server-side development is J2EE. Huge, multi-national corporations run on it exclusively. But, it wasn't always that way….

Back in the early days of Java, the client-side Applet was king. The partnership with Netscape thrust the Java onto the world stage. Early press releases all focused on the web experience provided by Applets.

But there was this pesky security issue - due to the fact that Java Applets are distributed and run through a browser, they can encounter some nasty code on the web. In order to deal with evil code, Applets are run in a Sandbox with limited permission. However, Applet developers said that this Sandbox was too restrictive. No access to the file system, or the clipboard, or native code, or really anything useful.

So, in Java 1.1, you could digitally sign applets so that they were trusted. This would give the Applet full permission, and theoretically users would manage their own trusted key store.

In Java 2, Sun added Certificate Authorities to the Applet specification, so that anyone with enough money to pony up could create a universally trusted Applet. This was tempered by the fact that now the user could create a policy to restrict these signed Applets to a specific set of permissions. So signed Applets ask for permission to run, and are granted AllPermissions, unless there is a specific client-side policy for that Applet, which takes precedence. But no one likes configuring security policies, do they? Remember, this is the unwashed masses of browser users, and they don't know a Java policy file from a can of Shinola.

Enter the Java Plugin, which now handles Applets for most browsers. In the previous 1.3 version of the Plugin, Applets signed with invalid certificates (self-signed or expired) would simply fail to load. If the signing certificate was valid, the user got a dialog box asking whether to run the Applet.

In the Java Plugin 1.4, the behavior was changed to load Applets even with invalid certificates. The only difference between Applets with valid signatures and invalid signatures is the warning messages.

Applets signed with an invalid certificate:

Applets signed with a valid certificate:

To me, this represents a tremendous over-simplification. Signed Applets now basically use the same, all-or-nothing security model as standard executables!

The error message for an unsigned .exe file (in IE7):

At least this has a red shield (bad) rather than an orange shield (maybe bad)!

Nowadays, in addition to the huge amount of server-side Java development, there is Java on mobile devices, smart cards, and entire operating systems in Java. But the original thing that made Java tick – the Applet – is becoming less and less relevant every day, and I can't help thinking it's due to the fatally flawed security model which has now almost completely lost its teeth.

References

Java Technology: The Early Years: http://java.sun.com/features/1998/05/birthday.html

Java 2 Platform Security: http://www.informit.com/articles/article.aspx?p=433382&seqNum=2

Using JDK 1.1 Signed Applets with Java Plugin: http://java.sun.com/products/plugin/1.2/docs/signed.html

Java Security, Evolution and Concepts: http://java.sun.com/products/plugin/1.2/docs/signed.html

KeepItLocked.net : Applets, Software Security

A Brief History of Applet Security