Transport Control Protocol, or TCP, is in the “Transport” layer (Transport Layer) of the TCP/IP model, or layer 4 of the OSI Model.
TCP makes sure that two applications are able to send and receive data in a reliable and error-checked way. Among other things, the TCP protocol defines how to initiate a connection (such that data can then be sent). This step is called the “TCP handshake” or “3-way handshake.”
The 3-way Handshake
A server and client would like to transfer data between them; first, they must establish a connection.
The server starts with a “passive open,” meaning that it is listening for communication on a given port.
SYN
The client then initiates an “active open” by sending a SYN message to the server. To do so, it, picks a (random) Initial Sequence Number, or ISN. It then creates a TCP segment and sets the headers to include the ISN (for example, ISN_client = 1000). It also sets the SYN flag to 1 to synchronize with the server, and the ACK flag to 0, as there’s no need for acknowledgment yet. Then, it sends this segment to the server.
SYN-ACK
At this point, the server can reject the request, or accept (acknowledge) it. Let’s assume the server accepts. It will then send back a SYN-ACK message. Like the client earlier, it choses a random Sequence Number (for example, ISN_server = 3000). Then, it creates the TCP segment to represent the SYN-ACK message. This includes the SYN flag set to 1, as it is synchronizing with the client. It also includes the ACK flag set to 1 because it is acknowledging the client’s message. The server also sends back an Acknowledgment Number, which is the client’s ISN + 1 (in this example, 1001). Lastly it includes the random sequence number as its own ISN.
ACK
Finally, the client receives the SYN-ACK, and will need to respond back to the server. It sends an ACK message. To do so, it creates a TCP segment that acknowledges the server’s ISN by sending back an Acknowledgment Number equal to the server’s ISN + 1 (in this example, 3001). It also sends back a Sequence Number, which is the Acknowledgement Number previously sent by the server (ex: 1001). It sets the SYN flag to 0, and the ACK flag to 1. Then, it sends it to the server for the third and final part of the handshake.
Tada! We’ve got a connection!
So to recap, that’s:
- Client sends SYN = 1, ACK = 0, ISN = 1000 to server.
- Server sends SYN = 1, ACK = 1, ACK # = 1001, ISN = 3000
- Client sends SYN = 0, ACK = 0, ACK # = 3001, SEQ # = 1001
Now the client and server have established full-duplex communication (meaning they can transmit information simultaneously, in both directions at once).
In reality, the sequence and acknowledgment numbers would be bigger, and would be randomly chosen. TCP segment headers have 32-bit fields for both the sequence and acknowledgement numbers (so the example numbers were a little small).
Why not a 2-way?
There are a few reasons why we need a three-way handshake–instead of just having the client send a SYN message and the server ACKing back. Our goal is to establish 2-way communication (full-duplex).
Each side must be sure that it can send data to the other side. The client must send data to the server and get some kind of message (acknowledgement) back that proves that the original message was sent (ISN + 1).
If this two-way handshake (SYN->ACK) happens correctly, it will only prove out communication in one direction: from client to server. To get two-way communication, we need to do another two-way handshake, this time with the server sending the SYN message and the client ACKing. This will prove out communication in the other direction.
Thus, the 3-way handshake is really two 2-way handshakes, with the middle step getting combined (into SYN-ACK).
Why do we need the ISNs? TCP uses sequence numbers to ID each byte so that the recipient can reconstruct the data and put everything back in the right order. For those of you who remember older cell phones with the numbered text messages (1/4, 2/4, etc): not having a sequence number would leave you to have to reconstruct the order by guessing.
Relation to Infosec
In other words, how could this go wrong? Glad you asked! 😀
SYN flooding
SYN flooding makes me think of “Midwest nice” and how I watch my coworkers deal with scam phone calls because they’re too nice to not respond (and hang up).
SYN flooding involves sending a bunch of SYN messages in a short timeframe, such that the server responds to each one with a SYN-ACK. The server will then wait around for the final ACK (it gives it some leeway because legitimate ACKs can be delayed due to network traffic). This is a huge drain on server resources, and can result in the server being unresponsive to legitimate users.
TCP sequence prediction attack
As mentioned before, the sequence numbers should be random, which is to say, hard-to-predict.
If a malicious third party has been listening to traffic between two hosts, it can determine the sequence number, and then attempt to send TCP segments (created to look as though they originate from one host’s IP address, sent to the other host’s IP address), with the sequence number. Effectively, the third party is trying to impersonate one of the hosts and send false data, or prematurely close the connection.
Because the legitimate host is also sending packets with the same IP address and sequence number, the attacker might try to DDoS the legitimate host (otherwise, they’re in a race against each other to get their message to the receiving host first). More info here.
TCP Veto
Very similar to the previous attack, an attacker can send a packet with an IP address from the legitimate host, and the correct/upcoming sequence number. If the attacker also knows (or can guess) the packet size, and sends this information in the TCP segment headers, then there will be two messages with the same headers, but possibly different information. The receiving host has to pick which one is legitimate–the one deemed to be a duplicate (which could be the actually legitimate one) is “vetoed” and thrown away. Communication then continues on as normal–duplicate packets are not uncommon, so this attack is somewhat difficult to detect.
TCP Reset
Lastly, TCP packets can be spoofed to prematurely close internet connections by setting the RESET flag to 1.
A reset packet indicates to the receiving computer that all communication on that TCP connection should stop immediately, and no future packets from that connection should be accepted. Normally, this would be a way for a computer to indicate that it didn’t know how to handle messages (for example, the computer was restarted) and needed to re-initiate the connection.
Like before, the attacker must sufficiently spoof out the TCP segment headers to make the message appear to be from a legitimate host. The “Great Firewall of China” uses TCP resets.