Wireshark

Wiresharking CURL - How a single GET request translates to 10 TCP Packets¶

1. Introduction and Setup¶

• Goal: To visualize and explain the sequence of TCP packets generated when executing a simple curl command (e.g., curl http://[IP_ADDRESS]) [00:05].
• Tools Used: Wireshark is used to capture and analyze the network trace [00:44].
• Key Concept: Every HTTP request is built upon a TCP connection, which requires specific phases: Handshake, Data Transfer, and Termination.

2. The TCP Three-Way Handshake¶

Before any data is sent, the client and server must synchronize sequence numbers.

• Packet 1: SYN (Synchronize): The client sends a SYN packet with an initial sequence number (ISN). In Wireshark, "Relative Sequence Numbers" are often used to make these easier to read [01:41]. The length of this packet is 0 [02:07].
• Packet 2: SYN-ACK: The server responds with its own SYN (its own ISN) and an ACK (acknowledgment) of the client's SYN [02:15].

• The "Ghost Byte": Even though the SYN has no data, the server increments the client's sequence number by 1 for the acknowledgment [03:13].

• Packet 3: ACK: The client acknowledges the server’s SYN, completing the handshake [03:56].

3. Data Exchange (The GET Request)¶

• Packet 4: HTTP GET Request: The client sends the actual HTTP GET request. The length of this packet depends on the size of the HTTP headers [04:43].
• Packet 5: ACK from Server: The server acknowledges receipt of the GET request. The acknowledgment number equals the client's sequence number plus the length of the data packet [05:12].

• Reliability: If the client doesn't receive this ACK, it will retransmit the request. Sequence numbers allow the server to identify and drop duplicate packets if the ACK was simply lost [06:23].

• Packet 6: HTTP Response (PSH): The server sends the requested HTML content. It often uses the PSH (Push) flag to tell the receiving application to process the data immediately [06:48].

4. Connection Termination¶

By default, curl closes the connection after the request is fulfilled unless specified otherwise [07:58].

• Packet 7: FIN-ACK (Server): The server sends a FIN (Finish) packet indicating it is done sending data and wants to close the connection [08:10].
• Packet 8: ACK (Client): The client acknowledges the data and the server's FIN request [08:37].
• Packet 9: FIN-ACK (Client): The client sends its own FIN to close its side of the connection [09:40].
• Packet 10: ACK (Server): The server acknowledges the client's FIN, and the connection is fully closed [10:22].

Key Takeaways¶

• Sequence Numbers: Essential for ordering packets and ensuring no data is missing or duplicated [01:28].
• Efficiency: TCP tries to combine information (like SYN and ACK) into a single packet whenever possible to reduce overhead [02:52].
• Overhead: A simple "hello world" HTTP request involves significantly more "under-the-hood" communication (10 packets) than the user sees [10:41].

Video Link: Wiresharking CURL - How a single GET request translates to 10 TCP Packets

What Really Happens During a WebSockets Connection - Wiresharking WebSockets¶

1. Introduction and Setup¶

• Objective: To demystify the multi-step process of establishing, maintaining, and closing a WebSocket connection [00:01].
• Setup: A WebSocket server is running on a Raspberry Pi (port 8080), and a client connection is initiated through a web browser's console using JavaScript [01:13].
• Key Concept: WebSockets are a bidirectional communication protocol built on top of HTTP, which itself is built on TCP [03:53].

2. Establishing the Connection¶

The connection process follows a specific sequence of network layers:

• TCP Three-Way Handshake: Like all TCP-based protocols, it begins with the standard SYN, SYN-ACK, and ACK exchange to synchronize sequence numbers between the client and server [03:46].
• HTTP Upgrade Request: After the TCP connection is established, the client sends an HTTP GET request with an "Upgrade: websocket" header. This "hijacks" the connection to switch from HTTP to the WebSocket protocol [04:57].
• Protocol Switching Response: The server acknowledges this by responding with an "HTTP/1.1 101 Switching Protocols" message [06:10]. At this point, the connection is no longer HTTP but is a raw TCP WebSocket "pipe" [05:25].

3. Maintaining and Using the Connection¶

• Ping-Pong Mechanism: To ensure the connection is still alive, the server or client can send a "Ping" packet. The other party must respond with a "Pong" to verify the connection. This is a built-in feature of the WebSocket protocol [06:56].
• Data Transfer: Data is sent as "WebSocket Text" packets. Unlike standard HTTP, this communication is full-duplex, meaning both parties can send data simultaneously [08:33].

4. Terminating the Connection¶

Closing a WebSocket is a two-layer process:

• Logical Close (WebSocket Layer): The client initiates a "Connection Close" request [09:54]. The server acknowledges this and sends its own "Connection Close" message back [10:38].
• Physical Close (TCP Layer): Once the WebSocket layer is logically closed, the underlying TCP connection must be terminated using the standard FIN, FIN-ACK, and ACK sequence [11:29].
• TCP Wait State: The party that initiates the close (the client in this example) will stay in a "TCP Wait" state for about 4 minutes to ensure all delayed packets are received, helping manage memory on the server side [11:44].

Key Takeaway¶

While software engineers often see WebSockets as a simple real-time stream, there is significant "chattiness" and complexity involved at the network level, including multiple layers of handshakes and acknowledgments to ensure reliable, bidirectional communication [07:42].

Video Link: What Really Happens During a WebSockets Connection - Wiresharking WebSockets

Wiresharking TLS - What happens during TLS 1.2 and TLS 1.3 Handshake¶

1. Introduction: Why Wireshark TLS?¶

• Packet-Level Visibility: Analyzing low-level TCP and TLS packets allows engineers to appreciate the "behind-the-scenes" work of a network request [01:01].
• Performance Awareness: Understanding the overhead of handshakes helps engineers avoid costly mistakes, such as opening and closing connections inside loops [01:19].
• Debugging Tool: Wireshark is essential for back-end engineers to debug complex networking traffic and protocol failures [00:36].

2. TLS 1.2 Handshake Analysis¶

The TLS 1.2 handshake is characterized by a "long" process involving multiple round-trips [03:07].

• TCP Three-Way Handshake: Before TLS begins, a standard TCP connection (SYN, SYN-ACK, ACK) must be established to agree on sequence numbers [03:22].
• Client Hello: The client initiates the TLS session by sending its supported cipher suites, extensions (like Server Name Indication - SNI), and supported TLS versions [03:46].

• Even if a specific version is requested, the client often includes support for that version and above (e.g., 1.2 and 1.3) [05:51].

• Server Hello & Certificate: The server responds with the chosen cipher suite and its digital certificate, which contains its public key and CA signature [06:54].

• Key Exchange: In TLS 1.2, this often requires additional packets to exchange key parameters (e.g., Diffie-Hellman) [07:48]. Modern clients prefer Diffie-Hellman over RSA because it provides Perfect Forward Secrecy [06:07].
• Change Cipher Spec: Once keys are exchanged, both parties send a message to indicate that all subsequent communication will be encrypted [09:02].
• Round-Trips: TLS 1.2 typically requires two round-trips (four main requests/responses) before application data can be sent [04:09].

3. TLS 1.3 Handshake Analysis¶

TLS 1.3 is a major optimization designed for speed and security [11:03].

• One Round-Trip (1-RTT): Unlike version 1.2, TLS 1.3 finishes the handshake in just one round-trip [04:22].
• Pre-emptive Key Exchange: In the "Client Hello," the client pre-emptively sends key shares. This allows the server to assemble the symmetric key and start encrypted communication immediately in the "Server Hello" [14:29].
• Mandatory Security: TLS 1.3 removes insecure options and forces secure exchange modes like Diffie-Hellman [07:58].

4. Handshake Failures and Error Handling¶

• Scenario: A client that only supports TLS 1.3 attempts to connect to a server supporting only TLS 1.2 (e.g., an older Nginx setup) [10:40].
• Handshake Failure: The server receives the 1.3 request but responds with a "Handshake Failure" alert [12:11].
• Connection Reset: The server then closes the connection because it cannot satisfy the client's strict security requirements [12:35].

5. Security and Observation Notes¶

• Encryption Privacy: Once "Application Data" begins, the traffic is encrypted. Wireshark cannot see the content of this data [09:23].
• Debugging Proxies: To see encrypted data for debugging, one must use a proxy like Fiddler, which acts as a "man-in-the-middle" to terminate and re-encrypt the TLS connection [09:31].
• Graceful vs. Nasty Stops: A proper termination uses a "FIN" packet, while a "Reset" (RST) packet indicates a "hard stop" or ungraceful closure [16:11].

Video Source: Wiresharking TLS - What happens during TLS 1.2 and TLS 1.3 Handshake

Wiresharking Secure Shell (SSH) - Spoiler alert 🚨 : its chatty¶

1. Introduction and Setup¶

• Objective: To analyze the efficiency, overhead, and packet-level details of the Secure Shell (SSH) protocol [00:06].
• Environment: An SSH server running on a Raspberry Pi, with Wireshark capturing traffic from a client machine [00:38].
• Key Characteristic: SSH is noted for being "chatty," meaning it sends a high number of packets even for minimal user input [12:26].

2. The SSH Handshake Process¶

Unlike TLS, SSH uses its own specific handshake and encryption setup.

• TCP Connection: The process begins with a standard TCP three-way handshake: SYN, SYN-ACK, and ACK [01:09].
• Protocol Version Exchange: Immediately after the TCP connection, both the client and server exchange their protocol versions (e.g., SSH-2.0-OpenSSH_8.1) [01:27]. This information is critical for selecting compatible algorithms [02:49].
• Key Exchange Initialization (KEXINIT): The client sends a list of supported key exchange algorithms (e.g., Elliptic Curve Diffie-Hellman), symmetric encryption ciphers (e.g., ChaCha20), and MAC algorithms [03:00]. The server then sends its own supported list [04:07].
• Diffie-Hellman Key Exchange: The parties use the agreed-upon algorithm to exchange public parameters. A unique aspect of SSH is that it often doesn't explicitly state the chosen algorithm in the packet; it is inferred by both sides [05:57].

3. Security and "New Keys"¶

• Generating the Shared Secret: After the exchange, both the client and server possess the full shared secret key [06:56].
• New Keys Packet: Both sides send a "New Keys" message. This packet indicates that all subsequent communication will be encrypted using the newly generated keys [08:02].
• Complexity Seeding: The client generates approximately six sub-keys to strengthen the encryption. This is particularly important for protecting against attacks on older ciphers like CBC (Cipher Block Chaining), where a hacker might otherwise be able to modify ciphertext without knowing the key [08:21].

4. Protocol "Chattiness" and Encrypted Traffic¶

• Post-Handshake Encryption: Once the handshake is complete, all traffic (including authentication and shell commands) is encrypted. Wireshark cannot decrypt this traffic without a specific key log [01:35].
• Command Overhead: Nasser demonstrates that a simple command like ls or touch can translate into over 100 packets [11:38].
• Possible Reasons for Chattiness:
• Predictability: By sending many packets or breaking data into smaller chunks, the protocol makes it harder for attackers to guess commands based on packet size or timing [13:32].
• Interactive Nature: Every keystroke and screen update in an interactive shell requires round-trip communication [11:54].

Summary Table of Round Trips¶

Video Source: Wiresharking Secure Shell (SSH) - Hussein Nasser