13.4 Using SSL from within J2EE Programs

Using the SSL support built into a J2EE product is a very simple and effective approach but in some cases may have some limits because the communication between the client and the server can use only the capabilities offered by the J2EE container. A direct SSL socket connection between client and server allows more sophisticated and responsive applications. For example, a Java servlet can communicate through an SSL connection and interoperate with other services and processes that are not necessarily written in the Java language. This can be done by using a Java package that provides SSL function.

13.4.1 JSSE

The Java Secure Socket Extension is a set of Java packages and APIs that enable the use of SSL from within Java programs. ^[7] JSSE provides a framework and an implementation for the SSL and TLS protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication. Using JSSE, developers can enforce secure passage of data between a client and a server running any application protocol over TCP/IP, such as HTTP, TELNET, or FTP.

^[7] JSSE was originally shipped as a standard extension to the J2SE V1.2 and V1.3 platforms. JSSE has been integrated into the J2SE platform starting with J2SE V1.4. JSSE is not an integral part of J2EE, but J2EE applications can use it as explained in Section 4.10.1 on page 145.

From a programmatic point of view, the main advantage of using JSSE is that a programmer does not have to bother with the details of the record and handshake protocols and with the encryption and decryption of the information exchanged. The underlying JSSE implementation will take care of those details at runtime. This way, the risk of creating subtle but dangerous security vulnerabilities is minimized. Moreover, JSSE simplifies application development by providing developers with a building block that can be integrated directly into existing applications. As SSL and TLS are standard protocols, Java programs using JSSE can communicate via SSL with other processes and services that may not have been written in the Java language.

The JSSE design resembles that of the Java Cryptography Architecture and Java Cryptography Extension (see Section 11.1 on page 377). Like the JCA and the JCE, JSSE provides both an API framework and an implementation of that API and is designed so that any vendor's implementation can be installed and used without having to recompile the application. JSSE uses the same provider architecture defined in the JCA and the JCE (see Section 11.1.3 on page 382). This enables applications to be vendor neutral, implementation independent, and, whenever possible, algorithm independent.

The JSSE API consists of the package javax.net and its subpackage javax.net.ssl . This API supplements the core network and cryptographic services defined in the java.net and java.security packages by providing extended networking socket classes, trust managers (see Section 13.4.2), key managers, SSL contexts, and a socket-factory framework for encapsulating socket-creation behavior. This API supports SSL V2.0 and V3.0, TLS V1.0, and HTTPS. These security protocols encapsulate a normal bidirectional stream socket, and the JSSE API adds transparent support for authentication, encryption, and data-integrity protection.

In Section 4.10.1 on page 145, we studied how servlets can become HTTPS clients by invoking an HTTPS URL programmatically. In Section 13.5 on page 462, we show how a servlet can use the JSSE API.

13.4.2 Trust Managers

A trust manager is a software component responsible for deciding whether the credentials presented by a peer during an authentication process should be considered trusted. In JSSE, trust managers are represented as implementations of the javax.net.ssl.TrustManager interface. TrustManager instances are created by either using a javax.net.ssl.TrustManagerFactory object or instantiating a class implementing the TrustManager interface.

13.4.3 Truststores

A truststore is a regular keystore that is used when authenticating a peer to decide whether the peer should be trusted. In JSSE, truststores are represented as java.security.KeyStore objects (see Section 11.2.7 on page 395). As the entries in a truststore are used to make trust decisions during an authentication process, an entry should be added to a truststore only by a system administrator and only if the entity represented by that entity is considered trusted.

The J2SE reference implementation comes with a default truststore file called cacerts , located in the lib/security subdirectory of the Java home directory. This file contains the digital certificates of common CAs, such as VeriSign and Thawte. The default password to access and modify this truststore is changeit . Users of a Java system can specify a different truststore by setting the system property javax.net.ssl.trustStore to the truststore file of their preference. This can be done programmatically, through a call to java.lang.System.setProperty() , or statically, using the -Djavax.net.ssl.trustStore option of the java command.

Often, it is useful to keep regular keystore files separated from truststore files. A regular keystore file contains private information, such as an entity's own certificates and corresponding private keys, whereas a truststore contains public information, such as that entity's trusted certificate entries, including CA certificates. Using two different files instead of a single keystore file provides for a cleaner separation between an entity's own certificate and key entries and other entities' certificates. This physical separation, which reflects the logical distinction of private- and public-key material, gives system administrators more flexibility in managing the security of the system. For example, a truststore file could be made write protected so that only system administrators are allowed to add entries to it. Conversely, a user 's keystore can be write accessible to its owner.