Transport Layer Security (TLS) Handshake

TLS is a standard closely related to SSL 3.0, and is sometimes referred to as "SSL 3.1". TLS supersedes SSL 2.0, Applications that require a high level of interoperability should support SSL 3.0 and TLS.

Because of the similarities between these two protocols, SSL details are not included in this documentation, except where they differ from TLS. The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate, although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0

The (TLS / SSL) protocol uses a combination of public-key and symmetric-key encryption. Symmetric-key encryption is much faster than public-key encryption; however, public-key encryption provides better authentication techniques. An SSL session always begins with an exchange of messages called the SSL handshake. The handshake allows the server to authenticate itself to the client by using public-key techniques, and then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server.

The Transport Layer Security (TLS) Handshake Protocol is responsible for the authentication and key exchange necessary to establish or resume secure sessions. When establishing a secure session, the Handshake Protocol manages the following:

• Cipher suite negotiation
• Authentication of the server
• Session key information exchange.

Cipher Suite Negotiation:

The client and server make contact and choose the cipher suite that will be used throughout their message exchange.

Authentication:

In TLS, a server proves its identity to the client. The client might also need to prove its identity to the server. PKI, the use of public/private key pairs, is the basis of this authentication

Key Exchange:

The client and server exchange random numbers and a special number called the Pre-Master Secret. These numbers are combined with additional data permitting client and server to create their shared secret, called the Master Secret.

Establishing a Secure Session by Using TLS

The TLS Handshake Protocol involves the following steps:

• The client sends a CLIENT_HELLO message to the server, which includes: The highest TLS version supported by the client. Ciphers supported by the client. The ciphers are listed in order of preference. Data compression methods that are supported by the client. The session ID, If the client is starting a new session, the session ID is "0" & Random data that is generated by the client for use in the key generation process.

• The server sends a SERVER_HELLO message to the client, which includes: TLS version that will be used for the https session. The cipher that will be used for the TLS session. Data compression method that will be used for the TLS session. The session ID for the SSL session & Random data that is generated by the server for use in the key generation process.

• The server sends the CERTIFICATE. This includes the server's certificate and, optionally, a chain of certificates beginning with the certificate of the certificate authority (CA) that assigned the server's certificate.

• The ServerKeyExchange message is sent by the server only when the server Certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret. This is true for the following key exchange methods: DHE_DSS, DHE_DSA, DHE_RSA, DH_anon

• The server sends the SERVER_DONE message. This message indicates that the server has completed this phase of the TLS handshake.

• The client creates a Pre-Master Secret and encrypts it with the public key from the server's certificate, sending the encrypted Pre-Master Secret to the server.

• The server receives the Pre-Master Secret & it uses its private key to decrypt it. The server and client each generate the Master Secret based on the Pre-Master Secret & Ramdon data. Both the client and the server use the Master Secret to generate the Session Key, which are symmetric keys used to encrypt and decrypt information exchanged during the TLS / SSL session.

• The client sends CHANGE_CIPHER_SPEC notification to server to indicate that the client will start using the new session keys for hashing and encrypting messages. Client also sends FINISHED message indicating that the client portion of the handshake is finished.

• The server sends a CHANGE_CIPHER_SPEC message to the client informing it that future messages from the server will be encrypted with the session key. Server also sends FINISHED message indicating that the server portion of the handshake is finished.

• Client and server can now exchange application data over the secured channel they have established. All messages sent from client to server and from server to client are encrypted using session key.

 Resuming a Secure Session by Using TLS

• The client sends a CLIENT_HELLO message using the Session ID of the session to be resumed.

• The server checks its session cache for a matching Session ID. If a match is found, and the server is able to resume the session, it sends a SERVER_HELLO message with the Session ID. 

Note  If a session ID match is not found, the server generates a new session ID and the TLS client and server perform a full handshake.

• Client and server must exchange CHANGE_CIPHER_SPEC messages and send "Client finished" and "Server finished" messages.

• Client and server can now resume application data exchange over the secure channel.

SSL v3 vs TLS v1.0 Differences:

• Ad-hoc MAC’s were changed to HMAC’s

• Added protocol and cipher suite requirements: Diffie-Hellman, Digital Sig-
nature Standard (DSS), and Trible-DES are required instead of optional

• Changes were made to client-write and server-write key calculation
claims that the changes are an improvement which it may well be.

Leave your comment below