Java Applets: Unsigned vs Self-Signed vs Signed

A Java Applet has, by default, many restrictions. It cannot:

  • open a socket connection to a server that is different from the web server that hosts the applet
  • access the user’s local filesystem
  • read certain system properties (e.g. user.home, java.home, …)

The reason for this is because an applet is started automatically by the web browser, not on the user’s own initiative, and therefore the user cannot take responsibility for the application’s behavior on their machine. By default the applet is called an untrusted applet (not started by the user’s own initiative), unsigned applet (the applet has not been signed by a certificate), sandbox applet (running in java’s security sandbox).

In order to eliminate these restrictions, it is possible to sign the applet using a certificate. There are two types of signed applets:

  • self-signed applets: signed by the developers themselves
  • signed applets: containing a signature that the browser should verify through a remotely running, independent certificate authority server (e.g. Thawte, Symantec, GoDaddy, …)

The applet is then called signed applet (the applet has been signed by a certificate). When the browser starts a signed applet, the applet will automatically request permission to run outside the security sandbox. And if the user grants permission, the applet becomes a trusted applet (the user takes responsibility), and can also be called a privileged applet (running outside the security sandbox).

Since the Java 6 Update 10 release (2008-10-15), unsigned applets can now make network connections to remote servers (servers that are different from the server that hosts the applet) using a special XML file called crossdomain.xml file. That file must be accessible on the server that the applet is trying to connect to.

Security warning dialog boxes

Unsigned applets

Since Java 7 Update 11 release (2013-01-13), the user is now always warned and asked permission to run unsigned applets (before that release, a warning dialog would only appear for signed applets). The user is prompted by a warning dialog that requires him to check a checkbox only if he accepts the risks posed by running the applet.

Also, since Java Update 21 release (2013-04-16), the warning dialog stresses furthermore (in red and bold) that running the application may be a security risk. Oracle now states on its website “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. […] self-signing is primarily of value to developer and intranet applications as it also requires managing the keystore for Java”.

unsigned applet - new warning dialog
from Java 7 Update 21 Release
unsigned applet - warning dialog
from Java 7 Update 11 Release

Note that the dialog above also warns you that your Java is insecure if you don’t have the latest update of Java. An additional button labelled “Update” is then added to dialog forwarding the user to Oracle’s Java Download page.

Self-signed applets

self-signed applet - new warning dialog
from Java 7 Update 21 Release

Note that the option that allows the user to avoid showing the warning dialog again, is hidden until you click on “Show Options”.

self-signed applet - warning dialog
from Java 7 Update 11 Release

Signed applets

signed applet with a trusted certificate
signed applet with a trusted certificate (as of Java Update 21 release)

Conclusion

Oracle, because of their recent security concerns, is dissuading the end users from running an unsigned or self-signed applet by making these warning dialogs “scarier” over the releases and by increasing the default Java security level.
From now on all your applets should be signed by a trusted SSL provider.

Don’t hesitate to comment for any updates that I might miss!

Further reading: http://threatpost.com/javas-losing-security-legacy

11 Replies to “Java Applets: Unsigned vs Self-Signed vs Signed”

  1. Hi, thanks for you article.

    I’m wonder if we can continue using self-signed applets on Intranet in companies. Java version have now expiration date (V. 7u45 for example !).

    What is your opinion on that ? Are certificated a way that MUST be used, even for Intranet websites ?

    1. I’ve forgotten :
      – a self-signed applet doesn’t start if Java Version is obsolete (I don’t know is a certified applet does)
      – a self-signed applet remembers very often to the user that it’s risky to use it (with the warning message).
      – Java message indicate that these applets will be blocked in a future version.

      So, is it a mandatory way to pay certificate for applet ?

  2. so this means that even if we sign our applet with a trusted CA certificate, even then the pop ups will appear???
    is there no way to permanently prevent these popups?

  3. I’ve bought a certificate. The popup appears only one time if you check a checkbox (this data is saved in the system, which avoid showing the popup even on another browser).

    Another advantage : the applet can be executed even if Java version is obsolete.

    But it is an expensive way !

Post a Comment