Monday, October 22, 2018

The TCP Handshake


We learned about the TCP protocol in the article “Understanding TCP and UDP.” A brief mention was made in that article on the 3-way handshake process. Before we delve into that further, we must recapitulate about the TCP (Transmission Control Protocol).  TCP is a reliable and connection-oriented protocol, which means it ensures packets are delivered to the destination computer. If a packet is lost during transmission, TCP has the ability to identify this issue and resend the lost or corrupted packet. 

Now, before any data is sent across, handshaking takes place between the two systems that want to communicate. Once the handshaking completes successfully, a virtual connection is set up between the two systems. It’s just like a high profile deal that gets signed. Just like in a deal, both the parties discuss on various parameters such as the financial settlement, payment of outstanding dues, shareholding etc., in a similar manner, the two hosts (systems or computers) must agree on certain parameters, data flow, windowing, error detection, etc. 

The following diagram will help us understand the agreement that takes place between the two hosts.



The host (lovely lady here) that initiates communication sends a synchronous (SYN) packet to the receiver. This means that “Would you be interested in establishing a data connection with me?”
The receiver acknowledges this request by sending a SYN/ACK packet which translates to “Yes, I am interested in taking this conversation further. I have acknowledged your request and sending you the details of how to communicate with me.”

The lady accepts this “SYN+ACK” packet and sends an “ACK” packet which translates to “Ok… I understand the terms and conditions. Let’s begin the conversation.”

After this, the host and the other system starts transmission of data between each other. If all were so good in this world, we would not have to deal with the following problems which arise when the lovely lady turns out not to be so lovely.

The lady here has a change of heart and decides to play a trick on the receiver. What she does is, she withholds the last step of the handshake – “ACK”. Since the 3 way-handshake is not complete, the other system keeps on waiting for that. In the meantime, this lady starts another connection with the server and again withholds the last “ACK” packet. If she does it multiple times, it results in what is called as a “SYN Flood” attack. This is actually flooding the victim system with SYN packets, eventually, the victim system allocates all of its available TCP connection resources and can no longer process new requests.

This is an example of DoS attack – Denial of Service. The victim system will not be able to provide any services to any client as all its resources are locked with one system. 

There is another attack – DDoS attack. This is a distributed denial of service attack. Here the attack is from multiple different systems which leave the handshake open and the result is again the denial of service. To put it in the same example, let’s consider that this lovely lady brings together a lot of her friends and ask them to start the handshake process with the victim and leave it in the middle. This would result in a DDoS attack.

There is one more attack mechanism we need to learn about before we say goodbye to each other.


One of the values that are agreed upon during a TCP handshake between two systems is the sequence numbers that will be inserted into the packet headers. Once the sequence number is agreed upon, if a receiving system receives a packet from the sending system that does not have this predetermined value, it will disregard the packet. This means that an attacker cannot just spoof the address of a sending system to fool a receiving system; the attacker has to spoof the sender’s address and use the correct sequence number values.

If an attacker can correctly predict the TCP sequence numbers that two systems will use, then she can create packets containing those numbers and fool the receiving system into thinking that the packets are coming from the authorized sending system. She can then take over the TCP connection between the two systems, which is referred to as “TCP session hijacking”.

No comments: