The SSL Layers

  

The SSL Layers

The Secure Socket Layer protocol enables private communications over the Internet and was designed as a programming interface for network protocols. It basically creates a secure channel between the two machines; this channel is transparent , meaning that the data is unchanged while it passes through it. SSL is designed to prevent eavesdropping, tampering, or message forgery.

A connection has two phases: the handshake and the data transfer. The handshake phase authenticates the server and allows the client and server to agree on the algorithm(s) to be used to protect the data. It also allows the client and server to establish a set of cryptographic keys to protect the data; optionally , the client may also be authenticated in this phase. The data transfer phase consists of breaking the data and transmitting it as a series of records.

Following are some of the properties of SSL:

  • Message confidentiality

  • Handshaking, which may be done by using the key pair algorithm, for end-point authentication

  • Encryption, which may be done by using a secret key

  • Message transport, which includes message integrity

  • Support of digital signatures such as MD5 and SHA

This makes SSL a very powerful instrument in the arsenal against attackers ; the main advantage of SSL (and TLS) is that it is protocol independent. SSL is composed of two layers: the SSL Handshake Protocol and the SSL Record.

The Handshake Protocol

The SSL Handshake Protocol allows client and server to authenticate each other and to negotiate the keys before the data is transmitted and received. To understand the handshake phase, you need to understand the key generation process. In TLS key generation, the client first computes a pre_master_secret - a secret string produced using a pseudo-random function (PRF). Then the pre_master_secret is combined with a client random and a server random to generate another secret called the master_secret , which is used to produce all cryptographic keys to protect the data. The master_secret then is used for the cryptographic keys (for encryption and MAC algorithms).

The process is very similar for SSL v3; however, the PRF is replaced with a series of functions based on the combination of MD5 and SHA-1. Figure 22-2 illustrates this process, where Function stands for either the PRF or the combination of MD5 and SHA-1.

click to expand
Figure 22-2: Key derivation process
Cross-Reference  

Chapter 9 describes the message digest MD5 and SHA-1 in more detail.

Now that you understand the key generation process, we can continue to explore the handshake process. Think of it as the client saying hello to the server. The server answers with a hello and a certificate, and then the client returns a master_secret and sends a Finished message that is answered by the server with a Finished message. Figure 22-3 illustrates this process.


Figure 22-3: Basic SSL Handshake Protocol

As Figure 22-3 illustrates, the client initiates the handshake with a ClientHello message, which contains the supported ciphers and the client random. This message is to communicate the client preferences to the server for version, cipher algorithms, and compression algorithms. The client then waits for the server to send the acceptable parameters based on what the client has presented in the ClientHello message. The server responds with its algorithm preferences and the server random in the first ServerHello message. The client treats any other message returned by the server, except for the hello request, as a fatal error. The ServerHello message has the same format as the ClientHello message. The difference is that the client offers a list and the server responds with a selection from that list. The server may also respond with a session_id for the client to re-use a session on the established keys if the server supports it. Otherwise a zero-length session_id is returned. If the server doesn't support any of the choices in the list that the client has sent in the ClientHello message, the session fails. This is a bit difficult for client implementers since the server decides on which keys and algorithms it will use.

The server normally sends a Certificate message after the ServerHello message, so it can be authenticated. The certificate is a sequence of X.509 certificates and has the server's public key and its identity. The certificate is particular to the selected cipher suite's key exchange algorithm. For instance, a modified X.509 will be used for Fortezza. The sequence has a particular order: The first certificate is the one for the server; the next contains the key for the first certificate; the next certificate contains the key for the previous certificate, and so on until a root certificate is reached. The root certificate contains the last key. In some cases, only one certificate is sent as a test certificate to test out the system.

Cross-Reference  

Chapter 25 describes the X.509 specification.

Because there could be other messages after the certificate, the server signals that it is done with this step in the process with an empty ServerHelloDone message. This is a marker interface to complete the certificates. If the server sends no certificates, or not enough certificate information, the ServerKeyExchange message is used for additional parameters to complete some of the keys. These keys include RSA_EXPORT , DHE_DSS , DHE_DSS_EXPORT , DHE_RSA , and DHE_RSA_EXPORT.

