Security in Java based Distributed Internet Applications

3.2 Bytecode Verifier

3.3 Security Manager

4.1 Malicious applets

4.2 Spoofing attacks

4.3 Decompilation attacks

6.1 Java Remote Method Invocation

6.2 Java Servlets

6.3 Java and CORBA

6.4 Firewall considerations

6.5 Java and SSL

7.1 New security features of JDK 1.2

7.2 Policy based security model

Nowadays the Internet and especially World Wide Web offers an excellent medium for providing both home and enterprise users with various networked applications. The possibilities for world wide distributed applications are finally emerging, but so far the utilization of these possibilities has remained quite low. One of the main reasons for this has been the mostly static content of World Wide Web and the lack of secure, platform independent programs in the Internet like heterogeneous hardware and software environments. Java promises to offer solutions for both these problems - programs that are both secure and platform and operating system independent, and which can easily be distributed via the Internet. This paper aims to provide a general overview of the security of Java in distributed application environments, especially the Internet.

Java is a platform independent, high-level object-oriented, interpreted language that is designed for networked heterogeneous computing environments. Java offers good support for both object-oriented programming paradigms and networked applications. Distributed applications can take advantage of an extensive library of routines for coping easily with TCP/IP family protocols like HTTP and FTP. This makes creating network connections much easier than in C or C++ and the capability for easy multithreading can be used for handling different sessions. The standard Java development environment containing a large, standard class library is offered by Sun and is called the Java Development Kit (JDK).

Java achieves its portability by compiling programs from source code to platform independent bytecode, which is then interpreted in the runtime environment by the Java virtual machine (JVM), which creates a virtual machine that remains constant across runtime systems. Bytecode makes Java programs portable and platform independent, but is still much more efficient to execute than traditional interpreted languages. With Just In Time (JIT) compiler and dynamic execution optimization technology Java programs are gaining platform specific compiled programs in performance.

Java programs come in two flavors - applications and applets. Java applications are similar to traditional compiled programs in a sense that in JDK 1.0 and 1.1 they don't have any security restrictions and are thus capable of using all the resources on the run-time platform. JDK 1.2 provides an additional security model for Java applications, which is discussed in more detail in chapter 7.2. Java applets are usually small Java programs embedded into web pages that are downloaded from web servers and executed in web browsers. Because applets can be downloaded from many sources, some of which may not be safe, they are subject to strict security checking and can use only a subset of available resources in the run-time environment. Java bytecode is designed so that it is possible to check the security and validity of the bytecode instructions, but it is generally impossible to analyze the security of a set of platform specific machine language instructions. In addition to Java bytecode design, the structure and syntax of the Java language offer a good basis for security, avoiding some weaknesses of more traditional programming languages. Some features of the Java language that have impact on security are [21]:

• Strong type safety for casts and method calls; class and type casts along with method calls are always checked for validity and thus safe in Java.
• No pointers; Java doesn't allow the programmer to write directly in memory thus avoiding potential program memory corruption by defective programs.
• Array index checking; Java language automatically checks all array references for valid indexes inside array bounds thus making it impossible to overflow buffers and to corrupt the heap.
• Automatic memory management i.e. garbage collection; Java provides automatic memory management thus freeing the programmer from the burden of managing memory manually.

Java applets are subject to strict security checking, because they can be downloaded from potentially malicious web sites. Otherwise they could corrupt files, or access private information on the user's computer and send it back to the web site. Thus applets are executed with minimal rights on the user's computer, but they can still offer a rich set of functionality. Normally applets that are downloaded from web sites are untrusted, and are executed in the so-called sandbox, which is a separate dedicated area in a browser for running Java applets. The sandbox has the following restrictions on program functionality [8, 21]:

• No file access; applets don't have any rights to access files on the user's computer.
• No external program execution; applets can't run any other programs that exist on the user's computer.
• No native method calls; applets can't execute any platform dependent native calls nor can they load program libraries.
• Limited network access; applets can only connect to the web site where they originated. Applets can't create listening sockets that could accept network connections from elsewhere.
• Limited access to system properties; applets have only limited access to system specific properties on the user's computer.
• No exit for Java Virtual Machine; applets can't terminate the Java VM under which they are run.
• No printing is allowed from applets; applet can't access external hardware resources such as printers.
• Identified popup windows; applets can create popup windows, but these windows are identified as applet windows by a separate status line. Otherwise a malicious applet could create a popup window that would emulate some system specific window and could thus fool the user to reveal some confidential information, which could then be sent to the web site from which the applet originated, for further use by the attacker.

Despite being limited by these restrictions, applet can still provide rich set of functionality working as clients for distributed applications, where the server part resides on the same machine as the web server from which the applet was downloaded. Applets are most often used in order to provide a visual user interface for distributed applications and thus don't require so much low-level resource access on the user's computer. JDK 1.1 provided a way to overcome these restrictions with the help of digital signatures, which are discussed in more detail in chapter 5. The standard sandbox protects the system from many basic attacks by malicious applets. For example, it will [8]:

