HTTPS and the TLS handshake protocol.


In the previous post I talked about how web browsers connect to the server and how a negotiation is initialized between server and client to establish a secure connection when the HTTPS protocol is used.

In this post I wil explain the SSL/TLS protocol and how a client (computer, smartphone, tablet, terminal, etc) and server can encrypt the data sent and received by an HTTPS connection.

First of all I’ll start talking about the relationship between SSL (Secure Sockets Layer) and TLS (Transport Layer Security). Both of them are procolos by which HTTPS can secure the data. They just describe the rules that client and server need to follow in order to create a secure tunnel and transfer encrypted data. The relationship between them is very simple. Transport Layer Security is just the name for the same protocol when it reached its version 3.1

  • SSL v1
  • SSL v2
  • SSL v3
  • SSL v3.1 = TLS v1.0
  • SSL v3.2 = TLS v1.1
  • SSL v3.3 = TLS v1.2

TLS Handshake Protocol

The TLS Handshake its like a sub-protocol of the TLS protocol. Its purpose is to define the algorithms and keys to authenticate the parties, verify and encrypt the data.
I will analize the TLS handshake with the popular Wireshark sending a connection attempt with openssl and the next command:
openssl s_client -tls1 -connect www.google.com:443
This command establishes the connection between the server and client by HTTPS. The -tls1 argument forces the connection by TLS v1.0
I will use Google as the site for the test.
Let’s see the results.


After de DNS query described in the previous post the client usually starts the handshake sending the command “Client Hello” to the server. We can see that command in the packet number 12 of the above image. Look at the Source and Destination columns to see the direction of the packet.

Client Hello

The Client Hello command lets the server know the next things:

  • The version of SSL that the client is trying to use for negotiating with the server
  • Some random bytes generated by the client that will be used next to generate a master key for encryption.
  • A list of encryption algorithms called cipher_suites. The client tells the server which cipher suites it understands.
  • A list of compression algorithms supported by the client. If one of them is selected by the server the algorithm will be used to compress each message.
  • Optionally: A list of extensions that can be used to improve the security of the handshake. These extensions are not part of the protocol itself but, if the server understands the extensions, they will be used.

You can see a screenshot of this command in the next image.

Server Hello

The next command in the handshake is the Server Hello transmitted from the server to the client.
In this command the information sent to the client is:

  • Some random bytes now generated by the server that will be used to generate a master key.
  • The cipher suite selected by the server (from the previous list sent by the client) that will be used for authentication, encryption and verification of the messages
  • The compression algorithm selected by the server (again from the previous list sent by the client) that will be used for compressing each message
  • If a extension was accepted by the server it will notify to the client in the Extension tag

I will explain later in this post what the cipher suites are used for in detail.
Here you have the information sent during the Server Hello command

Certificate

The Certificate command is usually sent again from server to client. In this command the information transmitted is the list of certificates that the client needs to have in order to authenticate the server and to encrypt some information. This can be one, two or more certificates. In the image below you’ll see two certificates sent to the client. The first one was issued to www.google.com. The second certificate was issued to Thawte SGC CA. The common name in the first certificate must match the domain name we are trying to reach (with few exceptions like wildcard certificates).

Server Hello Done

Immediately after the Certificate message the server sends the Server Hello Done message. At this point the client has all the information it needs to generate the key material that both parties will need to encrypt the data. This key material is sent in the next handshake message…

Client Key Exchange

The client generates some bytes of data, encrypt them with the public key of the certificate it received and then sends the encrypted data to the server (this is called PreMaster secret and will be used to generate the Master secret). The algorithm by which the client protects the data is defined during the Client Hello and Server Hello messages. It can be RSA or Diffie-Hellman.

Change Cipher Spec

This is also sent from client to server indicating that the server MUST be prepared to receive the data in encrypted format and not in readable format because all the previous messages exchanged between client and server had been readable. This is the last message sent from client to server as readable. After this all the data sent to the server will be encrypted and we will not be able to read the contents with wireshark or any other sniffer tool. Proof of this is that in the below image the message after the Change Cipher Spec is an Encrypted Handshake Message.

Finished

This is the first message protected by the algorithms and keys negotiated between the entities (this is the Encrypted Handshake Messsage we saw in the image). Both client and server send the Finished message but the first to do it is the client. If the server receives the message and could decrypt and understand it, it means the the server is reading the encrypted information in the right way. Now the only missing part is that client could decrypt the information sent by the server. To do that the server must send a Change Cipher Spec message too followed by the Finished message in the encrypted way. Exactly the same as client did. Again if the client could decrypt the Finished message it means that both parties are in frequency and they can talk to each other protecting all the data in transit.


This is the last message in the TLS Handshake. From now the whole data will be sent encrypted.

Cipher Suites

Now, let me talk about the cipher suites listed above. If you review the image posted in the client hello section you will see a list. This list indicates the algorithms that will be used during the handshake and data transmission. The protocol needs 4 algorithms to work:

  • Authentication algorithm
  • Key Exchange algorithm
  • Bulk cipher algorithm
  • Message Authentication algorithm

These 4 algorithms are specified in the cipher suite.
Analyzing the first suite in the list we have the text: TLS_DHE_RSA_WITH_AES_256_CBC_SHA.

  • TLS: This is Transport Layer Security, the protocol we are using in the negotiation
  • DHE: Denotes Ephemeral Diffie-Hellman. Diffie-Hellman is an algorithm for key exchanging cryptographic keys. Diffie-Hellman in ephemeral mode enhances its security
  • RSA: This is the algorithm used for authentication. The most used algorithm in public-key cryptography (Rivest, Shamir and Adleman)
  • WITH_AES_256_CBC: Advanced Encryption Standard is one of the best algorithms used in symmetric cryptography. Its key size can be of 128 bits, 192 bits or 256 bits. In this case the key size is 256 bits. CBC stands for Cipher-block Chaining one mode of operation in encryption. It means that the algorithm will encrypt the bytes of data by blocks and then it will link the encrypted blocks like a chain.
  • SHA: Secure Hash Algorithm will be used for message authentication creating a hash of each block of the message to verify the integrity of such message.

In the next post I will talk about the certificates transfered between the two entities and how they can validate its authenticity.
Comments will be welcome.

5 thoughts on “HTTPS and the TLS handshake protocol.”

Comments are closed.