2

Reading: https://mulloverthing.com/how-does-ssl-protect-against-replay-attack/ it says:

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).

Which raises 2 questions for me. Let's say I listened to SSL encrypted message over TCP:

  1. Why I can't create the same copy of the message with the same old sequence number? Will TCP throw that package?

  2. What if UDP is being sent and not TCP, will it still be thrown away?

dan
  • 19
  • 1
  • During the TLS handshake both sides agree on a key (e.g. when TLS uses DH), so replaying only replaces one side which will end up in an error while agreeing on the key, because the side you don't control will not choose the same random values again. – Robert Jul 26 '22 at 07:33
  • If you repeat TCP seqnums (with _any_ data, same or different) TCP silently discards it. SSL/TLS (layered above TCP) only needs to deal with data that is 'new' at TCP level, but actually duplicate or otherwise wrong at SSL/TLS level. – dave_thompson_085 Jul 26 '22 at 10:09
  • Also neardupe but out of date https://security.stackexchange.com/questions/20105/are-ssl-encrypted-requests-vulnerable-to-replay-attacks – dave_thompson_085 Jul 26 '22 at 10:16

1 Answers1

2

Why I can't create the same copy of the message with the same old sequence number? Will TCP throw that package?

This is about the sequence number of the TLS record, not the TCP sequence number. TCP has no insight into the TLS records since they are encrypted and thus no decisions about dropping data can be made here. If the sequence number is not the expected then decryption will fail and the TLS session will be aborted at the TLS layer.

What if UDP is being sent and not TCP, will it still be thrown away?

TLS expects a reliably transport layer (no duplicates, packet loss, reordering), which UDP isn't.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • "TCP has no insight into the TLS records since they are encrypted" TLS encrypts only the data in first layer (application layer) So TCP has an insight. what do you mean by sequence number of the TLS record? I didn't find such a thing. are you referring to sequence number of TCP? In this case how Replay Attacks are prevented? – dan Jul 26 '22 at 06:51
  • @dan: *" So TCP has an insight."* - TCP has no insight into the encrypted payload and has no insight into replays at this level. *"are you referring to sequence number of TCP? "* - again, NO. *"what do you mean by sequence number of the TLS record?"* - See [RFC 8446 5.3. Per-Record Nonce](https://datatracker.ietf.org/doc/html/rfc8446#section-5.3). – Steffen Ullrich Jul 26 '22 at 08:34
  • TLS does not transmit its seqnum, but in 1.2 and below does include it in the authentication (MAC 'pseudo-header' on older suites, AAD on AEAD in 1.2 only), so if e.g. you take the seq 3 record and resend it as seq 4 (or 999) auth fails and the connection is terminated. OTOH _DTLS_ works over UDP, and sends the seqnum explicitly in an expanded header, which is authenticated in the same way as TLS. Only TLS 1.3 (which does not (yet?) have a DTLS equivalent) forces the seqnum into the nonce where it is (automatically) authentticated by AEAD. – dave_thompson_085 Jul 26 '22 at 10:10