• prevent damage to the run-time system caused by updating files or running system commands.
• prevent the uninvited retrieval of data by reading files or extracting environment information.
• prevent the browser machine from being used as a platform to attack other machines.
• prevent the trusted build-in and local classes on the browser from being overridden or corrupted.

The sandbox restrictions are forced by the so-called SecurityManager class, which is used by the basic JDK classes in order to determine whether a requested operation is allowed. Including the SecurityManager class, the Java applet security builds on three fundamental aspects of the Java run-time environment: the ClassLoader, the Bytecode Verifier and the SecurityManager, the relationship of which is shown in figure 2. These three components are described in more detail in the following three chapters.

The ClassLoader is the first component that performs some form of applet checking. It determines how and when applets can load code and ensures that applets do not replace system-level components within the run-time environment. It also separates the classes it loads to avoid potential attacks: local classes are separated from remote classes and classes from different applets are separated from each other [23]. The search order when a new class is encountered is then the following [8]:

• Trusted core classes from java.* packages, which provide basic services for networking and graphical user interface implementations. These classes can not be redefined by applets, because a malicious applet could undermine the whole Java VM's security model by redefining, for example, the SecurityManager class. Core classes are usually part of the browser, if the browser has Java support.
• Local classes that can be found based on the host's classpath environment variable. Java capable browsers include as a rule the class packages that are part of the JDK, but the user can also make other classes available for the web browser by copying them to a directory that is part of the classpath environment variable. These classes are assumed to be safe and are treated like trusted core classes in some cases.
• Classes loaded from the web server i.e. classes that are part of the applet. These classes are always untrusted when not signed and are submitted to the Bytecode Verifier for checking.

The ClassLoader class instance is provided by the web browser implementation and it can not be changed by the applet in order to circumvent the normal loading order for classes.

The Bytecode Verifier is the second component in the applet security checking chain. After an untrusted class is loaded via a ClassLoader instance, the class file is handed over to the Bytecode Verifier, which attempts to ensure that the class is fit to be run by analyzing the code in the class file statically. The purpose of the Bytecode Verifier is to make as many checks as possible before runtime to improve the performance of the runtime execution of the class. The Bytecode Verifier checks the class file in four passes [8]:

• File Integrity Check: File integrity check is the first pass of the Bytecode Verifier. It checks that the class file has proper format, correct class file signature (0xCAFEBABE) and that each of the structures inside the class file is of the appropriate length.
• Class Integrity Check: Class integrity check is the second pass of the Bytecode Verifier. It checks the class file superficially without examining the actual bytecode instructions. The second pass ensures that the class has a superclass unless the class is the Object class, that the superclass is not a final class so that it can be inherited and that this class doesn't attempt to override a final method in its superclass. Integrity check also verifies that constant pool entries are well formed and that all methods and field references have legal names and signatures.
• Bytecode Integrity Check: Bytecode integrity check is the third and most complex pass of the Bytecode Verifier. It checks individual bytecodes in order to determine how the code will actually behave at runtime. This includes data-flow analysis, stack checking and static type checking for method arguments and bytecode operands. These checks ensure that bytecodes have the correct number and type of operands, that datatypes are not accessed illegally, that the stack won't underflow or overflow and that methods are called with appropriate parameter types.
• Runtime Integrity Check: Runtime integrity check is the fourth and final pass of the Bytecode Verifier. Runtime integrity checking is launched at runtime when required. For example, if a method is returning a class that is assigned to a superclass of the return class, the validity of this assignment is performed by the fourth pass of the Bytecode Verifier at the runtime when the returned subclass is loaded by the classloader to check that it actually is a subclass of the assigned class. Otherwise Bytecode Verifier would have to load the class even if the method call would never be performed thus causing a possible performance hit.

After these four passes it should be nearly impossible for the class file to forge illegal pointers, contain illegal bytecode instructions, contain illegal parameters for bytecode instructions, overflow or underflow the program stack, perform illegal casting or attempt to access classes, fields or methods illegally [23]. However, it is impossible from static analysis of code alone to determine whether the class file complies with these requirements. This applies especially to checking perfectly for stack overflows and underflows, which is impossible in both theory and practice.

The Security Manager is the last link in the applet security checking chain. It is active at runtime and initiates run-time access controls on attempts to perform file and network I/O, create new ClassLoaders, manipulate threads or thread groups, start processes on the underlying platform, terminate the Java Virtual Machine, load non-Java libraries (native code) into the Java VM, and load certain types of classes into the Java VM. The Security Manager is thus responsible for enforcing the applet sandbox restrictions. Various classes in the JDK for file, network and system properties access call special access verification methods of the SecurityManager class when applets are run in the Java VM. By default there is no instance of the SecurityManager class in JDK 1.0 and 1.1 for stand-alone Java programs, because they can't load classes from untrusted sources, but JDK 1.2 will provide an implementation of the SecurityManager class that can be used also with Java applications. [23]

