Secure Sockets Layer (SSL)

Most traffic that passes across the Internet is unencrypted, making it accessible to anyone who is able to intercept the data in transit. This situation is particularly problematic in wireless networks where it is relatively easy for an attacker to obtain access to data streams. When we speak of securing connections we are trying to ensure that data sent across these connections have the following properties:

SSL is a protocol that provides these three security properties for higher level TCP/IP protocols such as HTTP. SSL was designed by Netscape Communications Corporation and has been widely implemented, particularly in web browsers and servers. SSLv2 and SSLv3 were both designed and developed by Netscape and deployed in their web browser and server products. SSLv3 is a considerable enhancement of SSLv2, and fixes some security weaknesses in the v2 protocol. The Transport Layer Security (TLS) protocol was standardized by the Internet Engineering Task Force (IETF) and based on SSLv3. It includes some minor enhancements of the original integrity checking mechanism, an extra Finished message to prevent truncation attacks and a wider set of ciphersuites. Despite this, SSLv3 is the most widely deployed version of SSL, with some SSLv2 servers still in existence. Currently, few commercially available clients use only TLS.

SSL consists of a handshake protocol that allows a client to negotiate security parameters and keys with a server, and a record protocol which can use these negotiated keys and parameters to provide secure communications. A combination of public and symmetric key encryption, MAC (Message Authentication Code) and digest algorithms are used to achieve the confidentiality, integrity and authentication properties of the SSL connection. The particular combination of algorithms used is referred to as the ciphersuite. SSL supports a number of different algorithms including RSA, MD5, SHA-1, RC4® and DES. (Note: RC4 is a registered trademark of RSA Security, Inc.)

SSL/TLS Sessions

SSL/TLS is a session-oriented protocol that provides one or more secure channels between two communicating peers (the client and the server). Sessions are established by a handshake protocol, which authenticates the peers in the session and establishes a shared secret (the master secret) which is used to generate a number of keys to secure subsequent communication. Each session may have one or more connections associated with it, however each of these connections will have a unique set of keys.

Ciphersuite Negotiation

When making an initial request, a client specifies the ciphersuites it wishes to support and the server selects one from this list to use for the connection. Depending on the ciphersuite chosen, the server sends several messages to the client which in turn responds with one or more messages. In the usual mode of operation, only the server is authenticated. However, it is possible for the server to request that the client supply a certificate and an authentication message. Once the handshake exchange is completed and the necessary authentication has taken place, each side sends a ChangeCipherSpec message to indicate that they are ready to begin secure communications. The client and server use the negotiated master secret and the ClientRandom and ServerRandom values that are passed in the respective Hello messages to generate a set of keys for the connection. The server then uses these keys to send a Finished message which is used to check that no handshake messages were modified by an attacker.

Subsequent user messages are then encrypted and verified using the negotiated symmetric cipher and MAC algorithm using the generated keys. See Session Resumption/Caching.

Record Protocol

The SSL/TLS protocol uses a record layer to send all messages (including handshake messages and user data). This record structure allows fragmentation of messages across multiple TCP/IP packets, or combination of multiple messages into a single packet. The maximum record size is 16K, although in practice it may be necessary to handle records that are greater than 16K to handle bugs in certain vendor implementations. Each record is first compressed, then an integrity check is added before the record is encrypted using the currently negotiated cipher and keys. In the case of handshake messages (unless a re-handshake is being performed), a null ciphersuite is used which does not provide any encryption or integrity checks. Although compression is a standard part of the SSL/TLS protocol, no mechanisms are defined in either the SSLv3 or TLSv1 specification, and the feature is widely ignored in practice.

Session Resumption/Caching

New connections for an existing session may be negotiated by the client at any time by specifying the session-id in the initial ClientHello handshake message. The server is not required to honour such requests, and may require the client to negotiate a new session. However, if the server has retained or cached the session information, it may respond with a ServerHello message that includes the old session information. The existing master secret for the session and the new ClientRandom and ServerRandom values are then used to generate a set of keys for the connection.