SSL Java Standard Extension to JDK 1.1 (draft)

This document provides an overview of the components of the Secure Sockets Layer (SSL) API, which is a standard extension to release 1.1 of the Java platform. It is not tutorial; readers are expected to know the basics of socket programming in Java, and to be comfortable reading the SSL API Reference pages. However, a short note describing SSL's notion of a "cipher suite" is appended, since some readers will not be familiar with that concept.

Quality SSL implementations will involve a variety of additional components, beyond these standard SSL APIs. Components of note include implementations of cryptographic algorithms, secure key management including some notion of "login" to control access to private keys, using X.509 certificate chains to implement authentication policies, and tools to administer that X.509 authentication infrastructure. These SSL extension APIs do not depend on how those functions are performed.

Extension Packages

As is true of all Java Standard Extensions, these APIs are intended to be implementable from specification by third parties.

javax.net.ssl

This is a "high level" SSL API, which does not provide full access to specialized features sometimes needed by SSL applications. For example, controls over what private keys (and, equivalently, SSL sessions) get used are not available through these APIs, since they expose details at a level where different implementations are known to have necessary differences.

There are five basic features in this high level SSL API:

  1. SSLSockets and SSLServerSockets, used like any other sockets unless SSL-specific features are required.
  2. Socket factories, with which authentication contexts (holding private keys, certificate chains, and similar data) are associated. The constructors on SSL sockets are not publicly accessible, so these APIs must be used to acquire SSL sockets.
  3. SSL-specific session capabilities, including authentication. Several connections can belong to the same session.
  4. A handshake completion event notification facility. When they wish to create a new session, perhaps one with a different quality of protection, applications can start an SSL handshake. When that completes, they can be notified using the standard Java Beans event notification model.
  5. SSL-specific exceptions which may be thrown. These are all subtypes of IOException since that is the exception which may be thrown during the I/O operations which produce the need to report such exceptions.

It is a goal to allow implementation of this interface using native code, rather than requiring a pure Java implementation, since cryptographic security code is one of the classic areas where enabling choices of implementation is critically important. For example, in some cases hardware to accelerate cryptographic operations is important, and in many environments only specific implementations of cryptographic algorithms are permitted.

Accordingly, most of the methods on these classes are abstract or are constructors accessible only to subclasses.

javax.net (not specific to SSL)

This includes basic socket and server socket factories. By using factories, rather than constructors, systems have policy hooks through which different kinds or configurations of sockets may easily be substituted.

This approach contrasts with the approach currently used inside the java.net package, where sockets are implemented using a class which mirrors the weakly typed C-Language UNIX "sockets" API, and only one "implementation factory" exists per Java Virtual Machine.

javax.security.cert (not specific to SSL)

This holds X.509 certificate support. A more fully-developed core X.509 V3 certificate API will be present in JDK1.2.

HTTPS URL Handler

The java.net.URL class supports, without any modification, the https://host/object style URL. This represents one of the most common APIs to SSL on the client side; it layers the HTTP protocol over SSL. In many environments, firewalls support tunneling of HTTPS through corporate firewalls to Internet web servers such as those for banks and brokerages, providing a richer programming model than that which is available to socket level programmers.

A common way to use such URLs is to use HTTP's POST method to send a request to a remote object, for which a response is returned. This can be viewed as an easily used "object oriented RPC", secured using SSL's privacy and authentication features.

What is an SSL Cipher Suite?

A cipher suite combines four kinds of security features, and is given a name in the SSL protocol specification. Before data flows over an SSL connection, both ends attempt to negotiate a cipher suite. This lets them establish an appropriate quality of protection for their communications, within the constraints of the particular mechanism combinations which are available. The features associated with a cipher suite are:
  1. What kind of key exchange algorithm is used. SSL defines many; the ones that provide server authentication are the most important ones, but anonymous key exchange is supported (subject to "man in the middle" attacks). The "RSA" authenticated key exchange algorithm is is currently the most interoperable one. Another important key exchange algorithm is the authenticated Diffie-Hellman "DHE_DSS" key exchange, which has no patent-related implementation constraints.
  2. Whether it is freely exportable from the U.S. due to using short (512 bits) public keys for key exchange and short symmetric keys (40 bits) for encryption. Those are currently subject to breaking in an afternoon by a moderately well equipped adversary.
  3. What encryption algorithm is used. The fastest option is the RC4 stream cipher; DES and variants (DES40, 3DES-EDE) are also supported in "cipher block chaining" (CBC) mode, as is (in some suites) null encryption. (Null encryption does nothing; in such cases SSL is used only to authenticate and provide integrity protection.)
  4. What digest algorithm is used for the Message Authentication Code, either MD5 or SHA1.

So for example the cipher suite named SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA uses SSL, an authenticated Diffie-Hellman key exchange (DHE_DSS), is export grade (EXPORT), uses an exportable variant of the DES cipher (DES40_CBC), and uses the SHA1 digest algorithm in its MAC (SHA).

A given implementation of SSL will support a particular set of cipher suites, and some subset of those will be enabled by default. Applications have a limited degree of control over the cipher suites that are used on their connections; they can enable or disable any of the supported cipher suites, but can't change the cipher suites which are available.

This API was first published at the 20th National Information Systems Security Conference in Baltimore, Maryland on October 8, 1997. Copyright 1997-1998, Sun Microsystems, Inc.
java-security@java.sun.com