Despite the rigorous checking of applets it is still possible to envision potential attacks towards Java applets and their users. Most attacks against distributed applications are made possible by the lack of either proper authentication or integrity checking. Authentication means reliable identification of something. When using distributed applications both the user and the server should authenticate themselves, otherwise the so-called spoofing attacks are made possible. Integrity i.e. verifying that something is unaltered is also important. Integrity applies to both the client part (Java classes) of the distributed application and also to the communication messages, which are transmitted between client and server. Integrity, together with authentication protects the distributed application from the so-called man-in-the-middle attacks, in which the attacker is capable of listening to the network traffic and making changes to communication messages. Usually confidentiality, i.e. protecting the information from disclosure with encryption and other means, is also an important factor in distributed applications. For example, in electronic commerce the client usually communicates also with the server and transmits sensitive information like credit card numbers etc. These three concepts for security - authentication, integrity and confidentiality are in no way Java specific and are important in every secure system. They are discussed in much more detail in [19].

Of the Java specific threats, malicious applets have received most of the attention. Along with these Trojan horse and spoofing attacks have been the most common Java security threats publicized to date [6]. Most of the more serious attacks have been made possible by defects in the Java implementations rather than by fundamental design flaws in the Java security model and that is why it has so far been relatively easy to provide fixes for these problems. The following three chapters address these threats in more detail.

Most of the Java applet sandbox restrictions are oriented towards protecting the user's workstation and resources from potentially malicious applets. It is however possible to make intentionally hostile applets, because actual computation resources are not protected. This makes it possible to write hostile applets that can be used to break encryption or factor large prime numbers in order to use the computing resources of the user's machine for attacking other computers. Current browsers don't show any visible status symbols that would indicate that the client is running an invisible applet in a background thread. If the hostile applet uses very low priority and has no visible windows, then it is very likely that it can use the computing resources on a client computer without the user even being aware that he or she is running an encryption breaker. If the applet implements Java's Runnable -interface with a dummy stop method, it can remain resident in the browser's Java VM until the browser software is terminated.

A completely different approach is to make a hostile applet visible, but as annoying as possible. Because applet can control the priority of its threads, it can raise its priority so that it may be very difficult to kill it on systems that don't provide good pre-emptive multitasking. Even untrusted applets can take advantage of the audio resources of the system with the help of sun.audio package. This makes it possible to write annoying applets that could produce well-known notification sounds on indeterminate intervals or just start playing loud random noises from the speakers. To produce as annoying an applet as possible one could write an applet, that would raise its priority to maximum, play random noises from speakers, do heavy computation, popup full screen windows on top of each other successively obscuring the whole desktop. This would quickly render the whole workstation unusable until the Java VM in the browser has been terminated, which usually requires that the browser software is also terminated. If the web server from which the applet was downloaded has an SMTP server, the applet can also be used to send annoying e-mail. If the annoying application activates immediately upon download, it is easy to determine its origin, but if the annoying behavior is delayed by a nondeterministic delay long enough so that the user has had a chance to visit several web pages, the origin of the applet may no longer be easy to ascertain.

Most of the more serious hostile applets take advantage of security holes in the Java VMs of web browsers. Both Netscape Navigator and Internet Explorer have some version specific security holes that make it possible, for example, to crash the browser and also cause more serious damage. Examples of annoying applets and applets that take advantage of security wholes in specific versions of certain browsers can be found from [7, 18]. Of course, if the hostile applet is signed, it can make much more damage such as deleting files or distributing virus-like code to executables or other Java class files, but in that case the author of the Trojan horse is identified immediately. Signed applets also warn the user with a specific dialog window whenever the signed applet requests more privileges as shown in picture 1.

One of the attacks that distributed applications are subject to is spoofing attacks against web sites. Instead of connecting to the web site, the attacker fools the applet into contacting the attacker's web site, which is used in some form of attack. Example of this would be when a user is fooled to think that he is connecting to a bank's web site, but instead the applet that works as an user interface will send his password to the attacker, who may then use it to withdraw money from the victim's account. These types of attacks can be achieved, if the attacker has access to some router on the route from the user to the bank, or if the attacker can successfully take advantage of ICMP redirect or IP source route functions and use them to confuse the user's workstation. Spoofing attacks regarding legitimate web sites are made easier by the fact that the attacker can easily duplicate the web pages of the legitimate site beforehand by downloading and copying them. The attacker would then proceed by creating a server application that will communicate with the client. This fake server would store the client's user id and password for later use, and normally return a standard error message indicating, for example, that the server is under maintenance and will be available only after some time. After this the attacker would use the identification information by connecting to the legitimate web site and after successful identification the attacker would impersonate the original user and transfer money from his accounts.