The client then sends a ClientKeyExchange that contains the pre_master_secret , which was computed using the server's public key. It sets the key exchange for the server. For RSA, it will set an EncryptedPreMasterSecret message; for Diffie-Hellman, it will set a ClientDiffieHellmanSecret message; and for Fortezza, it will set a FortezzaKeys message. At this point both server and client have the client random, server random, and pre_master_secret, all of which are used to calculate the encryption and MAC keys. The client sends a Finished message that contains a MAC of all the previous messages and the server responds with its Finished message.

Note  

TLS and SSL v3 are very similar but incompatible. The differences are few: They include the hashing fuction, the ClientKeyExchange message, and the cryptographic key generation (TLS uses HMAC keyed message authentication v.s. SSL v3's keyed MAC function). In addition, TLS does not provide Fortezza support.

So far the handshaking has been established and keys have been exchanged. The point of using SSL is to translate the data into ciphertext . The purpose of the initial handshaking is to set up keys and a SYN state, similar to TCP, to synchronize the states in preparation for data transfer. This transfer is accomplished using the SSL Record Protocol.

An example of the cipher algorithm is " TLS_RSA_WITH_IDEA_CBC_SHA, " which means the message will use an RSA key exchange, an IDEA_CBC encryption algorithm, and a SHA message digest for the MAC. There are 32 cipher suites.

The SSL Record

The SSL Record is at the lowest level to handle the transport of data; the data stream is broken into fragments and the MAC is computed and appended to the fragment. The combination of MAC and data fragment is encrypted; the encrypted combination of fragments and MAC is referred to as the encrypted payload . A header is attached to the payload to form a record . As the receiver gets each record, it decrypts and verifies the record; the records are reassembled at the receiving end in plaintext, after validation, to make up the data stream.

This approach is mirrored after TCP. The header contains the content type , the length , and the SSL version; it is similar to the TCP packet header since it provides the necessary information for processing the payload into data. Figure 22-4 shows the record header.

click to expand
Figure 22-4: SSL record

The content type identifies the type of message. These messages depend on the current state of the SSL server and client. SSL supports four content types:

  • application_data : All data is transmitted as application_data , including the ciphertext that is transferred from the sender to the receiver.

  • alert : Usually used to transport errors from one peer to another to signal that an error condition has occurred and to provide some level of detail to describe the issue. Some of the conditions could be that the connection is about to close, errors with the handshaking, error with validation of the MAC, and more.

  • handshake : Used to carry handshake messages.

  • change_cipher_spec : Used to change the algorithm on the encryption and authentication of records. It also signals that the set of keys that was established in the handshaking is ready to be used for application data.

The length field is the length of more bytes to read off the receiver before processing the message; it is required for a stream message so that the receiver knows when it has the complete stream before decryption. The version number identifies the SSL version number to use; so far there are three versions. For SSLv3, the version's major will be set to 3 and the version's minor will be set to 0. For TLS, the major will be 3 and the minor will be 1. The server may respond with a lesser version. If the server responds with a lesser version and the client does not wish to use that version, the client needs to terminate the connection to the server.

The size of the record header is 5 bytes: 1 byte for the content type, 2 bytes for the protocol version, and 2 bytes for the length.

When the client is finished working with the server, it sends a close_notify alert message to signal the server that the connection is going to close. The TCP's FIN flag being set in the TCP packet follows this message. The server also responds with the TCP's FIN flag being set. These flags being set signify the closing of the connection.

According to the RFC, data fragments can be done in stream or block form depending on the format of the message. There are four cryptographic operations that SSL supports: digital signing , stream cipher encryption , block cipher encryption , and public key encryption .

There is the one-way hash function of SHA and MD5 for use in digital signing; in RSA, a 36-byte MD5 or SHA structure is used for the message digest. In DSS, the 20-byte SHA is used through the digital signing algorithm. In stream cipher encryption , the plaintext is exclusively ORed. In the block cipher encryption , the message is encrypted in block sizes; it is necessary to pad out the non-used characters , usually with zeros.

  


Java Security Solutions
Java Security Solutions
ISBN: 0764549286
EAN: 2147483647
Year: 2001
Pages: 222

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net