Comparing HTTP, HTTPS, VPN, and Tor with “snail mail” metaphors

Revision 76

The goal of this article is to break down how the Tor network protects your network metadata. All of the examples are based on what is commonly done in order to best represent reality. I only look at basic network operations and some basic network attacks, not client side, server side, Tor bridge, or Tor authority attacks. I may expand this article later to include more complex scenarios. In general, “HTTP” and “HTTPS” could be replaced with other, similar clear-text or encrypted transport protocols. Special thanks to Edward Snowden for giving the world factual evidence about network adversary capabilities that degrade fundamental human rights and intellectual freedoms.

I often meet intelligent people who are misinformed about what Tor allows people to do. Having this article allows me to share it with them so they can constructively point out which process(es) they’re criticizing. Sometimes people are right but fail to juxtapose an alternative technology’s vulnerabilities, like HTTPS or a VPN. Sometimes people are right but ignore probabilistic or subjective threat models. Tor is a complex system and requires thorough understanding.


1. HTTP and “snail mail”

If you’ve ever mailed a postcard to friends or family, you should understand this metaphor.

High-level primer:
message (1a), sender (1b) > recipient (1c)

1.1.1. The postcard has no protection; anyone who handles the postcard can read the message (1a), who sent it (1b) and who received it (1c).

HTTP Vulnerabilities

message (1a), sender (1b) > recipient (1c)

1.2.1. Your ISP always monitors and records (1b) and (1c) metadata, and can easily monitor or record (1a) content.

1.2.2. It is trivial for dragnet surveillance programs to monitor and record (1a), (1b), and (1c).

1.2.3. Nothing stops a network adversary from blocking (2c) access, such as an IP or DNS filter.

1.2.4. Very little can stop a network adversary from censoring or altering (1a), or reroute/MitM the traffic to malicious resources.


2. HTTPS and “snail mail”

If you’ve ever mailed a hand-written or typed letter, you should understand this metaphor.

High-level primer:
message (2a), sender (2b) > recipient (2c)

2.1.1. The letter has one layer of protection, the envelope. Anyone who handles the enclosed letter can read who sent it (2b) and who received it (2c).

2.1.2. The recipient (2c) can read the letter (2a); they know who sent (2b) the letter, so they know who to reply to (2b).

HTTPS Vulnerabilities

message (2a), sender (2b) > recipient (2c)

2.2.1. Your ISP always monitors and records (2b) and (2c) metadata.

2.2.2. It is trivial for dragnet surveillance programs to monitor and record (2b) and (2c) metadata.

2.2.3. Nothing stops a network adversary from blocking (2c) access, such as an IP filter.

2.2.4. If the recipient is 1) not enforcing strong TLS encryption protocols, 2) not using strong TLS cipher suites, or 3) is poorly configured, nothing stops a targeted attacker from capturing the traffic 1) at any intermediary infrastructure between the sender and the recipient or 2) inside the recipient’s compromised infrastructure. Once captured, the adversary can 1) remove the outer envelope (breaking weak SSL/TLS) to read the content, or 2) reroute/MitM the traffic to malicious resources.


3. VPN and “snail mail”

High-level primer:
content (3a), sender (3b) > traffic proxy (3c) > recipient (3d)

Adjusted metaphor:
message (3a), sender (3b) > mail proxy (3c) > recipient (3d)

VPN without HTTPS (postcard)

message (3a), sender (3b) > mail proxy (3c) > recipient (3d)

3.1.1. Take your postcard and write the recipient name and address (3d) along with the name and address (3c) of the company you’ve paid to proxy your postcard.

3.1.2. Enclose the postcard into an envelope. Destination: mail proxy name and address (3c), origination: your name and address (3b).

3.1.3. Now send the enclosed postcard. Your mail proxy will remove the envelope then send the now-naked postcard to the recipient. The mail proxy (3c) can read the message (3a). They know who sent (3b) the postcard and where the it’s going (3d).

3.1.4. The recipient (3d) can read the postcard (3a); they know where the postcard came from (3c), so they know who to reply to (3c).

VPN with HTTPS (letter)

message (3a), sender (3b) > mail proxy (3c) > recipient (3d)

