The TLS/SSL and the TLS/SSL Handshake

TLS is the acronym for Transport Layer Security and it is applicable to everything that runs under communication protocols, or protocols that rule the communication between parties, such as HTTP, FTP, TCP/IP, or SMTP protocols.

TLS is an improved protocol intended to replace the Secure Sockets Layer protocol, better known as SSL. Although they are not exactly the same, they are also not that different. Both were outlined for a similar purpose, and TLS took all the best practices and implementations of the SSL. They were considered synonyms as both were alternative security protocols for a long time, but nowadays the SSL protocol is being rapidly phased out after some vulnerabilities were found.

Both, TLS and SSL, are concerned with the full transmission of data through a secure layer, usually understood as a “tunnel”.

But before that tunnel is created, the parties must agree on how the data going through that tunnel should be protected. The challenge is that that agreement has to be reached through an already public channel prone to data interception and monitoring.

Data exchange on the public Internet is like throwing a piece of paper with your private bank details from one point to another in a shopping mall on a busy Black Friday

The Handshake protocol is a sub-protocol of he TLS/SSL to formalize that agreement. In other words, it is the protocol where the parties agree upon the same rules of confidentiality between the both, while preventing others to know some of the terms of that agreement.

We are going to broadly examine the Handshake protocol from one of its variants, the TLS 1.2 version. The 1.2 version is still widely used, although bear in mind that the newest version of the TLS protocol, version 1.3, considers that variant already outdated.

Let’s start by describing the main characters.

The Parties

The whole Handshake protocol focus on three participants: the Server, the Client, and the Certificate Authority.

The concept of Server might not be that ambiguous for someone without previous technical knowledge; it is easy to relate that to a machine.

The concept of Client could be less clear for the initiated, but the whole protocol doesn’t give room for doubt: like the Server, the Client is a machine. A program, to be more precise. A program that resides on a computer that would make the first contact with the Server, usually on behalf of someone else, like a user (you, for example).

So both, the Server and the Client are machine/software applications, not people.

The Client is the one who would start that communication because it is looking for a service (e.g., data resources) that the Server could provide.

The only actual entity is the Certificate Authority. Although we are not going to talk much about the Certificate Authority, keep in mind that it is a fundamental figure for the whole thing to work. The Certificate Authority is a truthworthy organization that acreditate the legitimacy of other organizations by providing a virtual certificate.

(An example of a Certificate, source: Wikipedia)

Now, keeping in mind that we are talking about machines, let’s turn our focus on to the steps they have to follow in order to reach data security.

Handshake Steps

The usual diagram of the TLS / SSL Handshake protocol (TLS 1.2) is like following:

(source: Wikipedia)

Notice that the diagram shows 4 relevant exchanges:

  1. When the connection is requested (the TCP/IP connection)
  2. The Hellos
  3. The Client Key Exchange (generation of session keys)
  4. The Application Data

The Handshake (TLS 1.2) is better described by the two in the middle: the Hellos and the Client Key Exchange. Let’s talk about those two.

The Hellos

The Hellos of TLS v1.2 contain the terms and pieces required for the eventual data protection mechanism. The interesting part of this exchange is that it is totally public. At this stage, there is no harm if the information is visible. The data protection procedure will make use of several pieces of information contained in those messages, but at this point it is not important if someone sees them; they won’t work without other still non-existing information that will be kept secret to others, partly because it will be exchanged in a protected format at a different step. It is also true that everyone could modify the values, but there will be ways to detect that too.

The Hellos are two:

  • The Client Hello
  • The Server Hello

Client Hello

To start the Handshake, our Client sends some information into the public Internet hoping that it will reach the intended Server.

In general, the “letter” sent to the Server is very basic, and of no harm for the concerned parties. You can interact with the following image if you want to know more :D.




So, our Client sends that Hello letter with the client random and waits.








Server Hello

That was the client hello but what happens on the other side? The server also responds with a “hello” letter.

Let’s see what it contains. You can interact with the following image if you want to know more :D.




So, our Server sends back a Hello letter to the Client. Immediately after it sends a message indicating that this is all to be shared in the Server Hello, and waits.

Final Remarks

In this post we went over part of the handshake procedure (TLS/SSL v1.2) but it doesn’t end here. In another post we will explain some aspects of the next step: the generation of the session keys, the ones that will allow the Server and the Client to encrypt the exchanged data.

For the preparation of this post I made use of an Inkscape’s add-on called Xia.

I just hope you enjoyed this reading. Meanwhile, happy coding!