74

Are SSL encrypted requests vulnerable to Replay Attacks? If so, what are good options to prevent this?

rreyes1979
  • 849
  • 1
  • 6
  • 3
  • Based on the question you posted here, http://security.stackexchange.com/questions/23607/replaying-ssl-traffic-in-an-active-connection that was flagged as a duplicate - just wanted to point out that it is possible for a man in the middle utilizing a proxy to decrypt the packets. – k1DBLITZ Nov 05 '12 at 14:33
  • Not sure what you want to tell us. Replays and MitM are unrelated. And MitM, with proxy or otherwise, only works if the client doesn't validate the server certificate correctly. – CodesInChaos Nov 05 '12 at 15:02
  • I thought it was pretty obvious. I was informing "us" don't make the assumption that SSL cannot be decrypted by a man in the middle. – k1DBLITZ Nov 05 '12 at 15:19
  • But 1) This question is not about MitM, it's about replay attacks. 2) MitM isn't possible when you use SSL correctly. – CodesInChaos Nov 05 '12 at 15:26
  • 3
    Did you actually read the other post? The scenario referenced a proxy server that someone had control over, aka, man in the middle. – k1DBLITZ Nov 05 '12 at 18:58

1 Answers1

54

The SSL/TLS channel itself is protected against replay attacks using the MAC (Message Authentication Code), computed using the MAC secret and the sequence number. (The MAC mechanism is what ensures the TLS communication integrity). See TLS 1.1 specification Appendix F.2:

To prevent message replay or modification attacks, the MAC is computed from the MAC secret, the sequence number, the message length, the message contents, and two fixed character strings.

EDIT: As @CodesInChaos points out, the handshake must also be taken into account, otherwise the whole TLS connection could be replayed (not just some records, which is what the MAC and sequence number would protect against). If an attacker replayed the same Client Hello message, the server would return a Server Hello with a different server random value thereby altering the rest of the key exchange. In addition, in RSA key exchange mode, only the initial legitimate client would know the pre master secret it has encrypted; in DHE key exchange mode, the client and server randoms are signed together in the server key exchange message (hence the importance of good random numbers there too). (There's a bit more on these two modes in this question.)

It's not clear from your question what you're trying to protect against replay attacks. Typically, this would be a message sent above the SSL/TLS layer, used by your application.

The encryption provided by SSL/TLS certainly prevents an eavesdropper from seeing that application request, and thus from replaying it with their own separate SSL/TLS connection.

However, SSL/TLS on its own doesn't necessarily prevent the legitimate initial user from replaying a request. Protocols and applications that require this additional level of protection tend to have nonce-based mechanisms at the application level to address this problem (which is rather independent of SSL/TLS, although preventing eavesdropping helps).

Community
  • 1
Bruno
  • 10,765
  • 1
  • 39
  • 59
  • 1
    While you're right that TLS protects against replay attacks, your explanation isn't very convincing to me. I know protocols which have everything you mention, and still suffer from replay attacks (at least when implemented naively). – CodesInChaos Sep 12 '12 at 18:52
  • @CodesInChaos, are you talking of the way TLS messages themselves are protected or at the application level? For TLS, I think a good MAC based on the sequence number should be sufficient to prevent replays, don't you? You just wouldn't process a message with the same sequence number twice. – Bruno Sep 12 '12 at 18:57
  • @CodesInChaos "_I know protocols which have everything you mention, and still suffer from replay attacks_" protocols implementing a message sequence abstraction? (ordered stream) – curiousguy Sep 12 '12 at 19:00
  • 3
    Details of the handshake are essential too, else an attacker can simply replay the whole connection. – CodesInChaos Sep 12 '12 at 19:02
  • @curiousguy I believe a naive implementation of [CurveCP](http://curvecp.org/packets.html) suffers from replay attacks. A well implemented server will avoid it, but it's easy to get wrong. (See "Issue 3" in [my blog entry on CurveCP crypto](http://codesinchaos.wordpress.com/2012/09/09/curvecp-1)) – CodesInChaos Sep 12 '12 at 19:05
  • Thanks Bruno for your reply. What I am trying to avoid here is an external agent to be able to replay a request to a REST API. I think having a working SSL connection between the client (javascript based) and the server should be enough to prevent that then. – rreyes1979 Sep 12 '12 at 19:21
  • @CodesInChaos, cheers for pointing out this omission (I've edited my answer). rreyes1979, yes, if your SSL connection is configured properly (including proper certificate verification to prevent MITM attacks). – Bruno Sep 12 '12 at 19:27
  • 3
    For reference, MAC here means "Message Authentication Code". Googling "TLS MAC" will get you lots of results about Macintosh and Layer 2 media access control addresses – Bacon Bits Jun 03 '16 at 19:42
  • By "sequence number" in your answer, do you mean the TCP layer sequence numbers? If so, does that mean the OS TCP stack layer is somehow responsible for prevention of replay attacks in TLS? So I afraid if in a specific OS, the TCP stack implementation works in way that it passes the payload of repeated packets (equal SEQ numbers) to application layer, then the OS is vulnerable to replay attacks for TLS traffic. Am I right? – Ebrahim Ghasemi Jan 12 '19 at 20:09
  • 1
    @Abraham No, I meant the sequence number as defined in the TLS specification (it's a quote from that spec). – Bruno Jan 13 '19 at 00:18
  • OK, Thanks. So, would you please check this: https://blog.valverde.me/2015/12/07/bad-life-advice/#.XDpHS1wzZPY How much is this attack serious? Is it practical? – Ebrahim Ghasemi Jan 13 '19 at 04:44