3.2.1. Take your letter and enclose it in an envelope. Put the recipient name and address (3d) on the envelope along with the name and address (3c) of the company you’ve paid to proxy your letter.

3.2.2. Enclose the letter into a second envelope. Destination: mail proxy name and address (3c), origination: your name and address (3b).

3.2.3. Now send the letter. Your mail proxy (3c) will remove the outermost (second) envelope then send the letter to the recipient (3d). The mail proxy (3c) knows who’s sending (3b) the letter and where the letter is going (3d).

3.2.4. The recipient (3d) can read the letter (3a). They know where the letter came from (3c) and who to reply to (3c).

VPN Vulnerabilities

content (3a), sender (3b) > traffic proxy (3c) > recipient (3d)

3.3.1. Your ISP always monitors and records (3b) and (3c) metadata.

3.3.2. With data retention, it is trivial for adversaries to obtain anything your ISP knows.

3.3.3. Global dragnet surveillance programs always monitor and record popular VPN (3c) metadata.

3.3.4. It is probable that dragnet surveillance programs automatically correlate (3b), (3c), and (3d) traffic because of its simplicity.

3.3.5. If your proxy has 1) data retention, 2) has been forced by it’s regional government to have data retention and gagged not to disclose its data retention, 3) uses insecure protocols, 4) insecure cipher suites, or 5) is poorly configured, (3b), (3c), and (3d) metadata become vulnerable. The one-hop proxy knows everyone’s identity, and they probably have your credit card number.

3.3.6. Nothing stops a network adversary from blocking (3c) or (3d) access, such as an IP filter.

3.3.7. If the proxy or recipient is 1) not enforcing strong TLS encryption protocols, 2) not using strong TLS cipher suites, or 3) is poorly configured, nothing stops a targeted attacker from capturing the traffic 1) at the one-hop proxy, 2) at any intermediary infrastructure between the one-hop proxy and the recipient, or 3) inside the recipient’s compromised infrastructure. Once captured, the adversary can 1) remove the outer envelope (breaking weak SSL/TLS) to read the content, or 2) reroute/MitM the traffic to malicious resources.


4. Tor and “snail mail”

There is no Tor equivalent to “snail mail,” so this is what it would look like.

High-level primer:
content (4a), sender (4b) > Tor guard relay (4c) > Tor middle relay (4d) > Tor exit relay (4e) > recipient (4f)

Adjusted metaphor:
message (4a), sender (4b) > first mail proxy (4c) > second mail proxy (4d) > third mail proxy (4e) > recipient (4f)

Tor without HTTPS (postcard)

message (4a), sender (4b) > first mail proxy (4c) > second mail proxy (4d) > third mail proxy (4e) > recipient (4f)

4.1.1. Take your postcard and put the name and address of the recipient (4f) on the front along with the name and address of the third proxy (4e) as the sender.

4.1.2. Enclose the postcard in an envelope. Destination: third mail proxy (4e), origination: name and address of the second mail proxy (4d).

4.1.3. Enclose the postcard in a second envelope. Destination: second mail proxy (4d), origination: name and address of the first mail proxy (4c).

4.1.4. Enclose the postcard in a third envelope. Destination: fist mail proxy (4c), origination: your name and address (4b).

4.1.5. Now send the postcard. The first mail proxy (4c) will remove the outermost (third) envelope and send it to the second mail proxy (4d). The first mail proxy (4c) only knows who sent (4b) the letter and where it’s going (4d).

4.1.6. The second mail proxy (4d) will remove the outermost (second) envelope and send it to the third mail proxy (4e). The second mail proxy (4d) only knows who sent (4c) the letter and where it’s going (4e).

4.1.7. The third mail proxy (4e) will remove the outermost (first) envelope and send the postcard on to the recipient (4f). The third mail proxy (4e) can read the postcard (4a). They know who sent (4d) the postcard and where it’s going (4f).

4.1.8. The recipient (4f) can read the postcard (4a). They know where the postcard came from (4e) and who to reply to (4e).

Tor with HTTPS (letter)

message (4a), sender (4b) > first mail proxy (4c) > second mail proxy (4d) > third mail proxy (4e) > recipient (4f)

4.2.1. Take your letter and enclose it in an envelope. Put the name and address of the recipient (4f) on the front along with the name and address of the third proxy (4e) as the sender.

4.2.2. Enclose the letter in a second envelope. Destination: third mail proxy (4e), origination: name and address of the second mail proxy (4d).

4.2.3. Enclose the letter in a third envelope. Destination: second mail proxy (4d), origination: name and address of the first mail proxy (4c).

4.2.4. Enclose the letter in a fourth envelope. Destination: fist mail proxy (4c), origination: your name and address (4b).

4.2.5. Now send the letter. The first mail proxy (4c) will remove the outermost (fourth) envelope and send it to the second mail proxy (4d). The first mail proxy (4c) only knows who sent (4b) the letter and where it’s going (4d).

4.2.6. The second mail proxy (4d) will remove the outermost (third) envelope and send it to the third mail proxy (4e). The second mail proxy (4d) only knows who sent (4c) the letter and where it’s going (4e).

4.2.7. The third mail proxy (4e) will remove the outermost (second) envelope and send the letter on to the recipient (4f). The third mail proxy (4e) only knows who sent (4d) the letter and where it’s going (4f).

4.2.8. The recipient (4f) can read the letter (4a). They know where the letter came from (4e) and who to reply to (4e).

Tor Vulnerabilities

Keep in mind that Tor circuits are generated randomly, are required to have significant international hops, and are created every time a Tor user starts a new Tor Browser session. Tor user and Tor relay diversity and volume are critical.

content (4a), sender (4b) > Tor guard relay (4c) > Tor middle relay (4d) > Tor exit relay (4e) > recipient (4f)

4.3.1. Your ISP always monitors and records (4b) and (4c) metadata.

4.3.2. With data retention, it is trivial for adversaries to obtain anything your ISP knows.

4.3.3. Global dragnet surveillance programs monitor and record known Tor exit relay (4e) metadata whenever possible.

4.3.4. Presuming that the Tor guard relay is not logging traffic, (4b), (4c), and (4d) metadata are not recoverable from the Tor guard relay.

4.3.5. Presuming that the Tor guard relay is logging traffic, the adversary will know (4b), (4c), and (4d) metadata. They cannot know (4e) or (4f) metadata with this relay alone. Most Tor relays are middle relays, and the guard flag is granted to middle relays and exit relays when it has good reputation (time, stability, no filtering). A Tor circuit cannot have any one relay fulfill two or more circuit roles.

4.3.6. Presuming that the Tor middle relay is logging traffic, the adversary will know (4c) and (4e) metadata, which is meaningless data. They cannot know (4b) or (4f) metadata with this relay alone. Most Tor relays are middle relays, and it takes reputation (time, stability, no filtering) for middle relays to be sent more traffic to process. A Tor circuit cannot have any one relay fulfill two or more circuit roles.

4.3.7. Presuming that the Tor exit relay is logging traffic, the adversary will know (4c) and (4e) metadata. They cannot know (4a) or (4b) metadata with this relay alone. Exit relays are explicitly set by the operator and can begin processing exit relay traffic as soon as it has an error-free connection to the Tor network. However, it takes reputation (time, stability, no filtering) for an exit relay to be sent more traffic to process. A Tor circuit cannot have any one relay fulfill two or more circuit roles.

4.3.8. An Adversary would have to own both the guard relay and the exit relay of any given circuit to conduct a successful network correlation analysis or attack. It is statistically improbable that any one adversary owns the circuit start and end nodes of a targeted user’s session. It is impossible for any one adversary to own any majority of relays, meaning it impossible for both ends of all circuits to be monitored all the time.

4.3.9. If the recipient is 1) not enforcing strong TLS encryption protocols, 2) not using strong TLS cipher suites, or 3) is poorly configured, nothing stops a targeted attacker from capturing the traffic 1) at the Tor exit relay, 2) at any intermediary infrastructure between the Tor exit relay and the recipient, or 3) inside the recipient’s compromised infrastructure. Once captured, the adversary can 1) remove the outer envelope (breaking weak SSL/TLS) to read the content, or 2) reroute/MitM the traffic to malicious resources.