In a TCP reset attack, an attacker kills a connection between two victims by sending one or both of them fake messages telling them to stop using the connection immediately. These messages are called TCP reset segments. In normal, non-nefarious operations, computers send TCP reset segments whenever they receive unexpected TCP traffic and they want its sender to stop sending it.
A TCP reset attack exploits this mechanism to trick victims into prematurely closing TCP connections by sending them fake reset segments. If a fake reset segment is crafted correctly, the receiver will accept it as valid and close their side of the connection. Fortunately, because it takes the attacker time to assemble and send their spoofed packet, reset attacks are only really effective against long-lived connections. Short-lived connections, for example those used to transmit small webpages, will typically have already fulfilled their purpose by the time an attacker is able to attempt to reset them.
The goal of the TCP protocol is to send a recipient a perfect copy of a piece of data.
However, the HTML is not sent over the internet in such a perfect, ordered form. Instead, it’s broken up into many small chunks(known as TCP segments) which are each sent separately over the internet and reconstituted back into the order in which they were sent by your computer’s TCP stack. This reconstituted output is known as a TCP stream, each TCP segment is sent in its own IP packet.
Reconstructing segments into a stream requires care, because the internet is not reliable. TCP segments may get dropped. They may arrive out of order; be sent twice; get corrupted; or have any number of other mishaps befall them. The job of the TCP protocol is therefore to provide reliable communication over an unreliable network. TCP achieves this goal by requiring the two sides of a connection to keep in close contact with each other, constantly reporting which pieces of data they have received. This allows senders to infer which data a receiver has not yet received, and to re-send any data that may have been lost.
In order to understand how this process works, we need to understand how senders and receivers use TCP sequence numbers to label and keep track of data sent over TCP.
TCP sequence numbers
Every byte sent over a TCP connection has an ordered sequence number, assigned to it by its sender. Receiving machines use sequence numbers to shift the data that they receive back into its original order.
When two machines negotiate a TCP connection, each machine sends the other a random initial sequence number. This is the sequence number that the machine will assign to the first byte of data that it sends. Every subsequent byte is assigned the sequence number of the previous byte, plus 1. TCP segments contain TCP headers, which are metadata attached to the start of a segment. The sequence number of the first byte in a segment’s body is included in that segment’s TCP header.
Acknowledging receipt of data
When a machine receives a TCP segment, it notifies the segment’s sender that it has been received. The receiver does this by sending an ACK(short for “acknowledge”) segment, containing the sequence number of the next byte that it expects to receive from the sender. The sender uses this information to infer that the receiver has successfully received all other bytes up to this number.
If a sender sends data but does not receive an ACK for it within a certain time interval, then the sender assumes that the data was lost and re-sends it, tagged with the same sequence numbers. This means that if the receiver receives the same bytes twice, it can trivially use sequence numbers to de-duplicate them without corrupting the stream. A receiver might receive duplicate data because an original segment arrived late, after it had been re-sent; or because an original segment arrived successfully but the corresponding ACK was lost on its way back to the sender.
Choosing a sequence number for spoofed segment