9

Reading from this question Why does the SSL/TLS handshake have a client and server random?, the OP asks why he can't use the premaster secret directly and the accepted answer says:

... preventing any replay attack.

I don't understand why it can't prevent replay attack if I use the premaster directly.

The premaster is encrypted by the server's public certificate. A man-in-the-middle can't decrypt the premaster secret without the server's private key. So I think that would be secure.

Do I misunderstand something?

Rick
  • 1,027
  • 1
  • 8
  • 21

2 Answers2

10

I think you misunderstand what a replay attack is. You are correct that a MitM wouldn't be able to see the premaster secret, but an attacker can still cause trouble even if they can't decrypt anything.

Say you make a request to the server ordering a widget. There's a MitM between you and the server, but the request is perfectly secure, and they can't decrypt anything. Unfortunately, this is an alternate universe where the premaster secret is used directly.

The MitM sees you've made a request to store.example.com. They can't see what the request is, but they can see that it's to store.example.com (either due to the IP address or due to SNI). They can't see any of the decrypted communications, but they can see all of the encrypted traffic. Just for the fun of it, they take all the encrypted traffic you sent to the server, and they send it again, 10 times.

Now your card is charged 10 more times and a few days later you end up with 11 widgets instead of 1.

Now what would happen if an attacker tried that in our universe? (very simplified)

  1. The attacker sends a copy of the victim's traffic that it had saved
  2. In the Server Hello, the server replies with a different ServerHello.random
  3. All values the attacker sends that are based on the original ServerHello.random won't match
  4. When the server receives the Finished message and tries to verify it, it will fail, because the master secret calculated by the server is different (even though the premaster secret is the same)
  5. The server will abort the connection

The key point here is that there is some state on the server, the ServerHello.random, that is different for each connection, and the master secret depends on this state.

AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50
  • Thanks for replying. But I still don't get it. A replay attack as you described can happen whether I use the premaster directly. How does using the `premaster + randoms` make a difference to this attack? – Rick Sep 23 '19 at 03:10
  • @Rick Does that help? – AndrolGenhald Sep 23 '19 at 03:25
  • 1
    Ah, I see. Now I get the point. I didn't know that it needs a new connection for the MIIM attacker to replay the attack. And here it derives a new question: Why would the man-in-middle need a new connection to the server to replay the attack, can't he just simply for example, duplicate every ssl/tls encryped packets after handshake sent from the victim? – Rick Sep 23 '19 at 03:48
  • 1
    @Rick That could almost be a new question in itself, but the short answer is that the MAC for each record includes a sequence number, so re-sending the first record after the 1000th record would cause the MAC verification to fail. This also prevents an attacker from arbitrarily reordering, duplicating, or dropping records without causing the connection to fail. – AndrolGenhald Sep 23 '19 at 03:51
  • OK then I got the whole big picture. Knowing that "resending doesn't work" is so far enough for me. Then everything makes sense now. ;D Many thanks to your patience! – Rick Sep 23 '19 at 03:54
0

Here two types attacks are discussed in the question,

  1. man-in-the-middle attack: Someone try to steal the information that you have sent, this can be protected with encrypting the information before you send with your public key and whoever has the corresponding private key , they can only de-crypt the information.

  2. Replay attack: Suppose you are sending some request (even with encrypting the request) and receiving some response from server/client. Now replay attack is , someone who is not not authorize to get the response, copy your request and getting the same response!!. This can be prevented by keeping some sequence number for the request and sign the request itself. So every request shall be signed with the new sequence number included. Now the server/client can verify the signature of the request and validate the sequence number. Even if some one try to send copied message , it will get rejected from the other side since sequence number is not incremented. The sequence number mechanism mentioned here is just for illustration.

Shyju Thekkumbadan
  • 31
  • 1