One way to carry out a spoofing attack is to hack a legitimate web site and to replace the original server or client part of the application with a modified version that would in addition to normal behavior also collect information about the user or system that would enable the attacker to take advantage of system resources that he couldn't normally use. If the attacker has access to the user's workstation, he could also try to replace some local classes on the user's workstation, which are normally thought as trusted. These local classes could, for example, store user id and password information, which to attacker would retrieve later on.

There are several ways, however, that can be used to protect the system from these spoofing attacks. The most basic one of these is to use authentication in order to ensure that the server, to which the client is connected, is legitimate. Using Secure Socket Layer (SSL) is one solution for providing authentication for distributed Internet applications and also for providing encrypted communication traffic. Companies are usually also protected with firewalls, which can be used to stop unwanted ICMP packets. Since JDK 1.1 Java has also provided means for signing applets digitally, which protects the user from hacked applications. If the client part is small and can always be downloaded from the server in real-time, then the possibility of corrupted local classes can be reduced by using a so-called guardian applet, which checks for corrupted local classes before proceeding to load the main applet. Applets in distributed applications should never store any sensitive information in the browser's cache or on the local file system unencrypted. One way to further reduce the risk of passwords falling into wrong hands is the use of one-time passwords. This has the advantage that the password can only be used once and has no value for a potential attacker later. One-time passwords are normally distributed as lists on paper or they are generated with a special electronic calculator like ActivCard.

So far this paper has been about the user's security, but it is also interesting to note what Java provides for securing a developer's implementation and the so-called intellectual property. Modern compiler technology makes it virtually impossible to recover, for example, C source code from the binary executable with decompilation, but it is almost trivial to obtain the assembly language code of the program with a proper disassembler [8]. In a similar way it is quite easy to convert Java bytecode from Java class files back to Java source code. The reason for this is the general and well-defined format of the Java bytecode. Advanced Java decompilers like Mocha and JAD are able to recover complete Java source code with all function and variable names identical to original source code, the only information missing after decompilation is comments. Because applets are downloaded from the web server, developers are in effect distributing their source code and thus potentially valuable intellectual property directly to users. Reasons for decompiling Java class files may include, for example, the recovery of valuable algorithm or discovery of how a particular security feature is implemented, which is yet another proof that one should never have the security of the system depending on proprietary implementation rather that relying on well researched and published algorithms.

Methods for protecting intellectual property from decompilation include shrouding or obfuscating the source code. This means replacing descriptive variable and function names with random strings and trying to reorganize source code so that it would be more difficult to follow the logic flow of the program. Some utilities try to protect Java class files from decompilation by replacing identifiers with reserved words like new or while. Because Java VM doesn't associate any meaning with identifier names reserved words can be used in a class file, but will result in decompiled source code that won't compile. However, many decompilers can easily beat these crude methods, so in practice the only certain solution for protecting Java source code is to divide application into two parts, the public client part that is downloaded and the private server part, that contains potentially valuable business logic implementations and communicates with client part. For more information about Java code reverse engineering, Java code obfuscating and related tools refer to [9].

Java Development Kit version 1.1 provided means for applets to escape the sandbox security restrictions by offering a possibility for signing applets digitally. Digital signatures are based on public key cryptography [19] and are used to verify the integrity of an applet and the identity of the signer. Signed applets can request additional privileges in order to circumvent applet sandbox restrictions. When a signed applet is loaded from a web page and run, the user is shown a confirmation dialog that contains identification of the applet's author and the privilege that the applet is requesting. An example of this dialog is shown in picture 1 below.

If the user accepts the signature and the requested privilege, the applet is assumed to be trusted and has access to the requested resource. The digital signature of the applet can also be examined in more detail as shown in picture 2.

Signed applets, however, provide only a coarse control for resource access. The model supports the granting of rights based on an operation, not on an individual resource or an operation target. For example, the user may grant the applet the privilege to connect to arbitraty web sites, but the user can't control the access based on individual IP addresses. This binary model for applet security - dividing applets simply to untrusted and trusted - has been criticized and JDK 1.2 addresses the problem by providing a more fine-grained policy-based security model as described in chapter 7.2. Another problem with applet signing is that it is performed differently for two of the major browsers, namely Microsoft's Internet Explorer and Netscape Navigator. This is partly because both vendors, Microsoft and Netscape, have implemented their own additions for controlling signed applets. The basic idea is nevertheless the same: the developer first creates a compressed file that contains all the classes in the applet and then digitally signs it. Java Development Kit 1.1 provides a tool called javakey, which can be used to create digital signatures for applets and the necessary keypair consisting of the public and private key. The developer first combines all the classes in the applet into a packed JAR file, which is then digitally signed with javakey. Netscape is using the JAR format, but it requires that the Certificate Authority who signs the JAR file be predefined as a trusted root. Netscape also provides means to control the period under which each permission is active with the help of its netscape.security package. Microsoft's Internet Explorer doesn't support the JAR format for signed applets, but it supports instead signed Cabinet files with the file suffix CAB. In addition to signed applets Cabinet files are also used for installing ActiveX controls and other platform specific code in Windows environments. In order to create a signed CAB file the developer must use the signcode tool provided with the Microsoft's Software Development Kit for Java [10].

