The SSL Handshake Using SSL

• Its commonly used. Almost every language that can use sockets has at least one SSL library package already implemented for it. And it is easy to define a secure version of a protocol by simply specifying that the secure version is a layer on top of SSL instead of simply being defined over cleartext sockets. This, for example, is the way HTTPS the secure version of HTTP is defined. Thus, in almost any situation where sockets can be used, SSL can be used with minimal extra programmer overhead and very few code changes. [ 10] [ 10] There will, of course, be computational overhead. After all, encrypting and decrypting data takes time. • Its good enough. While not absolutely secure, SSL meets the criteria for practical security in a wide variety of situations. SSL has been around, in one form or another, since 1995. Currently, there are three versions in active use: SSL2, SSL3, and Transport Layer Security TLS. SSL2 is the oldest version of the spec and is very widely used. SSL3 is newer, and TLS is a successor to SSL3 the main change from SSL3 is that the Internet Engineering Task Force has taken over stewardship of the standard. Neither SSL3 nor TLS seems to be widely adopted at this point.

2.6.1 The SSL Handshake

SSL is defined and implemented as a communication protocol layered on top of an ordinary socket connection. That is, in order to establish an SSL connection, a socket connection is first established. This socket connection is used by the client and server to negotiate a way to exchange information securely. After this negotiation process, often called the SSL handshake, the socket is used to transmit the encrypted information. The SSL handshake is necessary for two main reasons. The first is that the SSL specification is still evolving. Its not enough for the participants to use SSL; the client and server must agree on a version of SSL to use. The second reason is that SSL supports a variety of encryption algorithms commonly referred to as ciphersuites. Once a version of SSL is agreed upon, the ciphersuite and the values of the keys used for encryption still need to be arranged. Ciphersuites JSSE 1.02, which can be downloaded for free from Java soft, contains implementations of 15 distinct ciphersuites: SSL_DH_anon_WITH_DES_CBC_SHA SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_RC4_128_MD5 SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 Explaining exactly what these names imply is well beyond the scope of this book. But there are two important points to note: • Five of the ciphersuites are anonymous i.e., they contain the string anon in their name. Anonymous cipher suites don t require client or server authentication. • A wide variety of different strength encryption algorithms are supported. Generally speaking, algorithms based on DES i.e., containing the string DES or those exportable from the United States i.e., containing the word EXPORT are weaker and computationally much less expensive. Thus, the reference implementations run the gamut from fairly weak SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA to impressively secure SSL_RSA_WITH_RC4_128_MD5. The SSL handshake proceeds in four basic stages: 1. The client says hello. The first thing that happens is the client sends a message to the server that contains information about the client. In particular, this message contains information about which versions of SSL the client supports, which ciphersuites the client supports, and which compression algorithms the client supports. 2. The server says hello back to the client. The server responds to the client by sending a message that tells the client which ciphersuite and compression algorithms will be used for the encrypted communication. The server is free to choose any cryptographic algorithm that the client and server both support; in practice, the server usually chooses the strongest cryptographic algorithm supported by both the client and server. 3. The participants are authenticated. Ciphersuites can be anonymous or involve authenticating the participants. If the chosen ciphersuite involves authentication, it happens at this point. 4. Ciphersuite details are negotiated. In particular, the client and server exchange keys that will be used to encrypt further data exchanges.

2.6.2 Using SSL with JSSE