This article focuses primarily on the specification of Java applet security within Notes. However, because Java itself is still not well-understood, I'll cover the following topics:
- The design of Java for secure application delivery
- Running Java within a secure environment
- Establishing trust
- Onward to mission-critical applications
"Java™ is a secure programming language." You have probably read that statement in the trade journals or maybe within an Internet discussion. There are three questions that you should be asking yourself before you reach for the magic bullet:
- "What makes a language qualify as secure?"
- "Is it really true that Java is secure?"
- ". . . Secure to do what?"
Java was designed originally by Sun Microsystems in the early 1990s for the coming world of personal digital assistants (PDA's) and small consumer electronic devices communicating across networks. When it became apparent that the Internet would fuel demand for small, modular, object-oriented services, Java's first implementation was tightly targeted to this purpose.
Significantly, Java is the only programming language released expressly for network development and delivery.
Syntactically and semantically, Java is similar to C++ (though without pointers and with an elegant interface mechanism in the place of multiple inheritance) with minor contributions from Smalltalk (automatic garbage collection and run-time type checking), augmented by a rich threading mechanism and, of course, security features.
While C++ programmers will do well to unlearn some inbred habits and think afresh in Java, C++ and Java must be considered first cousins. Unfortunately, since few production Java applications exist, the claim of its proponents that Java is an easy language to learn and program remains promising but unproven.
Java, like any full-blown programming language can be used to write entire applications. However, in the Internet style, Java stakes out its turf as the tool of choice for writing small, self-contained components, termed "applets". An applet is a mini-application that executes within a browser. Applets are invoked by a small set of new HTML tags that pass appropriate parameters.
While applets can be loaded from a floppy disk or CD-ROM, Internet applets not already detected as resident locally are downloaded automatically to your machine over a network using TCP/IP. Upon download completion, the applet executes. When I make statements about Java security in the remainder of this article, it is Java applets that are in view, not Java applications.
Considering the functional weakness and low availability of useful Java applets today, Java's raging popularity is either a sign of its innovative design or the wishful thinking of programmers. The industry is betting heavily on the former. In fact, though Java is still in its infancy, early implementation is demonstrating its portability, interoperability, safety, and security potential.
Portability and interoperability ensure that a Java program written and compiled on one operating system will run on another operating system supporting Java without source code modifications (portability) or recompilation (interoperability). This is possible because all Java implementations are required by the design to support the same class library specification.
Also, Java compiles to a single pseudo-code model which is then interpreted by each operating system as needed. There is a negative performance hit, but the cross-platform benefits outweigh the disadvantage, and just-in-time Java compiler technology is advancing rapidly.
Like any programming language, Java's safety is relative. However, its creators have made it more difficult for Java, compared to C++, to inadvertently crash your system by removing features deemed "unsafe". These include direct access to memory locations (pointer arithmetic) and programmer-directed destruction of objects.
A common and often difficult to diagnose bug in C++ programs is overwriting of memory with "garbage," such as writing data past the end of an array. In Java, this problem is eliminated because all objects contain runtime type information and perform runtime type checking, so it is impossible to modify the eleventh element of a ten element array. This would generate a Java runtime error rather than a C++ crash.
Please note that I do not want to leave you with the impression that Java programs never crash. In general, though, crashes are due to bugs in the Java implementation, not in bugs in the Java program itself. Diligent programmers can throw the appropriate exceptions to enable Java programs to execute with reasonable grace and diagnostic messages.
For Java to qualify as an Internet-friendly language, we must be able to execute Java applets within a secure environment. After all, unlike classical word processing or spreadsheet applications, Internet-delivered Java applets lack a familiar and trusted brand label. We have to be certain that the distributor of the applet is "who they say they are" and that the applet, once delivered, will do what it is warranted to do on our system and nothing more.
Since the Internet does not magically prevent potential interception and manipulation of bytes during the transmission process, the problem of guaranteeing integrity can become quite complex.
Consequently, I am using the word secure here to describe a user's ability to gain protection from a malicious program. Many parallel but different projects are underway to build secure infrastructures with respect to Internet transmissions (firewalls, for instance), browsers (SSL), electronic commerce (SET) and more. Ultimately, Java security will take its place within overlapping and interpenetrating layers of other security systems (including Notes, of course).
Indeed, no programming language is secure per se, but must rely on programmers to make full use of provided security mechanisms.
Java's designers did have security in mind from the beginning, sometimes in subtle ways. For instance, the elimination of pointers prevents pointer forging during execution, enhancing security inherently.
Java also provides other security mechanisms inherent to the language. When an applet "comes over the net," Java automatically checks the program bytes to ensure that the applet conforms to the rules for a valid Java program. This precludes a Java applet from accessing data members and objects that are marked as "private". Even though a Java compiler would never generate the byte codes to perform this operation, a malicious programmer could "hand compile" these byte codes. Java's built-in byte code verifier would prevent the applet from ever executing the harmful code.
Where Java shines is by offering an embedding environment (such as Lotus Notes) great control over the security of a running Java applet. Notes takes advantage of methods within the Java class java.lang.SecurityManager to implement its security policy. For example, the java.lang.SecurityManager class includes a method named checkRead that is called whenever an applet attempts to read a file from disk. The security policy either allows the read to proceed or prevents the read by throwing a security exception.
By default, Notes implements the same strict security policy employed by other browsers, such as Netscape Navigator™ 3.0, over the Internet. Applets cannot access any files on your local disk. This includes reading from files, writing to files, deleting files, or even checking for a file's existence. Applets cannot load and run dynamic libraries (DLLs). They cannot obtain various attributes such as the client's user name, computer name or IP address.
Additionally, a Java applet can only communicate with the host machine where the applet originated, using Java's network API. This prevents information thefts by an applet external to your company's firewall reading some information from a machine inside your network and then retransmitting it outside your firewall.
While Java's security potential is unquestioned, its security today depends, ironically, on reducing its functionality to a point which renders it useless for many mission-critical applications. This is why support for Java within Notes itself and the ability to selectively permit Java applets greater access to corporate data is critical to enabling Java to take the needed jump required to make a promising language a useful language.
Notes 4.5 and the newly announced Domino products enable Java applets to execute directly within the Notes client environment. Developers can take advantage of Notes' features to ease applet development (for instance, cut-and-paste of Java applets into mail messages). Future versions will make Domino's object store, security, messaging and other application services directly available to Java applications.
The maturity of Notes makes it possible to extend the default Java security restrictions necessary to the Internet with a more flexible model suited to Intranet environments through the definition of trusted hosts.
While the default security policy pursued by Notes and other browsers is the only sensible approach for running applets downloaded from random Web pages on the Internet (the very definition of "untrusted"), this proves frustrating in a more trusted environment such as an Intranet.
For example, within a trusted Intranet, we might design an application that retrieves various data feeds from multiple computers, invoking a Java applet that reads and interprets these data feeds on a client machine. To accomplish this, the Java applet must be permitted to communicate with machines other than the applet's originating host.
Using Notes, we can configure the browser to allow applets written for an Intranet to have more "rights" than those delivered across the Internet. Under the "Java Applet Security" section in the location record of the Notes client (editable by choosing the menu item "File->Mobile->Edit Current Location"), we can control the level of network access granted to applets originating from "untrusted" or, it may be, "trusted" hosts.
For applets originating from untrusted hosts, the only right granted will be "allow access only to originating host". This corresponds exactly to the "very strict" security policy that has already been described.
Administrators can define greater freedom for applets communicating with trusted hosts to either "allow access to any trusted host" or to "allow access to any host". Trusted hosts can be specified with explicit host names (or IP addresses), or with wildcards ("*.mycompany.com" or "205.159.212.*").
The Java applet security section in Notes' location record contains one additional boolean valued field: "Trust HTTP Proxy". The default value for this field is "NO". This field comes into play if you are using an HTTP proxy to access Java applets (that is, have specified an HTTP proxy in the Web proxy field in the location record).
Assume, for example, an applet has been downloaded from the host "www.lotus.com" and assigned the following network rights: "Allow access only to originating host".
If the client is located on the Internet, Java's networking layer will resolve "www.lotus.com" to its IP address (126.96.36.199) and perform all network connections with the host at IP address 188.8.131.52. If the applet that originated from 184.108.40.206 attempts to connect to a host at any other IP address, the connection will fail with a security exception.
If the client is using an HTTP proxy inside a firewall, however, and the DNS name resolver is unable to resolve www.lotus.com to its IP address (due perhaps to a missing or incomplete name table), Java is forced to perform network communications by name (www.lotus.com) rather than by IP address (220.127.116.11). This is acceptable assuming that the HTTP proxy in use is authentic.
If the proxy is a rogue intent on mischief or if the HTTP proxy is using a rogue DNS name resolver, it is possible for two machines to communicate without Java realizing it and throwing the mandated security exception. For example, if the proxy sends network traffic for www.lotus.com variously to 18.104.22.168 and another computer (in this case, run by someone trying to steal data), then Java can inadvertently transmit data to the thief, circumventing the "allow access only to originating host" policy.
Therefore, an administrator should set the "Trust HTTP Proxy" field to "YES" only in conditions of high confidence in the proxy. While the foregoing might appear alarming, a proxy known to be trustworthy makes it far easier to surf the Internet from within a firewall, where your DNS name resolver cannot necessarily resolve every name.
If "Trust HTTP Proxy" is disabled, security exceptions will arise when attempting to run applets on hosts where a hostname cannot be resolved locally to the applet's host IP address. As a workaround, the applet can be run by specifying the IP address within the URL (for instance, http://22.214.171.124/applets/... rather than a name).
Admittedly, even the Notes mechanism for granting applets additional rights is not an ideal long-term security solution. While this mechanism goes a long way to reducing the danger of an applet wreaking havoc upon your system, it does not guarantee that all actions will be conducted with appropriate security.
Future versions of Java, probably available within the coming year, will support digital signatures for individual applets and take us much closer to the goal.
As a variety of security solutions become available over time, not only for Java but for Internet/Intranet applications broadly, programmers will be able to host progressively more critical applications safely over the network.
Meanwhile, however, Lotus Notes users on Intranets have the security needed to build complex Java applets. This is important not only with respect to building useful Java applications but with enabling your organization to justify the development of needed Java skills today. After all, unless applets can perform meaningful actions, there is little economic justification in building those skills.
One final note: always remember that security is only as secure as its weakest link. This has always been true and will remain true into the indefinite future. Ironically, in the fuss over Java security, we forget that corporations are foolishly executing mission-critical C and C++ applications today over their networks as though they are secure when, in fact, they are porous at many points to intrusion from outside.
Notes provides many security mechanisms (certificates, signed documents, access control lists, Java trusted hosts, etc.). Unless used with care, you, the user (whether administrator or programmer) will always be the weakest link.
When it comes to defining trusted hosts, security cannot rise any higher than the knowledge and expertise of a given administrator. Put positively, Notes administrators who understand their systems have latitude today to enable powerful, reasonably secure, Java-based applications. Notes is ready to host Java applets that can perform real work. Used wisely, you can gain the jump on competitors with exciting applications that merge the best of Notes with the best of Java.
1997 Iris Associates, Inc. All rights reserved.
Jeff Eisen joined Iris in July of 1995 to lead the effort of embedding Java applets into the Notes client. In fact, see our interview with Jeff and an article Jeff wrote to learn more about his work with Java applets. Before joining Iris, Jeff worked at Lotus where he focused on the platform-dependent layer of LotusScript. For R5, Jeff was responsible for the Notes browser as well as many other internet and MIME issues including the international work forming the basis for this article.