Signed applets provide one way of circumventing the sandbox restrictions, but currently their usefulness is somewhat limited by the fact that Microsoft's implementation doesn't support the standard JDK 1.1 way of signing applets. Signed applets also require a well-known Certificate Authority to certify signatures. The new security model of JDK 1.2 will probably solve both of these limitations.

The security for Java is mostly designed to protect the user's workstation and its resources against hostile code, which is why special care has been taken to design all the aspects of ClassLoader, Bytecode Verifier and Security Manager. However, Java is strongly engineered towards networked computing and offers excellent possibilities for creating distributed multi-tier applications. The purpose of multi-tier applications is to enable lightweight clients that may use services provided by other computers. In a general case the client doesn't even have to know where the service is implemented physically, which is referred as implementation transparency. Typical examples of distributed applications include lightweight clients accessing data that is stored in a database on the server side.

Most modern distributed applications are object-oriented. This means that the client accesses the services via an object interface, but the main business logic of the object is implemented on the server side and only the interface is visible and existing on the client side. Thus distributed objects are divided into two parts, the so-called proxy or stub objects on the client side, which provide the object interface for the client, and the so-called skeleton objects, which reside on the server side and contain the business logic implementation. The distributed object architecture is then responsible for carrying the method calls from the client side proxy object to the corresponding server side skeleton object. The implementation of various services is usually both location and implementation transparent meaning that the user of the service doesn't necessarily know where the service is physically implemented and how and on what language the implementation is done. With Java the most common distributed object architectures are currently the Remote Method Invocation (RMI) and the Common Object Request Broker Architecture (CORBA), but in the future most distributed Java applications will probably be based on the new Enterprise JavaBeans (EJB) component model by Sun. For more information on different distributed object architectures refer to [15, 16, 25].

Remote Method Invocation was first provided in JDK version 1.1. RMI provides a Java language specific way for creating distributed object-oriented applications. RMI allows objects in one Java virtual machine to invoke methods on objects in another remote virtual machine.

RMI is based heavily on the object serialization capability that is provided by Java. It is very easy to use, but as a language specific, lightweight object distribution model it doesn't provide similar scalability and range of services as CORBA. However RMI has recently gained some added value from RMI over IIOP support that allows interoperability from RMI to CORBA world. From the security point of view RMI is, however, very insecure for Internet use. The most important security issues of the RMI are [8]:

• RMI has a simple approach for creating the connection between the client and the server. Objects are serialized and transmitted over the network, but they are not encrypted, so anyone on the network can read all the data being transmitted and possibly make unwanted changes on the fly.
• RMI doesn't provide authentication for clients. A client requests an object (stub) and the server supplies it. Subsequent communication is assumed to be from the same client, which offers many possibilities for attacks.
• Objects provided by RMI don't have any kind of access control.
• Stubs are assumed to match the skeletons of the classes. However, programs could be constructed to simulate the RMI network calls, while allowing any data to be placed in the requests. This also presents problems if version control between the skeletons and the stubs isn't up to date.

JDK 1.2 will correct the worst problems by allowing the use of custom socket factories with RMI, thus enabling SSL support for both encryption and authentication. However, in the current release of JDK RMI isn't nearly secure enough for the Internet use. In small scale Intranet applications over a trusted network RMI provides - despite its security problems - an easy way of creating distributed object-oriented applications.

Java Servlet API is a way to deploy Java on the web server side. Servlets are Java programs running on the web server and are integrated with the web server software via the Java Servlet API. The Java Servlet API is quite recent addition to Java specification and isn't part of the JDK, which mainly consists of the classes to be used by Java client applications. Instead a separate Java Servlet Development Kit (JSDK) is provided by Sun for developing servlets. After a servlet is configured to be run by the web server, it is referred to with an URL address, the name of which is of the form http://webserver/servlet/servletname. Servlets can process both HTTP get and post requests that are directed to this address. Servlets are thus excellent candidates for transaction type processing of the clients' requests. Servlets are mostly used to replace traditional Common Gateway Interface (CGI) programs, because they provide many advantages over them [24]:

