Man in the middle interfering with TLS handshakes?
The handshake is unencrypted so you can modify the messages to make it look like the server only supports broken ciphers. Then the man in the middle can read all of the encrypted data because it was badly encrypted.
A surprising number of servers still support broken ciphers due to legacy uses or incompetence.
No: while the handshake is unencrypted, it is authenticated. An attacker can’t modify it.
What an attacker can do is block handshakes with parameters they don’t like. Some clients would retry a new handshake with an older TLS version, because they’d take the silence to mean that the server has broken negotiation.
well, unless both client and server have sufficiently weak crypto enabled that an attacker can break it during the handshake.
Then you can MITM, force both sides to use the weak crypto, which can be broken, and you're in the middle. Also not really so relevant today.
You could encrypt the handshake that you recieved with the server's certificate and send it back. Then if it doesn't match what the server thought it sent it aborts the handshake. As long as the server's cert isn't broken this would detect a munged handshake, and if the server's cert is broken you have no root of trust to start the connection in the first place.
How do you agree a protocol to encrypt the message to agree the protocol?
This is the message that returns a list of supported ciphers and key exchange protocols. There’s no data in this first packet.
Alice: I’d like to connect Bob: Sure here is a list of protocols we could use:
You modify bob’s message so that bob only suggests insecure protocols.
You might be proposing that Alice asks Trent for Bob’s public key … But that’s not how TLS works.
Bob's list of supported protocols is an input into the (authenticated) final handshake message, and that authentication failing will prevent the connection from being considered successfully established.
If the "negotiated" cipher suite is weak enough to allow real-time impersonation of Bob, though, pre-1.3 versions are still vulnerable; that's another reason not to keep insecure cipher suites around in a TLS config.
The fine man in the middle could still intercept that.
Yes, this is a seriously difficult problem with only partial solutions.
The basic math of any kind of negotiation is that you need the minimum set of cryptographic parameters supported by both sides to be secure enough to resist downgrade. This is too small a space to support a complete accounting of the situation, but roughly:
- In pre-TLS 1.3 versions of TLS, the Finished message was intended to provide secure negotiation as long as the weakest joint key exchange was secure, even if the weakest joint record protection algorithm was insecure, because the Finished provides integrity for the handshake outside of the record layer.
- In TLS 1.3, the negotiation messages are also signed by the server, which is intended to protect negotiation as long as the weakest joint signature algorithm is secure. This is (I believe) the best you can do with a client and server which have never talked to each other, because if the signature algorithm is insecure, the attacker can just impersonate the server directly.
- TLS 1.3 also includes a mechanism intended to prevent against TLS 1.3 -> TLS 1.2 downgrade as long as the TLS 1.2 cipher suite involves server signing (as a practical matter, this means ECDHE). Briefly, the idea is to use a sentinel value in the random nonces, which are signed even in TLS 1.2 (https://www.rfc-editor.org/rfc/rfc8446#section-4.1.3).