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).
(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.