• Portability: servlets are implemented with the standard Java language and are thus platform and operating system independent. Nowadays most common web servers provide support for the Servlet API or at least for some kind of a plug-in, with which the support for servlets can be enabled.
• Scalability: the web server will create a new instance of the servlet class for processing each request. The new instance is run in a separate new thread, and both the servlet class instance and the thread are alive only for as long as it takes to process the request. Creating a thread is a lightweight operation compared with the creation of a new process that must be done for running standard CGI programs. Thus servlets provide a much more scalable solution.
• Security: servlets offer the same security as other Java programs, for example protection from buffer overflows etc. that can cause serious security holes in traditional CGI programs.

Servlets can also transparently take advantage of a web server's SSL support thus enabling secure encrypted and authenticated communication between the browser and the web server. Support for secure SSL communication, integration with a web server plus the ability to automatically generate a new thread for processing each request are the main advantages of servlets over using traditional socket based Java server code on the web server.

However, servlets are not limited only for replacing CGI programs. Servlets can also be used as middle-tiers in Internet based distributed applications enabling lightweight clients, because servlets offer an easy and secure method for communicating with applets. Because Java has built in support for HTTP and object serialization, it is easy to create a general transaction based communication model between an applet and a servlet. This communication model is based on the ability of Java to serialize any class implementing the Serializable interface to any kind of output stream and to construct the serializable class based on data from any kind of input stream. Object based communication can thus be implemented by transmitting serialized objects between a servlet and an applet. This kind of communication model is introduced, for example, in [17]. When a servlet works as a middle-tier in a distributed application, it is usually connecting to a database for data retrieval, or it can be used as a protocol converter to transaction requests from HTTP based object serialization into CORBA method calls, in which case the servlet would work as an intermediate client for some object request broker (ORB).

Because servlets can use HTTP and SSL, the above described communication model allows secure, transaction type communication between an applet and a servlet [2]. This kind of communication has some drawbacks however. One of these problems is the identification of the client between requests assuming that the client doesn't have a fixed X.509 certificate for SSL authentication, because HTTP communication is transactional and it doesn't have any continuous communication context. These problems can be solved elegantly, however, by creating secure hash values with cryptographic hash functions like Secure Hash Algorithm (SHA), which is usually provided for the java.security.MessageDigest class. The servlet could create this hash value based on some pseudo-random material, such as a timestamp, a random number generator, the amount of free memory in the system and the internal state of the servlet. The client's IP address, user id and login password could also be used as an additional input to the hash function. This hash value could then work as an explicit session identifier in the requests of the client, and the state data of each client could be stored in a general container type class such as the Hashtable class of Java. If the Hashtable class instance is static, it is shared by all the threads in a servlet, and if the 160bit session identifier created by SHA is used as a key into the hashtable, the developer gets a small scale application server almost for free. Of course an applet and a servlet are not limited only to SSL, because Java allows easy protocol tunneling with HTTP [2]. For information about more complex and secure protocols implemented with Java refer to [11].

Servlets offer good potential for creating thin clients with secure client-server communication in distributed multi-tier computing architectures. The ability to take advantage of the serialization capability of Java avoids many problems that are traditionally encountered with proprietary protocols. To extend servlets to a more complete application server architecture, one can take advantage of products such as IBM's WebSphere application server that is based on servlet technology [5].

The Common Object Request Broker Architecture (CORBA) is a specification by the Object Management Group (OMG). It is the most common standard middle-ware for developing distributed object systems. CORBA provides many architectural and implementation features, including location and implementation transparency with respect to language, operating systems and hardware. With the growth of the Internet, CORBA is gaining also mainstream appeal. Currently CORBA implementations are incorporated both with the Netscape Navigator browser and the upcoming JDK 1.2. The main difference between CORBA and RMI are language independence and the scope of services offered. For more detailed comparison refer to [1].

Java provides, however, an excellent match with CORBA, because of its strong object orientation and native support for separate interfaces for objects. CORBA and Java are also coming together with the new Enterprise JavaBeans specification, which is a specification for new reusable component-based architecture by Sun [20]. CORBA specification itself includes a large set of services, which also take into account security on many levels. Object Request Brokers use Internet Inter-Orb Protocol (IIOP) to communicate with each other. OMG already has specifications for CORBA Security Service, Secure IIOP and a firewall specification for IIOP, which can be found from the OMG's web site. Because CORBA security is its own wide field and isn't in anyway Java specific, this paper doesn't include a more detailed description of the security features of CORBA; instead refer to the specifications by the OMG from [14].

