Java Plug-in 1.3 and RSA Signed Applets03/22/2001
Java's support of applets was one of the early factors that led to Java's immense popularity. However, Java applets have achieved less success over the last few years than was expected. There are a number of technical reasons for the failure of applets to live up to their early expectations:
- Larger applets took a long time to load and ran slowly.
- The language and API support provided by Navigator and Internet Explorer varied widely.
- The Java security support of the two browsers was nearly incompatible.
Fortunately, Sun worked hard over the years to address these shortcomings. There are now a number of reasons why applets are becoming a better solution for mobile code.
- The performance of the JVM has been improved. Classes load and execute much faster.
- JAR files enable all of an applet's classes to be retrieved with a single HTTP request.
- The Java plug-in provides an execution platform that is browser-independent, ensuring that applets execute in the same way no matter whether the user is running Navigator or Internet Explorer.
- The Swing API supports a common look-and-feel across windowing systems.
- The Java plug-in support for RSA signed applets and dynamic trust management simplifies the process of creating cross-browser trusted applets.
The above factors, combined with increased high-performance microprocessors and Internet connections, make applets a more appealing alternative to delivering executable content. In this column, I'll focus on the latest release of the Java plug-in (version 1.3) and its support for RSA signed applets and dynamic trust management.
The Java plug-in provides a way for users to run Sun's latest JVM and API within their browsers. The plug-in is run in place of the browser's native JVM and API classes.
For Java developers, the advantages of the plug-in are tremendous. The plug-in enables developers to write their applets for the latest version of Java. It is assured that their applets will work consistently and reliably with both older and newer browsers, whether they are from Microsoft or Netscape or whether they run on Windows, Linux, Solaris, or several other versions of Unix.
How does it work?
The Java plug-in works in generally the same way as other browser plug-ins, such as Flash and QuickTime. An HTML converter (available from Sun) converts
<applet> tags to the
<embed> tags used
to identify plug-in content to Internet Explorer and Navigator.
The plug-in appears to Internet Explorer as an ActiveX
control. When Internet Explorer encounters the
<object> tag of a converted HTML page (that
references the Java plug-in), it will check to see if the plug-in is
installed. If the plug-in is installed, Internet Explorer will load
and run the plug-in and use it to execute the applet referenced by the
<object> tag. If the plug-in is not installed,
Internet Explorer will download it from Sun and then install it (after
asking the user for permission to do so).
When used with Navigator, the plug-in takes advantage of
Navigator's plug-in API to simplify download and installation. The
first time that Navigator encounters an applet's
<embed> tag, it displays a missing plug-in icon to
the user. If the user clicks on the icon, Navigator walks the user
through the process of downloading and installing the plug-in. After
the plug-in is installed, it will execute any applets referenced by
The plug-in does not replace the browser's native JVM. The
browser's native JVM is still used to run applets that are referenced
<applet> tags. The plug-in is run in place of
the browser's native JVM when the browser encounters
<applet> tags that have been converted to
<embed> tags by
Sun's HTML converter. No conversion of the applet's Java code takes
place. The HTML converter only converts
tags within the HTML files that reference applets.
The plug-in and HTML converter are freely available from Sun.
Evolution of the Java Plug-In
The Java plug-in is not a new development. Plug-ins have existed for JDK versions 1.1 and 1.2. What's new and interesting about the Java plug-in 1.3 is its support for RSA signed applets and dynamic trust management.
Previous versions of Java plug-in supported DSA signed applets. The Digital Signature Algorithm (DSA) was developed by the U.S. National Institute of Standards and Technology (NIST) (see http://www.nist.gov). Even though DSA has been adopted as the standard for digital signatures within the U.S., the RSA algorithm is by far the most popular algorithm for digital signatures.
The RSA signature algorithm is a derivative of the RSA public-key encryption algorithm. RSA code signing certificates are supported in a uniform manner by both Navigator and Internet Explorer; DSA certificates are not. Prior to Java plug-in 1.3, a developer needed to obtain (and pay for) two code signing certificates -- one that was compatible with Navigator and one that was compatible with Internet Explorer. With Java plug-in 1.3, a single RSA code-signing certificate works with both Navigator and Internet Explorer.
Versions of Java plug-in prior to 1.3 required that the user's plug-in be statically configured to map sets of permissions to potential signers. This approach was cumbersome and difficult to manage. Java plug-in 1.3 provides support for dynamic trust management, which uses the browser's native certificate API and certification authority database to verify the certificates of code signers and to assign permissions to the signers. This is accomplished in a dynamic manner when signed JAR files are processed by the plug-in. Dynamic trust management eliminates the need to statically assign permissions to code signers.
Port scanner example
To show how the security features of Java plug-in 1.3 work and to illustrate their benefits, we'll develop a simple port scanner and then deploy it as a signed applet.
A port scanner is a program that checks to see if a TCP port is open. Internet servers, such as Web servers and mail servers, listen on TCP ports for connections from clients, such as Web browsers and mail programs. Web servers typically listen on port 80 and Simple Mail Transport Protocol (SMTP) servers usually listen on port 25. You can use a port scanner to tell whether a particular Internet host supports a TCP service on a particular port.
Security Implications of Port Scanners
Our port scanner will attempt to make a TCP connection to a specified host and port to determine whether the host is listening on that port. The default applet security policy prevents an applet from making TCP connections to hosts other than the one from which it is loaded. This means that our applet will need to be trusted to make connections to arbitrary hosts. This is accomplished by giving it an appropriate permission. In order to enable the applet to be eligible for this permission, we'll sign it using an RSA code signing certificate.
See It In Operation
Before we get into the details of the applet's implementation, you may want to see work. That way you'll have an idea of what to expect. The applet can be run from http://www.toolery.com/tools/portscanner/scan.jsp. You'll need version 4 or later of Internet Explorer or version 3 or later of Navigator to run the applet.
When you open up the applet's page, your browser will check to see if the Java plug-in version 1.3 is installed. If not, it will prompt you to install it. The Internet Explorer installation is a little smoother than the Navigator installation. Internet Explorer will pop-up a simple installation wizard, while Navigator waits until you click the plug-in icon before it initiates the installation process.
Once you've installed the plug-in, it will download and attempt to
run the SimpleScannerApplet from a JAR file named
scan.jar. When your browser encounters the JAR file's
signature, it will prompt you to determine whether or not you want to
trust the signed code. The plug-in will provide you with a prompt to
accept the signed applet. You can choose to accept it for the current
browser session, always, or never. If you don't accept the
certificate, the applet won't be able to perform sensitive operations,
like scanning other hosts. You can also click More Info to get more
information about the signer.
When you click the More Info button the following dialog is shown.
You can use the dialog to examine the contents of the signer's code signing certificate.
Assuming that you've accepted the certificate, the following applet will be displayed.
Enter a host name and port number and click the Scan button to see if the specified port is open on the host. For example, if you scan OnJava.com on port 80, you'll get the following output because ONJava's Web server listens on port 80.
However, if you scan OnJava.com on port 23, you'll get the following output. That's because port 23 (which is used for the telnet protocol) is closed on OnJava.com.
Note that the scanner reports the host's IP address in parentheses. Some hosts may have more than one IP address. These hosts can have some Internet services run on one IP address and other services run on the other addresses. If you want to scan a host using a specific IP address, enter the host's address in the Host name or IP address field. If a host does not have a name, you can just refer to it by one of its IP addresses.