Understanding SSL Protocol

SSL setup and data exchange over the underlying TCP connection takes place in two different phases: handshake and data transfer. The handshake phase involves negotiation of the cipher-suite, authentication of end-points and agreement on cryptographic keys for subsequent encryption and decryption of application data. This essentially establishes a SSL Session between two end-points. The data transfer phase involves message digest computation, encryption and transmission of the encrypted data blocks at one end and reception, decryption and digest verification at the other end.

Recall that TCP is a byte stream-oriented protocol, meaning there is no grouping of a sequence of bytes in records at the application level. SSL protocol layers a record structure on top of this, exchanging data, both during handshake and data transfer phase, in SSL Records. An SSL record consists of a header and a body, the header indicating the size and type of the body. More details on the various SSL Record types and the exact format of SSL messages can be found in RFC 2246.

It is important to keep in mind that even though SSL introduces the notion of records on top of TCP byte stream, applications do not see this packaging and continue to operate on byte streams.

Figure 6-2 depicts the sequence of messages exchanged between a SSL server and a client during the handshake phase. These messages and the corresponding processing at the client and server are explained below:

1.
The client sends a ClientHello message with a list of cipher suites it is willing to support, highest protocol version supported by the client, a random number and a compression method value, possibly NULL. Since a SSL client doesn't know whether it is talking to a SSLv2, SSLv3 or TLSv1 server, it could use the SSLv2 format for this message. This is the case with the J2SE v1.4 SSL library.

2.
Based on the ClientHello message, the server picks the strongest cipher suite supported by both end points and responds back with a ServerHello message. This message contains protocol version (3.1 for TLSv1), a 32-byte random value, a 32-byte session ID, the selected cipher suite and agreed upon compression method value.

3.
The server sends its certificate or certificate chain in a Certificate message if the selected cipher suite requires it. Except for a few cipher suites with anon authentication, all require the server to send its certificate.

4.
The server sends a ServerKeyExchange message if it has no certificate or the certificate is for signing purposes only.

5.
If the server is configured for client authentication then it sends a CertificateRequest message.

6.
Finally, the server sends a ServerHelloDone message. Note that all messages since the ServerHello message could be packaged in one SSL record. On receiving all these messages, the client performs a number of operations: verifies server's certificate, extracts the public key, creates a secret string called pre-master secret, and encrypts it using the server's public key.

7.
The client sends its certificate or certificate chain if the server asked for it.

8.
The client sends the encrypted pre-master secret in ClientKeyExchange message.

9.
The client sends a CertificateVerify message having a string signed by the private key corresponding to the public key of the certificate sent earlier. This message is not sent if the client did not send a certificate.

10.
The client sends a ChangeCipherSpec message in a separate SSL record to indicate that now it is switching to the newly negotiated protocol parameters for subsequent communication.

11.
The client sends a Finished message, which is a digest of the negotiated master secret and concatenated handshake messages. The server verifies this to make sure that the handshake has not been tampered with.

12.
The server sends a ChangeCipherSpec message in a separate SSL record to indicate switching to the newly negotiated protocol parameters.

13.
The server sends Finished message, which is a digest of the negotiated master secret and concatenated handshake messages. The client performs a similar verification on this message as the server.

Figure 6-2. SSL Handshake between Client and Server.


This concludes the creation of a SSL session between the client and the server, allowing the end-points to exchange application data securely, using the negotiated parameters for encryption and decryption. It is to be noted that the handshake involves compute-intensive public-key cryptography, adding significant delay to the connection establishment process. We talk more about it in the Performance Issues section.

A SSL session can span multiple TCP connections. It is possible for two communicating end-points to use the parameters associated with a SSL session for a subsequent TCP connection using a technique known as session resumption. This helps avoid the costly handshake operation between the same client and server.

A large number of cipher suites have been specified in TLS specification and more have been added in subsequent RFCs. The original cipher suites included combinations of authentication and key exchange algorithms RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA; symmetric ciphers RC2, RC4, IDEA, DES and Triple DES; and digest functions MD5 and SHA. RFC 2712 adds cipher suites for Kerberos-based authentication and RFC 3268 adds cipher suites for AES symmetric cipher. You can get supported and enabled ciphers in a Java implementation by querying the SSLSocketFactory class. The source code to accomplish this can be found in file ShowCipherSuites.java.