A firewall is a combination of a computer system and network hardware that is used to link two or more networks, and to enforce some access control policy between them. It protects one side of the network from the dangers and threats from the other part of the network. Basic firewalls are used to filter TCP/IP packet traffic by inspecting IP addresses and TCP port numbers. In companies firewalls are used to restrict almost all inbound traffic and to allow only a limited set of traffic to the Internet. The purpose is to avoid potential attacks, which are based on incomplete specifications and defective implementations of various network applications. By limiting the allowed inbound traffic the number of potential hacking attempts is severely reduced and by allowing access to only well known services like HTTP the risk of running malicious network programs from inside the firewall is also lessened. The general approach of companies that is used to connect secure enterprise network with the Internet is to use following restrictions on network traffic:

• Restrict all incoming network traffic: That is do not allow SNMP, HTTP, FTP, Telnet, Ping or other packets sent from the Internet to come inside the firewall. This can be achieved by closing a set of ports that is used by these application protocols.
• Allow only a limited set of protocols from inside the firewall to the Internet. These protocols normally include only HTTP, Telnet, FTP, SMTP or a subset of them. This can also be achieved by allowing access based on the TCP port number and potentially checking the TCP/IP packet protocol identifier.
• Possibly check the contents of the packets in allowed protocols. This can be used to remove all Java and JavaScript related contents from HTTP packets.
• Some companies also restrict the allowed downloads with HTTP and FTP protocols, and allow only the downloading of well known document formats like PostScript, Adobe PDF, Microsoft Word Documents and HTML-files in order to avoid the downloading of executable programs containing potential Trojan horses and viruses.

If the communication of a distributed application goes through a firewall, special care must be taken to ensure that the firewall allows the normal execution of the application and still protects the company network from outside attacks. Obviously in order to make use of these kind of distributed applications, the communication must be protected somehow, preferably by encrypting it. The most common scheme for allowing secure communication through firewall is to use SSL, which uses the well-defined port 443 and provides both authentication and encryption. SSL is described in more detail in next section. To enable a Java applet to communicate with a servlet using SSL, for example, the firewall should allow applet tags in HTML-pages to enable the downloading of applets, and allow connections to the remote port 443 for the SSL handshake. If the global service provider uses distributed Java applications, in which the client downloads an applet that communicates with the web server, problems may arise if the user is inside an enterprise network with a rigorous firewall policy. Rigorous firewall configurations may restrict all other protocols except HTTP for example. In this case one way to circumvent the firewall restrictions is to use protocol tunneling, in which HTTP is used to carry data packets of another protocol. This is normally achieved by using servlets, which are used as protocol converters from HTTP to IIOP for example. However, tunneling application level protocols securely with SSL and HTTP provides some problems. One of these is that the firewall can no longer be used to filter the data that goes through it, because the firewall sees only encrypted data and can not thus ensure that the data doesn't contain any unwanted items. Usually firewalls in companies also don't allow the use of RMI and IIOP. IIOP also presents another problem, because if an application is using asynchronous service calls, the response from the server may no longer be easily linked with the corresponding request from the client. The new firewall specification for IIOP from the OMG should solve this problem in the near future.

Secure Socket Layer is an open protocol for securing data communications across computer networks. It is also the most widely used protocol for implementing cryptography in the Web. It has two major security aims

• to authenticate the server and optionally the client using RSA public-key signatures.
• to provide an encrypted connection for the client and the server to exchange messages.

SSL provides a secure alternative to the standard TCP/IP sockets protocol. SSL implementations are mostly used with HTTP, but nowadays it is also used with other application protocols such as IIOP. SSL uses a handshake protocol when establishing a protocol session. The handshake protocol is responsible for negotiating a cipher suite that both communication parties support. After the common cipher suite is found, server sends the client its certificate, which will be verified by the client. After this the client sends encryption key material to the server. The key material consists of random bits and is encrypted with the server's public key. After this both parties can create a common encryption key for bulk encryption that can be done with RC4 or similar cipher algorithm. SSL also uses MD5 hashing to ensure data integrity.

The main advantage of SSL is that it removes the need for the application developer to deal with the low-level details of cryptography. Using SSL is transparent to the application developer, the only change needed to take advantage of SSL encryption is to change HTTP addresses' prefix from "http:" to "https:". Java applets can thus take direct advantage of SSL because SSL support is built into the browsers. Java applications however need separate class packages for SSL because JDK doesn't provide SSL support.

As discussed in chapter 6.2, one good solution for secure Java client-server communication is to use an applet and a servlet. The applet can use SSL support in the browser and the servlet can transparently take advantage of the web server's SSL support. This allows secure communication over HTTP that can be used either to tunnel some well defined protocol or with some proprietary protocol that could, for example, be based on Java's serialization. [2, 17]

The main weakness of the SSL solution is that users outside the United States can usually only get their hands on the export versions of the SSL cipher suites, which provide only 40bit encryption. The United States export restrictions for strong cryptography prevent normal users form acquiring versions of Netscape Navigator or Internet Explorer that provide strong 128bit cipher suites for SSL. The Opera browser from Norway, however, provides 128bit SSL security, but unfortunately it doesn't yet have Java support. Thus for secure client server solutions using Java one nearly has to live in the United States or revert to some proprietary encryption implementation while possibly taking advantage of the authentication that SSL provides with server side certificates.

