Can an HTTPS request be sent twice?

Question

When sniffing network traffic, one can see an HTTPS packet and all its (encrypted) data. I am wondering what would happen if this packet is copied and then re-sent.

Is there a protocol at some layer that prevents the same packet being used twice? (with something such as a timestamp maybe) If not, how should the server side defend against it?

If the entire TCP pack is sent twice, it would just be discarded by the recipient. — , Oct 23 '21 at 13:35
thanks @MechMK1. But what if a new TCP packet is created, and only the application layer data is copied within it? — Reedy, Oct 23 '21 at 13:53

Steffen Ullrich · Accepted Answer · 2021-10-25T12:36:36.573

36

There are multiple mechanisms to detect duplicates.

At the TCP level there is the sequence number sent within each TCP packet, which allows to detect if a packet was received twice, or more generally if it overlaps with already received data. This is not actually a security feature but to detect packet reordering, duplication and loss and this way provide a reliable transport layer on top of an unreliable network layer. If such a duplicate gets detected it will simply be discarded.
At the TLS level no sequence number are explicitly sent on the wire, but sequence numbers are still maintained inside the TLS state of each peer and are included in the computation of the payload protection. Thus TLS has a replay protection by design - see TLS sequence number for more. Since a successfully replayed packet essentially means that an attacker was able to actively fiddle with the underlying reliable TCP connection, this connection will usually be treated as compromised and abandoned.
Additionally each new TLS session results in a different encryption key, i.e. the server would not be able to decrypt a HTTP request sniffed from a different TLS session in the first place. Thanks to user253751 pointing this out in a comment.

edited Oct 25 '21 at 12:36

answered Oct 23 '21 at 15:49

Steffen Ullrich

184,332
29
363
424

1

A TCP/IP client or server would only discard a duplicate packet if it had also received a later packet in the same connection, or if timing suggests retransmission would be useless. Otherwise, it would respond to the duplicate packet by retransmitting any data it would have sent in response to the original, sometimes with additional information that has become available since the original was sent. – supercat Oct 24 '21 at 04:39
1

@supercat: I think you refer to TCP fast retransmit here. This is not about the duplicate packet with same payload though, it is about duplicate ACK only - i.e. the payload is irrelevant and can even be empty, only the ACK is relevant. See for example [here](https://www.isi.edu/nsnam/DIRECTED_RESEARCH/DR_WANIDA/DR/JavisInActionFastRetransmitFrame.html) for details. Still, if payload for the same sequence is received again this gets detected and the payload discarded. – Steffen Ullrich Oct 24 '21 at 05:27
1

See also: https://security.stackexchange.com/questions/20105/are-ssl-encrypted-requests-vulnerable-to-replay-attacks – usr-local-ΕΨΗΕΛΩΝ Oct 24 '21 at 13:43
4

Also if you tried it on a new connection, the server would send different randomness so your copy-pasted key exchange wouldn't work. – user253751 Oct 25 '21 at 07:34
1

@user253751 And I suspect that may even be what the original poster was actually willing to know. The body of the question only seem to talk about individual packets, but the title is "Can an HTTPS *request* be sent twice?", and the answer to this would be exactly your comment. I am pretty sure OP confuses the packets and the entire connection. – dim Oct 25 '21 at 10:54
@user253751: Good point. I've added it to the answer. – Steffen Ullrich Oct 25 '21 at 12:36
1

Worth noting that TLS 1.3 has a 0-RTT feature that doesn't prevent replay. I've added an answer that mentions this. – paj28 Oct 25 '21 at 21:15

score 3 · Answer 2 · answered Oct 25 '21 at 21:14

In general, no - the TLS protocol prevents replay attacks, so if data was copied and resent, it would be discarded.

There is one exception to this, a new feature in the TLS 1.3 protocol - 0-RTT. This is a performance enhancement, that comes at the cost of the protocol not preventing replay attacks in some circumstances. In theory, systems that allow 0-RTT will have application-layer defences against replay attacks. However, this creates a risk that applications might allow 0-RTT but have inadequate defences. I've no idea if 0-RTT vulnerabilities are something we might see in the wild, but this is a potentially interesting area of research. More info

score 1 · Answer 3 · answered Oct 25 '21 at 20:29

No, this will not work. By 'Packet' I assume you are just describing some data that is in a request over TLS, which can be split into multiple TCP packets sent to the server. This could be just sending something you received over a hijacked TCP connection that is already encrypted or by replaying a whole session you've recorded from start to finish starting with the TCP connect.

In the first case, the server's encryption state will not be the same as when the data was received the first time. If you encrypt 'Hello' at one point in the data stream, it will not be the same as if you encrypt 'Hello' at a later point. You might as well be sending random bits.

If you're replaying an entire connection, that won't work because of the way the handshake occurs. Each new connection has sets of random bytes generated by the client and by the server. These random bytes are used to generate the keys used for actual encryption of the later data. You would have to get lucky and have the same random bytes be generated on the server for your new connection as for the previous one you are trying to replay.

Can an HTTPS request be sent twice?

3 Answers3