CNS - 28 - TLS V

Lecture Info

  • Date: [2020-11-25 mer 11:30]

  • Lecturer: Giuseppe Bianchi

  • Slides:

  • Introduction: In this lecture we end with the basics of the TLS protocol.

1 Alert Protocol

The alert protocol is a sub-protocol used within TLS that is used to send error messages between client and server.

Some sample alerts are listed below, while for more information look for RFC224.

  • unexpected_message

  • bad_record_mac

  • record_overflow

  • handshake_failure

  • bad_certificate

  • certificate_unkown

If the error are fatal, the connection is terminated, otherwise if its a warning the client might decide to go on or simply to block the connection.

2 TLS does not protect TCP

Remember that TLS does not protect the TCP header, which is sent in plaintext without any message authentication. This means that anyone can kill a TCP connection.

While these can attacks can be real and dangerous, there is not much we can do about it from a TLS pov. Let's instead see another attack, the truncation attack.

3 Truncation Attack

In all our discussions about integrity we have always talked about message integrity. Let us now consider a broader view of integrity: session integrity. With this terminology we mean the integrity of the whole stream of messages that have to be sent from the client to the server.

Consider then a client which sends a message to a server using TLS. The message contains something like "sell 1000 google; buy 1000 amazon". An attacker could see the bytes sent (through the encrypted packages), and at some point could decide to send a TCP FIN packet to the server in the name of the actual, proper client, causing the natural conclusion of a TCP connection. We refer to this attack as a truncation attack.

Notice that this attack is not a DDOS attack, but is rather an attack to the integrity of the TLS session. This means that for a protocol to be completely secure we should not only make sure that the data is protected with encryption and message authentication. We also have to make sure that all the data the clients wants to send will be sent to the server, using a "all or nothing" approach.

3.1 Close Notify

To solve this problem the idea is to have an alert message (warning level) called close notifty that essentially does the same thing as a TCP FIN message, but inside the TLS session, and therefore using all security mechanisms offered by TLS.

This message informs the other party that there will be no more data after. With this we can easily detect truncation attacks.

4 Renegotiation

NOTE: What we are about to discuss in this section no longer applies to TLS v1.3. Still, we will present it anyways for teaching purposes.

We already mentioned that the original TLS separated the concept of a TCP session and that of a TLS sesssion. In particular at the start of the TLS session a full handshake was made, which resulted in the generation of the pre-shared secret. At the start of each TCP connection only a partial handshake was made, in which the pre-shared master secret was used to derive the master secret and all the secret keys needed for the connection.

While this approach works fine with short or medium lived TCP connections, there are a couple of situation which are not covered well, such as:

  • In the real world we often have very long TCP connections. We might thus want to a have a mechanism which allows us to change keys (re-keying) during the same TCP connection.

  • You may also want to upgrade your level of security during your TCP connection, that is you may want to change the cipher.

Because of these requirments the so-called renegotiation was introduce in TLS. It works as follows: after the first handshake, that is when the TLS session is already started and the data is already encrypted, you can do a renegotiation handshake. After this handshake a new TLS session is started which uses potentially a new cipher and a new key. With this approach we are able to break a single TCP connection into multiple TLS sessions.

Aside the fact that the renegotiation handshake is encrypted and its integrity is protected, in principle such handshake is not distinguishable from a the initial handshake. Can we use this to exploit the protocol?

4.1 Renegotiation Attack

Between August and September 2009 Marsh Ray, while doing a code review of a TLS implementation (PhoneFactor inc.) discovered a bug, and after contacting the company he made it publicly available on november 2009. Then, in mid november 2009, Anil Kurmus, a PhD student at ETH, turned the vulnerability into a pratical attack which basically stole twitter users credentials.

The bug allows to get a plaintext injection attack, in which the attacker is able to inject some data as if it were generated by the client. The attack works as follows: the attacker initially starts a TLS connection to a server, and then he intercepts the initial handshake of the client (through a Main in the Middle position already obtained), which he sends to the server as though it is a renegotiation handshake. Since the server cannot distinguish an initial handshake from a renegotiation handshake, he is unable to tell which data comes from the attack and which from the actual client, thus the data previously injected by the attacker is seen by the server as coming from the actual victim.

More in detail, the attacker does the following:

  1. It does a MITM attack to the client (victim)

  2. As soon as the victim starts a TLS handshake, the attacker grabs the relative packets, stops them from going to the server, and starts himself a TLS handshake.

  3. When the attacker has finished his TLS handshake, he is able to do a plaintext injection attack and inject some data.

  4. Then, when he has finished with this injection, he sends the client packets to the server that he previously stopped. The server seems them as a renegotiation handshake, and believes the data the attacker had previously sent was actually sent by the victim.

4.1.1 Preventing the Attack

As soon as the first actual attack was made public, they immediately disabled the renegotiation aspect of TLS.

Then in february 2010 they came out with a standardization patch with a renegotiation extension which introcued a new field that allows the server to recognize whether an handshake is cryptographically linked to the previous handshake. In the initial handshake this field is empty, while from the 2nd onwards it contains the fingerprint of the previous handshake message.

4.2 Prefix Data Injection

The things we are able to do a prefix data injection clearly depend on the particular application we're trying to exploit.

4.2.1 Example #1

Consider for example a pizza service, which is usually used by a victim client as follows 

GET /pizza?toppings=sausage;address=victim_address HTTP/1.1
Cookie: victim_cookie

An attacker using a prefix data injection vulnerability can inject the following 

GET /pizza?toppings=pepperoni;address=attacker_address HTTP/1.1
X-Ignore-This: (no carriage return)

This means that the final server sees this 

GET /pizza?toppings=pepperoni;address=attacker_address HTTP/1.1
X-Ignore-This: GET /pizza?toppings=sausage;address=victim_address HTTP/1.1
Cookie: victim_cookie

Where the second line is a comment.