SSL Connection Setup
SSL Connection Setup
Secure Socket Layer (SSL) sits on top of TCP layer, below the application layer and acts like sockets connected by TCP connections. It is used to secure TCP-based applications, not UDP or directly over IP. The most popular application used for SSL to secure communications is HTTP over SSL, or HTTPS. Others include SMTP/ IMAP over SSL.
An SSL connection is established in two main phases- the Handshake phase and the Secure data transfer phase. The handshake phase negotiates cryptographic algorithms, authenticates the server, and establishes keys for data encryption and Message Authentication Code (MAC). The secure data transfer phase sends encrypted data over established SSL connection.
The following shows the flow and messages of a typical SSL connection setup.
Hello Phase
The Client initiates a session by sending a Client Hello message to the Server. This Hello message contains:
- Version: The Client sends the version number that it supports. For example, for SSLv3, the version number is 3.0. For TLS, the version number is 3.1.
- Random: This is a Client generated random structure. It contains the Client's date and time, and a 26-byte pseudorandom number.
- Session ID (if any): This is included if the Client wants to resume a previous session. If the Session ID Length is 0, it indicates a new session.
- Cipher Suite: This is the list of cipher suites that are supported by the Client. An example of a cipher suite is TLS_RSA_WITH_DES_CBC_SHA, where TLS is the protocol version, RSA is the algorithm that will be used for key exchange, DES_CBC is the encryption algorithm and SHA is the hash function.
- Compression Methods: Currently, no compression methods are supported.
The following shows a typical Client Hello message.
The Server sends back the highest protocol version that is supported by the Client and the Server. This version will be used throughout the connection. The Server responds with its own Hello message. This Hello message contains:
- Version: The Server sends the highest version number supported by both Client and Server.
- Random: The Server also generates its own random value. It also contains its own date and time.
- Session ID: If the Client sends an empty session ID to initiate a new session, the server generates a new session ID. If the Client sends a non-zero session ID to resume a previous session, the uses the same session ID that is sent by the Client. If the Server cannot or will not resume a previous session, it generates a new session ID.
- Cipher Suite: This is the single cipher suite selected by the Server out of the cipher suites proposed by the Client.
- Compression Method: Currently, no compression methods are supported.
The following shows a typical Server Hello message.
Authentication and Key Exchange
In this phase, the Client and the Server generates an authenticated shared secret, called pre_master secret, which is converted to master sercret. SSLv3 and TLS support RSA and Diffie-Hellman for key exchange.
The Server sends its certificate to the Client. The Server certificate contains the Server's Public key. The Client will use this key to authenticate the Server and to encrypt the pre_master secret.
The pre_master secret has two pieces: the Client's protocol version and the random number. The pre_master secret is encrypted by Server's Public key retrieved from the Server Certificate.
The Server may create and send a temporary key to the Client using Server Key Exchange message. This key can be used by the Client to encrypt the Client Key Exchange message. This step is required only when the Server Certificate does not contain a Server Public Key.
The Server may request authentication from the Client using Client Certificate Request message. The Client responds back with a Client Certificate and Client Certificate Verify messages. The Client Certificate message contains the Client's Public key and the Client Certificate Verify message contains the hash of all the handshake messages so far signed by Client's Public key. It does the job of Client authentication.
After these messages, the Server sends a Server Hello Done message indicating it has finished and is awaiting a response from the Client.
Key Derivation
The Client sends the Client Key Exchange message after computing the pre_master secret. This is encrypted by Server's Public key and sent to the Server. In this phase, the Client and the Server create a master secret individually from the data exchanged during previous phases. The Client and the Server use the following to generate the master secret. This master secret is never exchanged.
- Pre_master secret
- Client and Server random values
Only the Server with the Private key that matches the Public key in the certificate can decrypt this data and continue the protocol negotiation.
The Client then sends a Change Cipher Spec message indicating to the Server that all messages that follow the Client Finished (Encrypted Handshake) message will be encrypted using the keys and algorithms negotiated. The Server also sends a Change Cipher Spec message followed by an Encrypted Handshake message to indicate that it will begin encrypting messages with the keys negotiated.
Application Data
After the handshake phase, the communication begins on the newly established SSL connection. The Record Protocol receives the data from application layer and is responsible for fragmentation the data into blocks and re-assembly of the data blocks, sequencing the data blocks, compression/ decompression and encryption/ decryption of the data.
