2

In the Finished handshake of TLS all previous messages exchanged are sent from the client to the server (and reverse) and protected by a MAC. This is what also "prevents" TLS_FALLBACK_SCSV from being modified/deleted by an attacker.

But attacks as Freak and Logjam use downgrade attacks. E.g. as explained in a Cloudflare blog:

A MitM attacker intercepts a client connection and replaces all the accepted ciphersuites with only the DHE_EXPORT ones

So when the integrity and authenticity of the Client hello (and other messages, but this may be the most important here) is protected, how can it be modified in attacks like Freak and Logjam where Export cipher suites are forced?

rugk
  • 1,237
  • 1
  • 13
  • 25
  • Okay, possibly [Does TLS_FALLBACK_SCSV provide blanket protection against downgrade attacks?](https://security.stackexchange.com/questions/89834/does-tls-fallback-scsv-provide-blanket-protection-against-downgrade-attacks) already answers this. However if you can find a better or more generic answer, please answer here. – rugk Feb 21 '16 at 11:16

1 Answers1

2

After reading some docs I finally can answer my own question.

Basically I had a misunderstanding. It is important to know the "TLS Record Protocol". This protcol is the base of TLS and is always used. At the beginning for the Handshake and at the end when the Handshake finished and the data is transmitted over TLS (when using HTTPS this is HTTP). TLS Record (taken from the German Wikipedia article on TLS; CC-BY-SA 3.0)

However at the beginning there is obviously no encryption or HMAC the client and server can use to secure the exchanged messages as they have not agreed on using a cipher yet (this is done in the Handshake). So they have to use a cipher without any encryption and integrity protection. This is TLS_NULL_WITH_NULL_NULL. After the record layer is initialized with this cipher, which basically offers no protection, the handshake can begin.

So the hello messages of client and server are therefore unprotected and an attacker can tamper with them. To protect the whole process the Finished messages (which are exchanged at the end of the handshake) contain a hash (HMAC) of all previous sent messages and therefore allow client and server to verify the integrity of these messages.

In SSL 3.0 up to TLS 1.1 a combination of MD5 and SHA-1 is used. In TLS 1.2 the HMAC defined in the cipher is used. Further details are explained here. The issue is that the key used in the HMAC and the HMAC itself can be weak. E.g. could the HMAC be using a MD5 hash (as in the SLOTH attack against TLS 1.2). This was also explained by the discoverer of the SLOTH attack (specifically look a slide 8). They conclude:

The TLS downgrade protection mechanism itself depends on downgradeable parameters.
- hence, the only fix is to find and disable all weak parameters: groups, curves, mac algorithms,...

How the downgrade attacks on EXPORT ciphers work in detail is explained in this answer.

rugk
  • 1,237
  • 1
  • 13
  • 25