SSL is a communications protocol layer created by the Netscape Communications Corporation. It rests atop the TCP/IP protocol stack. SSL provides secure services over TCP/IP, such as confidentiality through data encryption, integrity via a MAC algorithm, and optional authenticity and nonrepudiation of both a socket client and a socket server. Although operating over TCP/IP, SSL can also operate under other TCP/IP-based protocols such as HTTP and IIOP. Thus, SSL can be viewed as a layer that operates between TCP/IP and higher-level communications protocols, such as HTTP and IIOP, to provide a secure communications solution. Note that although SSL most typically operates above TCP/IP, it can also operate above other reliable transport protocols.

SSL v1 was never publicly used, but Netscape introduced SSL v2 with version 1 of Netscape Navigator. SSL v3 represents the most current SSL standard in wide use. The Transport Layer Security (TLS) protocol developed by the Internet Engineering Task Force (IETF) extends the SSL v3 protocol with enhancements to the authentication aspects of the SSL algorithm. The Wireless Transport Layer Security (WTLS) protocol, as its name implies, is a version of TLS used in wireless communications.

The SSL v3 behavior follows the basic algorithmic sequence described here:

In addition to this basic handshaking protocol, messages can be sent between SSL client and server to indicate certain warning and error conditions. A protocol for changing the crypto algorithm used by the SSL session is also provided by SSL.

It is the SSL handshaking protocol, however, that provides the most insight into the utility of SSL. While the server can authenticate a client by validating the client's public certificate, this does not provide a complete authentication solution. Rather, the fact that key exchange messages are generated by the client using the client's private key enables the server to successfully decrypt information sent by the client to the server. The server thus authenticates that the actual client sent such information based on use of the client's public certificate. The same authentication process applies to the client's authentication of the server. Thus, the server-side SSL process must have a means to access the key store for the server private key during server authentication, and the client must have a means to access the key store for the client private key during client authentication.

A full description of SSL is beyond the scope of this book. But it does help to have a basic understanding of the SSL handshaking protocol as described above. This will enable you to better understand how to construct Java applications that utilize an API to SSL. Such an understanding can help you understand what SSL can and cannot do for you when providing confidential communications between a client and server. For example, based on the basic algorithmic SSL handshaking sequence described earlier, it may be apparent to you how difficult delegation of client identity is via SSL. That is, when using client authentication with SSL, the client's private key, retrieved from a key store, is used on the client-side in the process of generating the key exchange information. Thus, if the SSL client process is acting on behalf of another actual user process, the SSL client would have to have the private key of the actual user process. This is of course unacceptable in many situations.

Thus, while most people think of authentication as the means by which users authenticate themselves with a server process in order to perform security-critical operations, intermediate processes that must present themselves to the server on behalf of the end user may find it difficult to do so using SSL. More often than not, when using SSL for providing confidentiality between a client and server, the authentication that takes place is to authenticate the two end processes involved with the SSL session. A higher-level authentication process may actually be implemented above SSL in order for an SSL client to delegate end user process identity to the SSL server. For more information on SSL, check out http://www.assuredtech.com/resources/ssl.

The Java Secure Socket Extension (JSSE) provides a standard API to secure socket protocols such as SSL. The JSSE also supports an API to the Transport Layer Security (TLS) secure socket protocol. These are the specific protocol versions that are supported:

These versions are supported only by virtue of the JSSE API. At the time of this writing, Sun provided a reference implementation for only a subset of these protocols (SSL v3 and TLS v1). As with the other security extensions, the JSSE architecture follows the same adapter model of providing an API and a service provider interface for different underlying implementations to plug into the JSSE. The JSSE v1.0 download is available at http://java.sun.com/products/jsse/.

JSSE Package and Class Overview

The following packages compose the JSSE v1.0 architecture:

• javax.net.ssl: This package contains the set of core classes and interfaces for the JSSE APIs.

• javax.net: This package is not specific to the JSSE, but it is needed to support basic client socket and server socket factory functionality.

• javax.security.cert: This package is also not specific to the JSSE, but it is needed to support basic certificate management functionality.

The JSSE class architecture is primarily useful for its encapsulation of SSL socket and SSL server socket objects and factories. SSL session handles can also be useful. Finally, the SSL binding and handshake event and listener APIs are also provided. Figure 9.1 depicts this core architecture of the JSSE. Note that, in order to keep the overview discussion brief, overloaded methods or method signatures are not shown in this diagram. The following list describes the role of each major API class or interface in the JSSE architecture:

