4

When an HTTPS conversation is initiated, a random number is generated to create a key for the exchange (or something like that). What I don't understand is how this prevents replay attacks.

Why can't an attacker just repeat all the requests that the real client made?

This answer claims it isn't possible, while this answer claims the opposite. I can't see how an attack wouldn't be possible, unless there were nonces involved.

Community
  • 1
  • 1
Chris Middleton
  • 5,654
  • 5
  • 31
  • 68
  • Because the requests wouldn't make sense, being based off a different random seed? – TZHX Mar 01 '15 at 10:49
  • @TZHX Why can't I, the attacker, just send the sniffed encrypted cookie and be connected? How would the other side know I wasn't already "connected"? (I'm know my understanding is wrong, so please know that these questions are just to increase my understanding, not to imply the premise of these questions is correct) – Chris Middleton Mar 01 '15 at 10:54

1 Answers1

5

The answer is here, courtesy of @Emirikol: https://softwareengineering.stackexchange.com/a/194668/245162

HTTPS can be enough to secure the server from replay attacks (the same message being sent twice) if the server is configured to only allow the TLS protocol as per RFC 2246 section F.2.

This is done through the use of Message Authentication Codes (MAC).

Also see: https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail

Adrian K
  • 9,880
  • 3
  • 33
  • 59