Web security: TLS

What is TLS? In this article you will learn how it works, how TLS protects HTTP traffic and how it differs from SSL.

Introduction

In the article How the Internet works we saw how the 4-layer system on which the sending of data on the Internet is based works. If you haven't read the article I recommend you do so in order to understand this one better. Have you read it yet? Great. As you may have deduced, any intermediary listening to the flow of information will be able to pick up those data packets and spy on their content. This, obviously, is a very big security and privacy issue.

The solution? Encrypt all data packets so that intermediate nodes can only intercept encrypted data that has no utility. And this is where TLS comes in.

TLS

TLS (Transport Layer Security) is a cryptographic protocol that adds security to the transport layer (hence the name). This is important, it should be clear that encryption is not added at the application level. That is, if you log into a web page using the browser, your data is not encrypted in the browser, it is encrypted at the transport layer. So HTTPS does not mean HTTP + TLS, it means that HTTP is on top of a transport layer (in this case TCP) that is cryptographically secure thanks to TLS. The order would be HTTP -> TLS -> TCP -> ....

TLS and SSL

In 1995, Netscape created the SSL (Secure Socket Layer) family of protocols. The purpose was mainly to provide the HTTP protocol with encryption, thus creating what we know as HTTPS. In the following years SSL was improved and advanced in version. It was in 1999 when the IETF (Internet Engineering Task Force) created and standardized TLS 1.0, a protocol very similar to SSL 3.0 that came to replace the SSL protocol family and thus avoid future patent problems. Since then, the various versions of SSL have become obsolete and today the TLS protocol has advanced to version 1.2 (although there is already a draft for version 1.3).

How TLS works

The TLS protocol has two functions: authenticate and encrypt.

SYNCLIENTACKClientHelloRequestSYN ACKSERVERServerHelloCertificateServerHelloDoneChangeCipherSpecFinishedResponseClientKeyExchangeChangeCipherSpecFinishedTCPSECURECONNECTIONTLS
Message flow known as handshake

Authentication between the client and the server is carried out in the process known as handshake. This procedure is performed in several steps, the first being exchanging supported TLS/SSL versions and the supported cipher suites. We will see later what these cipher suites are for. The server also sends the client its certificate based on the X.509 standard.

The client checks the validity of the certificate to ensure that the server is who it claims to be, and not someone intercepting the handshake process and impersonating the server.

After this, the server and client generate a symmetric master key that will be used to encrypt the data and exchange information securely.

Depending on the cipher suites and the order of preference specified by the server, one cryptographic algorithm or another will be used to generate the master key. Let's look at a couple of examples.

RSA

Using RSA, the client generates the master key and sends it to the server in encrypted form using the server's public key that was received with the certificate. Then the server, using its private key, decrypts the master key so that both know the key and can use it to encrypt future messages.

(EC)DH

Elliptic Curve encryption via the Diffie-Hellman cryptographic algorithm (EC-DH) is a cryptographic system that makes use of a different mathematical problem. In this case, client and server must collaborate to generate a master key using asymmetric keys.

This means that both generate a Diffie-Hellman key pair (a public key and a private key). Then, through the public keys, both reach an agreement and generate the symmetric master key that will be used to encrypt the data.

Perfect forward secrecy

Perfect forward secrecy (PFS) is a cryptographic term that guarantees that the discovery of a current master key does not compromise past communications.

Imagine that someone evil (let's call them the NSA) is dedicated to monitoring and storing all encrypted traffic over a TLS-protected connection. Okay, they can't read it, but... What's going to happen when the NSA manages to crack the master key? Exactly, they will have access to all the information. And this is worrying because in cryptography, what is difficult today will be very easy to solve in a few years. Remember the difference in power between a computer from the 90s and one of today.

Any cryptographic algorithm can guarantee PFS by changing the master key at each new connection. Even so, EC-DH is usually used because it is faster when generating keys. In this case we would be talking about ephemeral keys, so the exact system is known as (EC)DHE (E for ephemeral).

Thanks to this variant, a new Diffie-Hellman key pair is generated on each TCP connection, thus forming a unique master key for each session. If a master key is compromised, it will only affect the data shared on that connection. Thus, if the NSA wants to spy, it will have to carefully choose the traffic it wants to monitor, since decrypting one master key may be feasible, but thousands... is more complicated.

Enabling PFS on the server is simple, just enable ephemeral algorithms like (EC)DHE and disable all others. The problem is that, as of today, some older browsers do not support this algorithm and require RSA. By setting the order of preference and limiting (as much as possible) the use of non-ephemeral algorithms, we can guarantee PFS on most connections.

Conclusion

In this article we have seen in broad strokes how to guarantee a minimum of security both in the present and in the future using TLS.

You can support me so that I can dedicate even more time to writing articles and have resources to create new projects. Thank you!