Figure 9.1. The JSSE architecture.

• SSLSocket: A socket that supports SSL, TLS, and WTLS secure socket protocols

• SocketFactory: A factory for Socket objects

• SSLSocketFactory: A factory for SSLSocket objects

• SSLServerSocket: A server socket that supports SSL, TLS, and WTLS secure socket protocols

• ServerSocketFactory: A factory for ServerSocket objects

• SSLServerSocketFactory: A factory for SSLServerSocket objects

• SSLSession: An interface to an object encapsulating an SSL session

• SSLSessionContext: An interface to an object encapsulating a collection of SSL sessions identified with a session ID

• SSLBindingEvent: An event class encapsulating SSL session binding and unbinding events

• SSLBindingListener: A listener interface implemented by objects wanting to be made aware of SSL session binding and unbinding events

• HandshakeCompletedEvent: An event class encapsulating the fact that an SSL handshake has completed

• HandshakeCompletedListener: A listener interface implemented by objects wanting to be made aware of SSL handshake completion events

Thus, as you can see, the basic JSSE architecture is rather simple and yet provides a core suite of API abstractions necessary for tapping the functionality of SSL from within Java applications. The remainder of this chapter will describe the most important JSSE API abstractions in more detail and demonstrate how to use them in your applications. Note however that at the time of this writing, the JSSE API was still fairly young in its version 1.0 release form. Thus, the chapter discussion focuses on the core JSSE APIs and most commonly used interfaces for immediate practical API usage. Additional vendor-specific SSL library interfaces may still be utilized by Java JSSE API developers in actual real-world implementations.

As with other Java 2 security and JCA means for configuring security module providers for use by a particular JVM instance, the JSSE follows the same provider configuration scheme. That is, a JSSE provider can be configured for use with a JVM instance by configuring an entry in the [JRE_HOME]libsecurityjava.security file. A security.provider.x entry in that file can be modified or added to reference a particular security provider. For example, you might have

security.provider.1=com.assuredtech.security.SSLProvider

Similarly, a security provider might also be configured for use with a JVM instance from within a static method call to the java.security.Security class as exemplified here:

// Add new instance of a JSSE provider
java.security.Provider provider
        = new com.sun.net.ssl.internal.ssl.Provider();
java.security.Security.addProvider(provider);

The provider class name used for this example is simply the default SSL provider that comes equipped with the downloaded JSSE reference implementation. The end-to-end SSL client and server example that is built up throughout this chapter in fact assumes that your SSL client and SSL server have established the default security provider during startup as shown above. The default provider implementation packaged with the JSSE reference implementation provides support for SSL v3 and TLS v1. The default implementation also provides support for RSA encryption used in generating signatures, support for PKCS12 key stores, X.509 key management functionality for loading authentication keys from a key store, and X.509 trust management functionality for chaining of certificates.

Creating SSL server sockets can be as simple as creating regular Java TCP/IP server sockets. SSL server socket abstractions provide additional hooks, however, to manipulate the security and SSL-related operation characteristics of SSL socket connections. SSL cipher parameters, authentication properties, and handshaking management are also exposed by the SSL abstractions. Although standard APIs exist for creating SSL server sockets using standard SSL server socket factories, the means by which handles to SSL server socket factories are obtained can be JSSE provider-specific.

In this section, we explore the most basic steps for creating JSSE SSL server socket factories, creating SSL server sockets, and blocking for SSL client socket requests in the context of an example SSL server. Manipulation of such sockets is then most often implemented just as regular java.net TCP/IP sockets are manipulated.

javax.net.ssl.SSLServerSocketFactory sslServerSocket
    = SSLServerSocketFactory.getDefault();

ssl.ServerSocketFactory.provider=com.assuredtech.ssl.ServerSocketFactoy

