What is TCP?
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.”
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.
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.
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.
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.
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).
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.
In other words, how could this go wrong? Glad you asked!
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.
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.
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.
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.
- Top Best Keylogger in Python 3 Make One
- What is Hacking?
- Secrets of the Deep Dark Web
- CODECHEF September Lunchtime 2020 SOLUTIONS
- August Lunchtime 2020 SOLUTIONS
June Long Challenge 2021 Solutions
- Maximum Frequent Subarray Sum solution codechef
- Dual Distance solution codechef
- Optimal Xor Set solution codechef
- Minimum Subtree Cover solution codechef
- Minimum Dual Area solution codechef
- Bitwise Tuples solution codechef
- Shortest Route solution codechef
- Bella ciao solution codechef
- Summer Heat solution codechef
March Long Challenge 2021 Solutions
- An Interesting Sequence ISS SOLUTION
- Tree House THOUSES SOLUTION
- Valid Paths VPATH SOLUTION
- Modular Equation MODEQ SOLUTION
- Tic Tac Toe TCTCTOE SOLUTION
- Xor Equality XOREQUAL SOLUTION
- Golf LKDNGOLF SOLUTION
- Solubility SOLBLTY SOLUTION
April Long Challenge 2021 Solutions
- Chef and Dice SDICE Solution
- Worthy Matrix KAVGMAT Solution
- Binary String MEX MEXSTR Solution
- Boolean Game BOOLGAME Solution
- Tree Permutations TREEPERM Solution
- Destroy the EMP Chip CHAOSEMP Solution
- Chef and Pair Flips PAIRFLIP Solution
- String Power STRPOW Solution
- Brahma and Shiva SHRINES Solution
- Water Sort Puzzle (Challenge) WTRSORT Solution
- World Record BOLT Solution
- Strong Language SSCRIPT Solution
- Valid Pair SOCKS1 Solution
Codechef Long Challenge Solutions
February Long Challenge 2021
- 1. Frog Sort Solution Codechef
- 2. Chef and Meetings Solution Codechef
- 3. Maximise Function Solution Codechef
- 4. Highest Divisor Solution Codechef
- 5. Cut the Cake Challenge Solution Codechef
- 6. Dream and the Multiverse Solution Codechef
- 7. Cell Shell Solution Codechef
- 8. Multiple Games Solution Codechef
- 9. Another Tree with Number Theory Solution Codechef
- 10. XOR Sums Solution Codechef
- 11. Prime Game Solution CodeChef
- 12. Team Name Solution Codechef
January Long Challenge 2021
- Chef and Division 3 DIVTHREE SOLUTION Code Chef
- Encoded String DECODEIT SOLUTION Code Chef
- Point Of Impact BILLRD SOLUTION Code Chef
- Fair Elections FAIRELCT SOLUTION Code Chef
- Watching CPL WIPL SOLUTION Code Chef
- Chef and Ants ANTSCHEF SOLUTION Code Chef
- Blackjack BLKJK SOLUTION Code Chef
- And-Or Game ORAND SOLUTION Code Chef
- Stack-Queue Sort (Challenge) SQSORT SOLUTION Code Chef
- Expected Number of SCCs RCTEXSCC SOLUTION Code Chef
- Curious Matrix CURMAT SOLUTION Code Chef
- Cool Subsets COOLSBST SOLUTION Code Chef
- Sequence Creation ARCRT SOLUTION Code Chef
- Greedy Students GRDSTD SOLUTION Code Chef
November Challenge 2020 SOLUTION CodeChef
- Ada and Dishes SOLUTION ADADISH
- Iron Magnet and Wall SOLUTION FEMA2
- Magical Candy Store SOLUTION CNDYGAME
- Unusual Queries SOLUTION UNSQUERS
- Red-Black Boolean Expression SOLUTION RB2CNF
- Chef and the Combination Lock SOLUTION CHEFSSM
- Scalar Product Tree SOLUTION SCALSUM
- Connect on a Grid (Challenge) SOLUTION CONGRID
October Lunchtime 2020 CodeChef SOLUTIONS
- AND Plus OR SOLUTION ANDOR
- Chef and Subtree MEXs SOLUTION SUBMEXS
- Chef Likes Good Sequences SOLUTION GSUB
- Cute Chef Gift SOLUTION COPAR
- Chef Is Just Throwing Random Words SOLUTION SSO
- Counting Spaghetti SOLUTION CDSUMS
- Chef and Edge Flipping SOLUTION EFLIP
- A. Shandom Ruffle SOLUTION
- B. Pear TreaP SOLUTION
- C. Sneetches and Speeches 3 SOLUTION
- D. The Grim Treaper SOLUTION
- Y. Sneetches and Speeches 1 SOLUTION
- Z. Trick or Treap SOLUTION
- A. Floor Number SOLUTION CODE FORCES
- B. Symmetric Matrix SOLUTION CODE FORCES
- C. Increase and Copy SOLUTION CODE FORCES
- D. Non-zero Segments SOLUTION CODE FORCES
- E. Rock, Paper, Scissors SOLUTION CODE FORCES
- F. Number of Subsequences SOLUTION CODE FORCES
- Chef and Easy Queries SOLUTIONS CHEFEZQ
- Covid Run SOLUTIONS CVDRUN OCTOBER CHALLENGE
- Positive AND SOLUTIONS POSAND
- Replace for X SOLUTIONS REPLESX
- Village Road Network SOLUTIONS VILLNET
- Random Knapsack SOLUTIONS RANDKNAP
- D-Dimensional MST SOLUTIONS DDIMMST
- Compress all Subsegments SOLUTIONS SEGCOMPR
- Adding Squares SOLUTIONS ADDSQURE
- Inversions SOLUTIONS INVSMOD2 OCOTBER CHALLENGE
- Rooted Minimum Spanning Tree SOLUTIONS ROOTMST