CNS - 16 - TLS I

• Date: [2020-10-26 lun 14:00]

• Lecturer: Giuseppe Bianchi

• Slides:

• Introduction: With this lecture we start the 2nd part of the class, in which we will focus on a deep analysis of a single protocol, namely TLS, the protocol used for the security of the web.

The three most famous network security protocols are ssh, tls/ssl, ipsec. We will now start analyzing the second one, tls. A very good book on the subject is "SSL and TLS essentials" (2000), by Stephen Thomas.

The History of SSL/TLS can be sumrised as follows:

more in depth:

• In 1993 the web came out storngly with the browser released by mozilla. Right after that the company that developed netscape defined a protocol called Secure Socket Layer, with version SSL v1 defined in 1994. This version however was never released.

• The first released version of SSL was SSL v2, and it came out in 1995, in netscape 1.1. This version was badly broken immediately upon release.

• Understanding the mistakes made, in 1996 netscape proposed a new version of SSL, SSL v3. Conceptually speaking this version was well designed, and it still serves as the basis for the current version of the TLS protocol, which is TLS v1.3.

• The SSL protocol, which was a proprietary protocol, was then submitted to the IETF in order to standardize it. The resulting standardized protocol was released in 1999 and was named Transport Layer Security (TLS). A part from a few differences, TLS v1.0 is pretty much equivalent to SSL v3.1.

• Up to this point TLS was used only for web security, that is only for the HTTP protocol. This is why the names SSL, TLS and HTTPS are pretty much the same thing. Since HTTP ran over TCP connections, it meant that TLS implicitly assumed that the connction was reliable. It turned out that if you ran TLS v1.0 over an unrelabile communication channel, then the protocol broke down. To fix this problem in 2006 a new version of TLS was introduced, TLS v 1.1, as well as a different version of TLS named DTLS, which was made to work over unreliable (UDP) connections.

• The next version of TLS, TLS v1.2 was released in 2008. In this version they decoupled the protocol from using specific hash-functions (such as MD5/SHA-1) , which were broken by that time.

• Then, in 2018, a complete overhaul of the protocol was made to get TLS v1.3. This version is the first version of the protocol that guarantess the so-called perfect forward secrecy property.

The two main protocols for software security, which are IPsec and SSL/TLS run at two different levels of the network software stack:

• IPsec: runs on top of IP before the transport layer, that is the IPsec packets are held inside IP packets. IPsec is also used to protect the IP packet itself. In IPsec you have no specific notion of which transport protocol you're using; it protects all packets which are sent by your network card.

  

• SSL/TLS: TLS was born to protect a specific service, which was the web service (HTTP protocol). This means that SSL/TLS sits in btween the HTTP protocol and the transport protocol (TCP). Notice that TLS does not protect the transport protocol: TCP remains unprotected, and thus an attacker can potentially modify it.

  

Observation 1: When you use openVPN, which is a TLS based VPN, the idea is that you use TLS to create a secure channel in which to send other IP packets. This is the concept of tunneling.

Observation 2: There are various reasons for why TLS is much more known than IPsec. Some of these are:

1. TLS runs user space;

2. TLS is much simpler to configure;

3. IPsec comes from the networking domain;

4. If you use TLS tunneling you can also protect the IP stack;

Observation 3: If you remember the OSI stack, TLS is a good example of a session level protocol.

Observation 4: Even though initially TLS was limited to Internet Transport, it can be transformed to secure any point-to-point communications in general.

Observation 5: There is a big difference between EAP-TLS and EAP-TTLS. With the second you create a tunnel in which you exchange security credentials. With the first one instead you use TLS to exchange certificate.

When creating a socket with TCP/IP you specify your IP address as well as a port number, which acts as an identifier for the service you are actually launching. For instance HTTP runs on port 80. When you're writing http://www.uniroma2.it you are implicitly using port 80.

The correct approach for encapsulating TLS messages would be the following: you have a TCP packet which contains a TLS packet, and the port number is actually not written in the TCP packet, but rather in the TLS packet.

For historical reason however this approach was not taken at all. What the original implementors of TLS did was the following: they decided that if you wanted to use HTTP you would use port 80, and if you wanted to use TLS you would use port 443. They have thus duplicated the port number: one for HTTP and one for HTTPS. HTTPS is thus HTTP over TLS.

Thus, the way in which applications are supported in TLS, for historical reasons, are based on duplications of port: the non secure version and the secure version.

Observation: IPsec managed the encapsulation in a much better and cleaner way, because it doesn't allow the attacker to know which protocol or which application you are using. With IPsec you thus have a traffic flow confidentiality, which is defined as follows: an adversary which looks at your packets should not be able to tell which protocol or which service you are using.

When you want to create a secure session also known as a security association between two-endpoints, you have to do the following two things:

1. Establish a session;

2. Transfer application data

The TLS approach is so-called two-in-one, because upon every connection both things are done. This means that anytime you connect to a web server using HTTPS both things are done:

1. TLS Handshake phase: used to setup the session:

   • Agree on which algorithms to use

   • Share the secret keys used for encryption

   • Perform authentication

2. Transfer application data:

   • Communication privacy with symmetric encryption

   • Data integrity with Keyed Message Authentication Code (HMAC)

The protocol stack of TLS can be visualized as follows

As we can see, TLS typically runs on top of TCP. It then uses the TLS Record Protocol as a format to exchange data. On top of it you can run:

• Application data, which is general.

• Handhsake Protocol, which is used to establish session and initialize communication.

• Alert Protocol, which defines a basic way to handle errors.

Its important to note that the format of the TLS Record Protocol changed significantly from TLS v1.2 to TLS v1.3. Having said that, we will still mention this because in this course we are not interested particulary in the latest version of TLS, but rather on how to design protocols. We will thus implicitly assuming that the version of TLS we're working with is TLS v1.2.

To construct the record protocol, the following operations are executed in order

Even though from an application point of view these operations seems totally fine, from a security point of view they actually made two huge erors. These errors are:

• Doing the compression before the encryption turned out to be problematic and was exploited by an attacked named CRIME in 2012.

• Adding the MAC before encrypting also turned out to be problematic, and was exploited multiple times throughout the years by the so-called PADDING ORACLE ATTACK.

In TLS v1.3 they decided to only supported AEAD. That is, they are not allowing anymore to seperate the adding of MAC and the encrypting of the message. Now both things have to be done at the same time.