// Get and load standard KeyStore
java.security.KeyStore keyStore = null;
try{
  // Get key store instance
  String keyStoreType = "JKS";
  keyStore = KeyStore.getInstance(keyStoreType);
  // Create key store file stream
  String keyStoreFileName = "samplestore";
  FileInputStream fileInputStream
    = new FileInputStream(keyStoreFileName);
  // Load keys store from file stream given a password
  String keyStorePassword = "SAMPLESTOREPASS";
  char[] keyStorePassordInChars = keyStorePassword.toCharArray();
  keyStore.load(fileInputStream, keyStorePassordInChars);
}
catch(NoSuchAlgorithmException noAlgorithmEx){
  noAlgorithmEx.printStackTrace();
}
catch(FileNotFoundException fileNotFoundException){
  fileNotFoundException.printStackTrace();
}
catch(IOException ioException){
  ioException.printStackTrace();
}
catch(KeyStoreException keyStoreException){
  keyStoreException.printStackTrace();
}
catch(CertificateException certificateException){
  certificateException.printStackTrace();
}

// Get reference implementation key managers given key store
com.sun.net.ssl.KeyManager[] keyManagers = null;
try{
  // Create a key manager factory given an algorithm
  String keyManagerAlgorithm = "SunX509";
  com.sun.net.ssl.KeyManagerFactory keyManagerFactory =
  KeyManagerFactory.getInstance(keyManagerAlgorithm);
  // Initialize key manager factory with password and key store
  String keyManagerPassword = "SAMPLEKEYPASS";
  keyManagerFactory.init(keyStore , keyManagerPassword.toCharArray());
  // Get key managers from the factory
  keyManagers = keyManagerFactory.getKeyManagers();
}
catch(NoSuchAlgorithmException noAlgorithmEx){
  noAlgorithmEx.printStackTrace();
}
catch(UnrecoverableKeyException unrecoverableKeyException){
  unrecoverableKeyException.printStackTrace();
}
catch(KeyStoreException keyStoreException){
  keyStoreException.printStackTrace();
}

// Get reference implementation trust managers
com.sun.net.ssl.TrustManager[] trustedManagers = null;
try{
  // Create trust manager factory
  String trustManagerAlgorithm = "SunX509";
  com.sun.net.ssl.TrustManagerFactory trustManagerFactory
    =  TrustManagerFactory.getInstance(trustManagerAlgorithm);
  // Initialize trust manager factory
  trustManagerFactory.init(keyStore);
  // Get trust managers
  trustedManagers = trustManagerFactory.getTrustManagers();
}
catch(NoSuchAlgorithmException noAlgorithmEx){
  noAlgorithmEx.printStackTrace();
}
catch(KeyStoreException keyStoreException){
  keyStoreException. printStackTrace();
}

// Get secure random value
java.security.SecureRandom secureRandom = null;
try{
  // Create secure random instance given an algorithm and provider
  String secureRandomAlgorithm = "SHA1PRNG";
  String secureRandomProvider = "SUN";
  secureRandom = SecureRandom.getInstance(secureRandomAlgorithm,
                                          secureRandomProvider);
}
catch(NoSuchProviderException noProviderEx){
  noProviderEx.printStackTrace();
}
catch(NoSuchAlgorithmException noAlgorithmEx){
  noAlgorithmEx.printStackTrace();
}

// Get and initialize reference implementation SSL context
//  given key managers, trust managers, and a secure random value
com.sun.net.ssl.SSLContext sslContext = null;
try{
  // Create an SSL context given a context provider
  String sslContextProvider = "SUN";
  sslContext = SSLContext.getInstance(sslContextProvider);
  // Initialize SSL context
  sslContext.init(keyManagers, trustedManagers, secureRandom);
}
catch(NoSuchAlgorithmException noAlgorithmEx){
  noAlgorithmEx.printStackTrace();
}
catch(KeyManagementException keyManagementEx){
  keyManagementEx. printStackTrace();
}

// Obtain handle to SSLServerSocketFactory using reference
//   implementation specific SSLContext
javax.net.ssl. SSLServerSocketFactory  sslServerSocketFactory
  = sslContext.getServerSocketFactory();

// Create SSL server socket using SSL server socket factory
try{
  int serverPort = 9000;
  javax.net.ssl.SSLServerSocket sslServerSocket = (SSLServerSocket)
        sslServerSocketFactory.createServerSocket(serverPort);
}
catch(IOException ioEx){
  ioEx. printStackTrace();
}

