What Is SSL/TLS? How SSL, TLS 1.2, And TLS 1.3 Differ From Each Other?

SSL/TLS is so popular today. No internet communication works without it. Despite its popularity, many people still don’t know much about SSL/TLS. They failed to answer the basic questions like, what is SSL/TLS?. Are SSL and TLS the same? Which is the current version of the SSL/TLS protocol? How does SSL/TLS protect the Internet? We thought it is better to give some heads up about the basics of SSL/TLS. This article will answer all these fundamental questions about SSL/TLS, and we start from what is SSL/TLS protocol? History of SSL/TLS protocol and mainly TLS handshake process.

What is SSL/TLS?

SSL/TLS is a network encryption protocol that provides encrypted communication on the Internet. Netscape, a famous web browser company of 1990, first developed SSL and added that to their browser. Later it was termed as TLS by Internet Engineering Task Force with a group of companies, including Netscape and Microsoft. SSL 1.0 was never released to the public. SSL started its journey in 1994.  

SSL/TSL History:

The history of SSL/TLS goes back very early on to the says of the world wide web. Let’s see the journey of SSL/TLS in chronological order:

1. The journey of SSL/TLS began in 1994 when Netscape Navigator released SSLv2.
2. A few months later, Netscape identified a massive vulnerability in SSLv2, so they released SSLv3 in 1995.
3. In 1996, the Internet Engineering Task Force formed a group gathering several companies, including Netscape and Microsoft, to study standardized version of web browser encryption. The group decided to change the name from SSL to TLS in 1999. That’s how TLSv1.0 got released (RFC 2246). Technically, SSL v3 and TLS v1.0 are the same.
4. Researchers found several vulnerabilities in the TLSv1.0 protocol. It was also found that TLSv1.1 was prone to BEAST attack. A new version of TSLv1.2 (RFC 4546) was released in 2006, addressing all the vulnerabilities.
5. As days passed with some reforms, TLS v1.2 (RFC 5246) got released in 2008 and incorporated into all the major browsers in 2013.
6. TLSv1.3’s first draft was created in 2017 and released in 2018 (RFC 8446).

Cipher Suites:

It’s one of the vital things to know when you are dealing with SSL/TLS. Cipher suite is a set of algorithms that helps to secure a TLS session. One cipher suite is made up of three cryptographic algorithms.

1. Key Exchange Algorithm: This algorithm is used to securely exchange the symmetric key between the Client and the Server over unsecured public networks like the Internet.
2. Bulk Encryption Algorithm: Bulk encryption algorithms are used to encrypt the application data exchanged between the Client and the Server.
3. Message Authentication Code: This is used to perform the handshake integrity checks. This process takes a portion of header information from each message involved in the handshake process, combines them, and generates a digest message. This digest message will be shared with another party to make sure the handshake process hasn’t tampered.

Visit the link to know the supported cipher suites and protocol versions here: Supported cipher suites & protocol versions

DH Key Exchange Process:

Encryption is the main reason to use SSL/TLS. ‘Key’ is the primary entity in encryption. Encryption doesn’t work without keys. So we thought it is important to show the logic behind the key exchange.

Encryption protocols are majorly divided into two main classes—symmetric and Asymmetric encryption. Actual encryption happens in asymmetric encryption as it used two keys, private and public keys. 

Let’s see how key exchange happens in asymmetric encryption protocols:

Let’s assume ‘a’ is a private key of the Client. ‘b’ is a private key of the Server. Two large prime numbers, ‘p’ and ‘g’ are public keys that will be shared with both the Client and Server.

The mathematical formula to create an encrypted key is g^a mod p.

Phase #1:

Step 1: When the Client requests a connection to the Server. The Server sends a public certificate with ‘p’ and ‘g’ values.

Step 2: Client generates Client encryption key.

g^a mod p = A

Step 3: The Server generates its encryption key.

g^b mod p = B

Step 4: Both Client and Server exchange their encryption keys.

Phase #2:

Step 5: Both Server and Client use the same mathematical function to calculate the key.

Client key: B^a mod p = K

Server key: A^b mod p = K

K works as a symmetric key.

TLS v1.2:

As there is no significant difference between TLS v1.0, TLS v1.1, and TLS v1.2. On top of that, TLS v1.2 is more close to the universe. We thought it’s good to explain the TLS v1.2 handshake process. In TLS v1.2 there are plenty of messages move back and forth between Client and Server. We will look at those in the step by step process. For a detailed process, visit here: Decoding TLS v1.2 protocol Handshake with Wireshark

Step 1: The entire handshake process starts with the Client sending a “client hello” message to the Server. This message consists of cryptographic information such as supported TLS protocols, all supported Cipher Suites, 28-byte random number, UTC time, session ID, and URL of the Server.

Step 2: In response to the Client’s “client hello” message, the Server sends with “server hello” message. This message includes the highest supported TLS protocol, CipherSuite, that the Server has chosen out of the ones offered by the Client. The Server also sends its certificate along with the session ID, UTC time, and another 28-byte random number.

Step 3: The Client verifies the Server’s certificate. After the verification, it sends a random byte string, called “pre-master secret,” and encrypts it using the public key of the Server’s certificate.

Step 4: After the Server receives the pre-master secret, the Client and the Server both generate a master key along with session keys (ephemeral keys). These session keys will be used to symmetrically encrypt the data.

Step 5: The Client now sends a “Change Cipher Spec” message to the Server to let it know that it will switch to symmetric encryption using session keys. Along with it, it also sends a “Client Finished” message.

Step 6: In reply to the Client’s “Change Cipher Spec” message, the Server switches its security state to symmetric encryption. The Server concludes the handshake by sending a “server finished” message.

To complete all this process, it may take 0.25 to 0.5 seconds. In HTTPS, the initial half of the second goes into completing the TCP and TLS handshake protocol before exchanging the application data. That is why HTTPS sites would take a longer time to load than HTTP.

TLS v1.3:

The latest release of the TLS protocol is v1.3. The main idea behind this version is to reduce the time of the handshake process by reducing the back and forth messages between the Client and the Server. This shortened handshake process lets the exchange of application data to began in the way faster than older versions of TLS protocols.

Step 1: The TLS 1.3 handshake also begins with the “Client Hello” message as in the case of TLS 1.2. The Client off course sends the list of supported cipher suites and guesses which key agreement protocol the Server is likely to select. The Client also sends its key share for that particular key agreement protocol.

Step 2: In reply to the “Client Hello” message, the server replies with the chosen key agreement protocol. The “Server Hello” message also contains the Server’s key share, its certificate, and the “Server Finished” message.

Step 3: Now, the Client checks the certificate shared by the Server, generates symmetric keys as it has the key share of the Server, and sends the “Client Finished” message. From this point, both the Client and the Server start communicating by encrypting messages.

In TLS v1.3, the whole process is shortened from six steps to three steps. This saves approximately 25% to 50% of the time to complete the TLS process.

QnA:

• Decoding TLS v1.2 protocol Handshake with Wireshark
• A mathematical explanation of the Diffie-Hellman Key Exchange protocol:
• 15 key factors to find the most secure messaging app!
• Step by step procedure to enable key based authentication on Raspberry Pi:
• Step by step procedure to set up Open VPN on Raspberry Pi: