Securing Data-in-Motion - Packets


I wanted to make a few posts about common privacy routing mechanisms. Particularly, I would like to help the community understand basic network security for data-in-motion, which is data moving between machines, networks, geographic locations, and so on.

This first post will introduce the concept of packets, and focus primarily on the underlying components of encapsulation, headers, payloads, source, destination, and - most importantly - encryption. I will use HTTP/S to abstract away Layers 4-7 of the OSI model where appropriate, and Layers 1-2 will be largely ignored. This allows us to focus on packets (Layer 3). I will also simplify packets by ignoring header components such as QoS, TTL, checksums, and so on.

tl;dr for the non network engineers - I am making things simpler than they actually are.


Packets are what routers use to move data between networks, whether that be between you and your ISP, your ISP and a different ISP, or an ISP and a datacenter. All packets are made up of two components - a header and a payload:

  • Header - holds the information that a router cares about, such as IP version, flags, and so on; for our purposes we will focus on source and destination

    • Source - IP address where the packet is coming from

    • Destination - IP address where the packet is going

  • Payload - the contents or data contained within the packet

The following is an example of a packet that machine 1 with IP address sent and machine 2 with IP address received:

Source:, Destination:


Packets can be encapsulated, which is a complicated process that can involve many protocols that accomplish it different ways. For our purposes, think of it like putting a packet within another packet. The inside packet becomes the payload for the outside packet. Following the previous example, perhaps machine 1 wants to send the packet to machine 2 via a middleman of IP address, which would look like:

Source:, Destination:
    Source:, Destination:

When the middleman receives the encapsulated packet, the middleman de-encapsulates the packet, which means it removes the top header. Then, normally, the middleman sends the payload as its own packet.


As previously mentioned, I will use HTTP/S as an example. There are many other protocols we could discuss. Where HTTP/S is helpful is in its usage of TLS, which is a common encryption method for data-in-motion. Thanks to the sophistication of modern public key infrastructure (PKI), using TLS means that only you and the web server you communicate with can read the payload of your HTTP traffic (…and, theoretically, sophisticated nation states with secret, functioning, quantum computers…).

You should always use HTTPS. In situations where you cannot, you should (in most cases) refuse to use that site. Here is a demonstration of the difference:

HTTP packet:

Source:, Destination:
    POST /login HTTP/2
    {'username': 'idiot', 'password': 'terrible-password'}

HTTPS packet:

Source:, Destination:

See? The HTTP payload is encrypted, and therefore your login information cannot be viewed by any router or hacker between you and the web server.

Privacy Implications

Packets cannot be routed without the source and destination header information. The problem is that (public) IP addresses are relegated to specific geographic locations, and those locations are either public or can be made public. This means that accessing a website exposes your location (approximately) and the web server’s location to you, the web server, and every router in between.

Furthermore, if the payload is unencrypted, all of those same machines can read whatever information is transmitted between you and the web server - including protocols being used, pages accessed, usernames, passwords, bank details, and so on.


Packets are the language of the Internet. Without them, you would not be able to view this website.

However, packets can contain sensitive information. HTTPS helps, but we need more than that to protect our privacy.

If there is a second post, I would like to next discuss how proxies, VPNs, and Tor work. Let me know if that would be helpful or interesting to you.


Great information. Thanks for sharing and I’d be interested in the next post.

This is seriously a wealth of knowledge. This might become one of the best repos of QubesOS on earth! Thank you!