The security model of the Java has evolved with each release of the Java Development Kit. The table 1 summarizes the changes in security functionality that is provided in each major version of the JDK. As shown, JDK 1.0 provided the division of Java programs into two categories, trusted applications and untrusted applets, which are subject to the Java sandbox restrictions. JDK 1.1 extended the so-called black and white security model by enabling digitally signed applets, which could break out from the Java sandbox restrictions. If the user accepts the signature and grants the privileges, signed applets are run similar to Java applications and have thus no access constraints to resources. JDK 1.1 provided also Java Cryptographic Architecture (JCA) API, which contains methods for message digests like SHA and MD5, digital signatures and key pair generation for public key signatures. Java Cryptographic Extensions (JCE) extends Java with more cryptographic services such as encryption, but due to the U.S. export rules JCE is not part of the freely available JDK. JDK 1.2 will provide improved and much more flexible access control features than the previous versions. These new features are discussed in the next section, but the discussion is based on beta-level documentation and it is possible that some of the features will be changed before the final release of JDK 1.2.

Java Development Kit 1.2 provides several new and important additions to the security model of Java. The most important of these new features is the policy-based, fine-grained access control, which is described in more detail in the next section. In addition to the policy-based access control JDK 1.2 also provides a new set of security related tools, which replace the javakey tool in JDK 1.1. These new tools are introduced in the table 2.

Unlike JDK 1.1, JDK 1.2 provides access control also for applications instead of only applets. The access control model of JDK 1.2 is also much more fine-grained than the black and white model of JDK 1.1 allowing even the lexical scoping of privileges. JDK 1.2 has also an implementation of SecurityManager class unlike previous versions of JDK. This has the advantage that developers no longer have to write their own SecurityManager classes from scratch for applications, instead they can use and inherit the provided reference implementation. JDK 1.2 includes also an X.509 version 3 implementation of a new Certificate interface, which enables developers to build tools for parsing certificates, enforcing their own site-specific certificate policies, and managing local databases of certificates. Other additions to JDK 1.2 include guarded and signed objects. Guarded objects can be used for customizing access control to specific objects and signed objects can be used for ensuring the integrity and immutability of objects. JDK 1.2 also provides custom socket factories for RMI, which can be used to enable RMI over SSL thus overcoming some of the security weaknesses of RMI. For more detailed information about the new security features in JDK 1.2 refer to [3, 13].

The policy based access control model is no doubt the most interesting new feature of JDK 1.2 from the security point of view. It provides common fine-grained access control for both applications and applets. Instead of signing code and enabling everything as in JDK 1.1, the application can be granted individual fine-grained permissions for specific operations. The policytool is used to grant or refuse these permissions based on data, such as who signed a given class and where it was loaded from. When it comes time to execute the privileged code block, the new access controller consults the policy database to see if the code has the required permission. The policy based access control model can be described as follows:

• All executable code, i.e. classes, is divided into security domains. Each class belongs to one, and only one domain. Security domains can, for example, include code base URLs or all classes signed by specified vendor.
• Each security domain is assigned permissions. Each permission specifies a permitted access to a particular resource such as "read" and "write" access to a specified file or directory, "connect" access to a given host and port, etc.
• The intersection of permissions present in the current method call stack (down to and including the permissions of the current thread with its inherited access control context, or the upmost privileged class) define the operations this method is allowed to perform.

The policy, specifying which permissions are available for code from various signers and locations, can be initialized from an external configurable policy file. Unless permission is explicitly granted to code, it cannot access the resource that is guarded by that permission. Examples of specified security policies in a security database are given in figure 7. For a more detailed description of the JDK 1.2 security policy model refer to [12].

The security in distributed Internet applications is a wide field, so this paper has only scratched the surface of the general domain, despite being focused mostly on the Java specific issues. Even though Java was originally designed for secure network-based computing, it is only know reaching the maturity, that it needs in order to be widely used for large scale distributed business applications. It is, however, evident that Java provides a good basis for more secure distributed computing. The security model of the current JDK version 1.1 has yet some gaps, especially concerning the granularity of access control, but the soon coming JDK version 1.2 will elegantly fill these gaps by providing a new fine-grained access control model for resources. The evolution of Java security has also been fast and will probably remain so, which gives it a certain credibility. The best fit for Java, considering large scale distributed object-oriented computing, seems to be either CORBA or EJB, both of which will offer an expanding set of security related services. Because both of these seem to be merging into a common model for creating distributed applications, Java will probably be part of the foundation for tomorrow's large-scale secure distributed applications.