Brief Overview of SSL

Early versions of SSL—SSLv1, SSLv2 and SSLv3—were developed by Netscape Communications and made available to other vendors for implementation. As different implementations appeared with their own interpretations of not-so-well-specified aspects of the protocol, it became clear that a more formal approach to standardization was needed. In response, IETF formed the TLS working group in May of 1996 to standardize an SSL-like protocol. The result was a protocol specified in RFC 2246, a minor upgrade of SSLv3 and known as TLS, or at times as TLSv1. As the basic principles and mode of operation are the same for both SSLv3 and TLS, we use the term SSL while talking about features and capabilities common to both, reserving the terms SSLv3 and TLSv1 for aspects that are unique to either of these versions.

In simple terms, SSL employs cryptography and PKI to provide message confidentiality, integrity and end-point authentication. Here is a layman's description of the SSL protocol: An SSL session is established between two end points of a TCP connection and encrypted data is exchanged over the established connection. To establish a session, the server presents a X.509 certificate to the client. The client may, on request of the server and after successfully validating the server certificate, present its certificate for mutual authentication. Subsequently, a key exchange algorithm, such as Diffie-Hellman, is used to compute a shared secret key. This secret key is used for encrypting and decrypting all the messages using a symmetric encryption algorithm. For ensuring message integrity, message digest is computed using a digest algorithm and is appended to the data.

The combination of the server authentication algorithm, key exchange algorithm, the encryption algorithm and the digest algorithm is known as a cipher suite and is conventionally represented as a string incorporating well-known abbreviations of each algorithm, separated by underscores. For example, cipher suite TLS_DH_RSA_WITH_DES_CBC_SHA refers to RSA authentication, Diffie-Hellman key exchange, DES_CBC bulk-encryption algorithm, and SHA digest. SSL uses a cipher-suite as parameter to the protocol. What it means is that newer and more powerful algorithms can be added without changing the basic protocol operation.

SSL is essentially a layer over TCP, meaning it relies on TCP for reliable, connection-oriented, byte stream-based communication, and any TCP-based higher-level protocol can be layered over SSL with minimum changes. Even the APIs provided by SSL libraries, including Java API for SSL, also known as JSSE (Java Secure Socket Extension), mimic the popular socket-based API for TCP programming. This design characteristic of SSL has been a key factor in its success as the dominant security protocol.

However, as we soon see, semantically SSL is quite different from TCP, and certain extension of the API and applications are necessary. These differences are primarily due to the need for each end-point to specify its certificate and validate the certificate supplied by the other end-point based on its list of trusted certificates. Recall from the discussion in previous chapters that within the Java platform a certificate with a private key is usually stored in a keystore, and trusted certificates, without private keys, are stored in a truststore.

With this brief introduction to SSL, let us turn our attention to the Java API for SSL. We come back with a more detailed description of the SSL protocol operation after going over the Java API and few example programs.