Listing 6-4. Displaying cipher suites supported by JSSE
// File: srcjsbookch6ex1ShowCipherSuites.java
import javax.net.ssl.SSLSocketFactory;

public class ShowCipherSuites {
  public static void main(String[] unused) {
    SSLSocketFactory sf =

(SSLSocketFactory)SSLSocketFactory.getDefault();
    String[] supportedCSuites = sf.getSupportedCipherSuites();
    String[] enabledCSuites = sf.getDefaultCipherSuites();

    System.out.println("Supported Cipher Suites:");
    for (int i = 0; i < supportedCSuites.length; i++){
      System.out.println("	[" + i + "] " + supportedCSuites[i]);
    }
    System.out.println("Enabled Cipher Suites  :");
    for (int i = 0; i < enabledCSuites.length; i++){
      System.out.println("	[" + i + "] " + enabledCSuites[i]);
    }
  }
}

Running the ShowCipherSuites program with Sun's J2SE v1.4 produces the following output. The same output may be obtained by running command "ssltool show –cs".

C:ch6ex1>java ShowCipherSuites
Supported Cipher Suites:
        [0] SSL_RSA_WITH_RC4_128_MD5
        [1] SSL_RSA_WITH_RC4_128_SHA
        [2] SSL_RSA_WITH_3DES_EDE_CBC_SHA
        [3] SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        [4] SSL_RSA_WITH_DES_CBC_SHA
        [5] SSL_DHE_DSS_WITH_DES_CBC_SHA
        [6] SSL_RSA_EXPORT_WITH_RC4_40_MD5
        [7] SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
        [8] SSL_RSA_WITH_NULL_MD5
        [9] SSL_RSA_WITH_NULL_SHA
        [10] SSL_DH_anon_WITH_RC4_128_MD5
        [11] SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
        [12] SSL_DH_anon_WITH_DES_CBC_SHA
        [13] SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
        [14] SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
Enabled Cipher Suites  :
        [0] SSL_RSA_WITH_RC4_128_MD5
        [1] SSL_RSA_WITH_RC4_128_SHA
        [2] SSL_RSA_WITH_3DES_EDE_CBC_SHA
        [3] SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        [4] SSL_RSA_WITH_DES_CBC_SHA
        [5] SSL_DHE_DSS_WITH_DES_CBC_SHA
        [6] SSL_RSA_EXPORT_WITH_RC4_40_MD5
        [7] SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

This is only a small subset of cipher suites supported by TLSv1. As we see later, the choice of cipher suite has implications on security and performance of the system.

Does a programmer need to know all these gory details of SSL internals? The answer is yes and no. Most of the time everything works fine and you don't need to worry about the internal working of SSL. However, while configuring a system for SSL communication, it is common to encounter compatibility or configuration problems. In cases where you cannot get things working at the first try, you may want to look at the handshake messages to identify the cause of the problem. That is where the information presented in this section comes in handy.

How do you get hold of these messages? You can do so by either enabling debug messages at your Java program or by using a program like ssldump or running ssltool in proxy mode.

Enabling debug messages related to SSL operation in a Java program is simple. You set the system property javax.net.debug to the appropriate value, either at the command line or within the program by calling System.setProperty(). To get a list of all the supported values, set this property to string "help". This property is examined only when a SSL related method is invoked, so you must have the program that performs some SSL operation to get the help message. You can find more about this system property and other ways of trouble-shooting in the section Trouble Shooting.

Run ssltool in proxy mode to analyze SSL messages by issuing command "ssltool proxy –patype ssl –inport <inport> -host <host> -port <port>". The client should connect to the proxy by specifying the machine running the proxy and <inport> as the target TCP address and the server's machine name and port number should set as arguments <host> and <port>. In contrast, ssldump can be used to listen for TCP packets flowing through a network interface card, without requiring the client's destination host and port to be modified. You can find more about ssldump at http://www.rtfm.com/ssldump/.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.116.49.243