try{
  // Enter server loop to wait for client requests and then
  //  hand off client sockets handles to special handler threads
  while(true){
    // Block waiting for client requests
    javax.net.ssl.SSLSocket clientSocket
      = (SSLSocket) sslServerSocket.accept();
    // Hand off SSLSocket to special runnable handler thread
    MyHandler handlerThread = new MyHandler(clientSocket);
    // Start the special handler thread
    handlerThread.start();
  }
}
catch(IOException ioEx){
  ioEx.printStackTrace();
  System.exit(0);
}

public class MyHandler extends Thread
{
  private Socket sslSocket;
  private InputStream remoteInStream;
  private OutputStream remoteOutStream ;

    ...

  public MyHandler(SSLSocket sslSocket) throws IOException
  {
    // Set client socket handle and get IO streams
    this.sslSocket = sslSocket;
    this.remoteOutStream = sslSocket.getOutputStream();
    this.remoteInStream = sslSocket.getInputStream();
  }

  public void run()
  {
      try {
        ...
      // Create a data input stream
      DataInputStream inputStream = new DataInputStream(remoteInStream);

      // Read a line from the input stream
      String readLine = null;
      while( (readLine = inputStream.readLine()) == null){
         System.out.println(readLine);
      } ;

      // Read another line
      readLine = inputStream.readLine();
      System.out.println(readLine);
        ...
    }
    catch (IOException ioException) {
      ioException. printStackTrace();
    }
  }

The creation of SSL sockets from client to server is also a very simple task using JSSE. Clients must first obtain handles to SSL socket factories. These handles are obtained in the same way as SSL servers obtain handles to SSL server socket factories. Creation of SSL client sockets is then accomplished using one of a few very simple socket-creation calls. SSL sockets are then used much as regular Java Socket objects are used to communicate with a remote server. This section describes how to obtain SSL socket factory objects and how to create SSL socket objects using JSSE.

SSLContext sslContext = SSLContext.getInstance("SUN");;
   ...
    // Establish parameters and initialize SSLContext
   ...
SSLSocketFactory  sslSocketFactory = sslContext.getSocketFactory();

ssl.ServerFactory.provider=com.assuredtech.ssl.SocketFactory

// Get default SSL Socket Factory
SSLSocketFactory sslSocketFactory
        = (SSLSocketFactory) SSLSocketFactory.getDefault();

// Set remote host and port number
String host = "111.111.111.111";
String portNumber = 9000;
// Create an SSLSocket to a remote server
SSLSocket sslSocket
    = (SSLSocket) sslSocketFactory.createSocket(host, portNumber);

An SSL session represents a communications session between two threads. Data communicated between such entities engaged in an SSL session can be exchanged over different physical connections during the lifetime of the session. Likewise, an SSL connection might allow more than one session to utilize the established SSL connection.

On the server side, the capability to create SSL sessions associated with an SSL server socket can be established using the SSLServerSocket.setEnableSessionCreation(boolean flag) method. The boolean value passed into such a method of course indicates true if SSL sessions are allowed to be created on the server socket connection. The SSLServerSocket.getEnableSessionCreation() method call returns a boolean value to determine if the SSL server socket enables session creation. The same two methods exist on the SSLSocket object as well. In addition to such methods, the SSLSocket object also provides a getSession() method to return an SSLSession object used by the current connection. The SSLSession.invalidate() method is used to invalidate sessions and, thus, prevent other connections from using the current SSL session.

The javax.net.ssl.SSLSession interface provides a means by which objects can be bound to a session using a String name and for removing and retrieving such objects via the following methods:

Additionally, SSLSession defines a number of other getters related to attributes of the SSL session:

The javax.net.ssl.SSLSessionContext interface simply serves as a collection of SSLSession objects that are associated with a particular entity. The SSLSessionContext interface defines a getIds() method to return an Enumeration of all session IDs associated with the SSL context. The SSLSessionContext interface also defines a getSession (byte[] sessionID) method to return an SSLSession identified by the session ID byte array.

SSL is a popular means for encrypting traffic between clients and servers. SSL sessions are encrypted using server-side certificate information and can also, optionally, require clients to authenticate themselves. JSSE provides a standard API for encapsulating the SSL protocol for use by SSL clients and servers. JSSE providers plug their specific SSL implementations beneath the JSSE standard API. By using JSSE in your Java applications, you can better insulate your applications to vendor-specific SSL API mechanisms. Although this is generally true, a vendor-specific method for configuring socket factories and authentication information is still required for JSSE v1.0.