| SSL is a standard protocol proposed and developed by Netscape [1] in 1994 for implementing cryptography and enabling secure transmission on the Web. The primary goal of the SSL protocol is to provide privacy and reliability between two communicating parties. SSL is now under the control of the international standards organization, the Internet Engineering Task Force (IETF), which has renamed SSL to Transport Layer Security (TLS). The TLS first specification, [2] version 1.0, was released in January 1999. [3] TLS V1.0 is a modest upgrade to the SSL V3.0, which is the most recent version of SSL. For the purposes of this book, the differences between SSL V3.0 and TLS V1.0 are insignificant. Therefore, in the remainder of this chapter, we will refer to this protocol as SSL, which is the name this protocol has become known as. [1] The Internet draft of the SSL V3.0 specification is available at http://home.netscape.com/eng/ssl3/draft302.txt. [2] See Request for Comments (RFC) 2246 at http://www.ietf.org/rfc/rfc2246.txt. [3] The draft specification of TLS V1.1 was released in March 2003. SSL provides a secure alternative to the standard TCP/IP sockets protocol. In fact, SSL is not a drop-in replacement, because the application has to specify additional cryptographic information. Nonetheless, it is not a large step for an application that uses regular sockets to be converted to SSL. Although the most common implementation of SSL is for HTTP, several other application protocols have also been adapted . SSL has two security aims: to authenticate the server and the client by using public-key signatures and digital certificates [4] and to provide an encrypted connection for the client and the server to exchange messages securely. [4] This is optional. SSL client authentication needs to take place only if a server explicitly requires it. As we discuss in step 3 on page 453, even server authentication may be not required in some cases. The SSL connection is private and reliable. Encryption is used after an initial handshake to define a secret key. Message-integrity checks are maintained . In SSL, symmetric cryptography is used for data encryption, whereas asymmetric, or public-key, cryptography is used to authenticate the identities of the communicating parties and to encrypt the shared encryption key when an SSL session is established. This way, the shared encryption key can be exchanged in a secure manner, and client and server can be sure that only they know the shared secret key. Also, you have the advantage that client and server can encrypt and decrypt the communication flow with a single encryption key, which is much faster than using asymmetric encryption. In this way, SSL is able to provide -
Privacy. The connection is made private by encrypting the data to be exchanged between the client and the server. In other words, only they can decrypt it and make sense of the data. This allows for secure transfer of private information, such as credit card numbers , passwords, secret contracts, and so on. -
Data Integrity. The SSL connection is reliable. The message transport includes a message-integrity check based on a secure hash function. So there is virtually no possibility of data corruption without detection. -
Authenticity. An SSL session typically involves server authentication, which means that the client can authenticate the server. Optionally, an authenticated server can authenticate the client too. Mutual authentication implies that the information is guaranteed to be exchanged only between the intended parties. The authentication mechanism is based on the exchange of digital certificates. -
Nonrepudiation. Digital signatures and certificates together imply nonrepudiation. This establishes accountability of information about a particular event or action to its originating entity, and the communications between the parties can be proved later. For more information about these points, refer to Section 10.1 on page 343. SSL comprises two protocols: the record protocol and the handshake protocol. 13.1.1 The Record Protocol The record protocol defines the way that messages passed between the client and the server are encapsulated. At any time, the record protocol has a set of parameters associated with it, known as a cipher suite , which defines the cryptographic methods being used. The SSL standard defines a number of cipher suites. The names describe their content. For example, the cipher suite named SSL_RSA_EXPORT_WITH_RC4_40_MD5 uses -
Rivest-Shamir-Adleman (RSA) public-key encryption for key exchange with an export-strength modulus (see Section 10.3.1.1 on page 360) -
Rivest's Cipher V4 (RC4) for bulk data encryption, using a 40-bit export-strength key -
Message Digest V5 (MD5) hashing to ensure data integrity (see Section 10.2.2.4 on page 356) Note that a cipher suite determines the type of key-exchange algorithm used, the encryption algorithm used, the digest algorithm used, and the cipher strength. The SSL protocol can use various digital-signature algorithms for authentication of communication parties. SSL provides various key-exchange mechanisms that allow for the sharing of secret keys used to encrypt the data to be communicated. Furthermore, SSL can make use of a variety of algorithms for encryption and hashing. These various cryptographic options defined by SSL are described by SSL cipher suites. For example, cipher suite SSL_RSA_WITH_RC4_128_MD5 implies an RSA key-exchange mechanism with unlimited strength, an RC4 128-bit encryption algorithm, and an MD5 hash function. On the other hand, cipher suite SSL_RSA_EXPORT_WITH_RC4_40_MD5 implies an RSA 512-bit key exchange mechanism, an RC4 40-bit encryption algorithm, and an MD5 hash function. 13.1.2 The Handshake Protocol When the SSL record protocol session is first established, it has a default cipher suite of SSL_NULL_WITH_NULL_NULL , or no encryption at all. This is where the SSL handshake protocol comes in. It defines a series of messages in which the client and the server negotiate the type of connection they can support, perform authentication, and generate a bulk-encryption key. At the end of the handshake, they exchange ChangeCipherSpec messages, which switch the current cipher suite of the record protocol to the one they negotiated. This process is shown in Figure 13.1. Figure 13.1. The SSL Handshake  In Figure 13.1, only the server is authenticated, so the client does not need to provide a certificate. If client authentication is required, the handshake is a little longer. In that case, the client also sends its certificate or a no_certificate message to the server. Let us now see more details on how an SSL session is activated. The major elements in an SSL connection are -
The cipher suites that are enabled -
The compression methods that can be used; the compression algorithms are used to compress the SSL data and should be lossless -
Digital certificates and private keys, used for authentication and verification -
Trusted signers, that is, the repository of trusted signer certificates, used to verify the other entities' certificates -
Trusted sites, or the repository of trusted site certificates To speed up connection establishment, the SSL protocol allows reuse of cryptographic parameters of previously established communication sessions between a client and a server. For this reason, SSL also maintains a session cache . The steps involved in an SSL transaction before the communication of data begins are as follows . -
The client sends the server a Client Hello message. This message contains a request for a connection, along with the client capabilities, such as the version of SSL, the cipher suites, and the data-compression methods it supports. -
The server responds with a Server Hello message. This message includes the cipher suite and the compression method it has chosen for the connection, and the session ID for the connection. Normally, the server chooses the strongest common cipher suite. If unable to find a cipher suite that both the client and the server support, the server sends a handshake-failure message and closes the connection. -
The server sends its certificate if it is to be authenticated, and the client verifies it. Optionally, the client sends its certificate too, and the server verifies it. When a secure connection requiring SSL server authentication is being established, the server sends a certificate chain [5] to the client to prove its identity. The SSL client will pursue the connection establishment to the server only if it can authenticate the server, or, in other words, verify the signature on the server's certificate. In order to verify that signature, the SSL client needs to trust the server site itself or at least one of the signers in the certificate chain provided by the server. [6] After verifying the server certificate, the client uses the public key of the server in the next steps of the SSL handshake protocol. [5] The CA that signed a certificate might not be a known or trusted entity. Hence, for verification purposes, the certificates of the CA, and of the CA that certified this CA, would be required. This is known as a certificate chain (see Section 10.3.4 on page 372). [6] In the certificate chain provided by the server, only one of all the certificates needs to be trusted in order for the server itself to be authenticated. However, some SSL implementations , including some JSSE providers, also require that all those certificates be successfully validated . On those implementations, the authentication process will fail, for example, if any of the certificates in the certificate chain provided by the server has expired . SSL client authentication follows the same procedure: If an SSL server requires client authentication, the client sends to the server a certificate chain to prove its identity, and the server has to verify it. We discussed SSL cipher suites earlier in this section. Almost all the SSL cipher suites, with the exception of some anonymous ones, require server authentication and allow client authentication. -
The client sends a ClientKeyExchange message. This random-key material is encrypted with the server's public key. This material is used to create the symmetric key to be used for this session, and the fact that it is encrypted with the server's public key is to allow a secure transmission across the network. The server must verify that the same key is not already in use with any other client. If this is the case, the server asks the client for another random key. -
When client and server agree on a common symmetric key for encrypting the communication, the client sends a ChangeCipherSpec message indicating the confirmation that it is ready to communicate. This message is followed by a Finished message. -
In response, the server sends its own ChangeCipherSpec message indicating the confirmation that it is ready to communicate. This message is followed by a Finished message. Now the client and the server can start communicating in secure mode. |
