2

A message authorization code is used in TLS to prevent man-in-the-middle-attacks that involve tampering with the contents of the packet in-flight. However, there is one specific attack which I don't see covered.

At one stage of the TLS handshake, the client sends the server a private randomly generated proposed symmetric key which has been encrypted with the server's public key. A man the middle cannot decrypt that value and learn the value of the symmetric key because it does not possess the private key. However, it can swap the contents of the message with its own private symmetric key, and send that message to the server instead.

The message authorization code (MAC) can supposedly prevent this from happening:

If we agree on a key and hashing cipher, you can verify that my message comes from me, and I can verify that your message comes from you.

[...]

An attacker can modify the message but does not know the key. He cannot compute the correct MAC, and you will know the message is not authentic.

What if an attacker generates their own symmetric key, encrypting that value with the public key, setting that value as the data payload, setting the MAC to the corresponding value for the new proposed symmetric key, and sends that to the server?

If my understanding is correct, the server will decrypt the message payload using its private key, verify message integrity using the MAC, set that to be the shared secret symmetric key value, and respond to the "client" (really, the attacker) with the data payload "Finished" encrypted with that key. In essence, the server now has a shared secret with the attacker, who it thinks is the client.

Not knowing the original secret symmetric key, the man in the middle cannot actually forward the server response to the client. Nevertheless, at this point the man in the middle can make requests to the server, whilst masquerading as the client.

Does TLS actually protect against this somehow?

Aleksey Bilogur
  • 123
  • 4
  • Side note - RSA key exchange has fallen out of favor, and it's removed in TLS 1.3. – AndrolGenhald Aug 30 '19 at 23:20
  • My reading is that TLS only protects against this if you use mutual TLS. – Aleksey Bilogur Aug 31 '19 at 00:18
  • 1
    Ah, I think I actually misunderstood your question. Reading it again though I'm not sure I see what the concern is, isn't this essentially the same as blocking the victim's connection and the attacker creating their own connection? The server doesn't really know who is connecting either way. Identification of the client _can_ happen with client certificates, but usually it happens at a higher layer with username & password (& possible 2nd factor) after the TLS session has been established. – AndrolGenhald Aug 31 '19 at 01:21

1 Answers1

2

Does TLS actually protect against this somehow?

Why would it? All that you've done there (as the "attacker") is connect as a client yourself, with a completely incidental side of denial-of-service for another client. Unless you're using client certificates (mutual TLS), anybody can establish a connection to the server. You won't see any secrets from the client, because they aren't going to have a TLS connection to the server so they won't send any requests that might contain credentials, session tokens, or other sensitive data. You won't see any secrets from the server (aside from possibly your own) because you haven't authenticated yourself, so the server isn't going to tell you anything sensitive.

If you are using mutual TLS, well, you don't know the client's private key (for that matter, if you tamper in this way, you probably won't even learn their public key because the client won't go through with the handshake) so you cannot offer the signed token that is used to prove identity in mTLS. Without that, the server will either reject your handshake entirely, or ask you to authenticate in some other way, and again, you don't know the "legit" client's auth secrets (or any others).

CBHacking
  • 42,359
  • 3
  • 76
  • 107
  • My reading of the wording of [High Performance Browser Networking](https://hpbn.co/transport-layer-security-tls/#tls-handshake) implied that MAC protects against message tampering, period. Without mutual TLS, I could not see how that was possible, which made me feel that I was missing something. But as you and @AndrolGenhald have pointed out, in that case authenticating the client is an application-level concern. Now I know! – Aleksey Bilogur Aug 31 '19 at 02:54
  • 1
    MAC requires having already established a shared key. It's used for protecting the messages passed through the TLS channel, not for protecting the handshake used to establish the channel. That is done, if it is necessary to do it at all, with cryptographic signatures; for example, in Diffie-Hellman key exchanges (with or without elliptic curves) the server signs its DH parameters with its private key so the client knows they haven't been tampered with. The client has no need to sign (or MAC) its own parameters, for the same reason as in the answer. – CBHacking Aug 31 '19 at 08:05