Tor Deep Dive Part 10: Tor, VPN, Tailscale or Cloudflare Tunnel? A Decision Table
The earlier parts looked at Tor in detail. This last part asks the question most readers actually have: if I want to reach my own server, or hide where my traffic goes, which tool should I use?
A disclosure first. I tested Tor in this series. I did not test a commercial VPN, Tailscale or Cloudflare Tunnel. What I say about them comes from their own documentation, quoted where I can, and I flag what the documentation does not say.
What the vendors say
Tailscale builds a WireGuard network between your devices. Its encryption documentation describes WireGuard as the data plane, and says of its DERP relay servers that they “never access your unencrypted data; they only handle WireGuard packets that are already encrypted” (Tailscale: encryption). That page does not say whether the coordination service could read traffic, so I will not claim either way.
Cloudflare Tunnel runs a small daemon on your server that makes an outbound connection to Cloudflare, so you need no inbound ports. Its documentation says all traffic to your origins flows through Cloudflare (Cloudflare Tunnel). That is the trade: no open ports, and Cloudflare sits in the path.
Who sees what
| Tor (exit) | Tor (onion service) | Commercial VPN | Tailscale | Cloudflare Tunnel | |
|---|---|---|---|---|---|
| Hides your IP from the destination | Yes | Yes, both ends | Yes, behind the VPN’s IP | Not the goal | Not the goal |
| Who can see the destination and content | The exit, unless the protocol is encrypted end to end | Nobody on the path | The VPN provider | Only your devices, per the vendor’s description of the data plane | Cloudflare |
| Who knows who you are | Your guard sees your IP, not your destination | Same | The provider sees your IP and destination | The vendor knows your account and devices | The vendor knows your account |
| Opens inbound ports on your server | Not for an onion service | No | Depends on setup | No | No |
| Works for ordinary users without setup | Needs Tor client | Needs Tor client | Yes | Needs client on each device | Needs the daemon on the server |
| Speed | Slow | Slower | Usually fast | Usually fast | Usually fast |
The honest caution: “who sees what” rows for the commercial tools are statements about their design, not my measurements, and a VPN provider’s no-logs claim is something you trust, not something you verify.
Which tool for which job
| You want to | Use | Why |
|---|---|---|
| Reach your own SSH server from anywhere without exposing port 22 | Tor onion service or Tailscale | Neither needs an open inbound port |
| Hide your IP from a website | Tor Browser, or a VPN if you trust the provider | Tor spreads trust, a VPN concentrates it |
| Expose a web app without opening ports | Cloudflare Tunnel | Built for this; accept Cloudflare in the path |
| Join your own machines into one private network | Tailscale | Designed for it |
| Get past a network that blocks Tor | Tor bridges, if you can test them | I did not test bridges, so treat this as a pointer, not a recommendation |
| Resist a patient observer of both ends | Not any of these alone | See Part 9 |
Ranking ways to reach your own SSH server
This is the part I would act on. From best to worst, on the evidence of the earlier parts:
- An onion service plus key-only SSH. There is no exit to attack, no open port, and the address is the key. Part 4 sets it up and notes the costs.
- A private network such as Tailscale, with key-only SSH over it. No public port, and you rely on the vendor’s design as documented.
- A pinned host key over a public exit, with key-only login. A hostile exit cannot log in without your private key, and a pinned key makes interception show as a warning. Part 5 tested what an interceptor can and cannot do.
- Password SSH over a public exit. Do not. This is exactly what the Part 1 attackers harvested.
The whole series
- How over 300 Tor exit relays were hijacked to steal SSH passwords
- How Tor works and what you are trusting
- Running a Tor client on Debian 13
- SSH over Tor, host keys, and why an onion service beats an exit
- What a hostile exit can do to an SSH connection
- Ebury, and how to check your own Debian hosts for it
- Finding bad exit relays with a Python scanner
- Running a Tor relay securely on Debian
- Other ways Tor can fail you
The scanner from Part 7 and the relay check from Part 8 are published together as tor-checks on GitHub, under the MIT licence.
Sources
- Tailscale: encryption
- Cloudflare Tunnel documentation
- The Tor Project documentation and forum posts cited in Parts 1, 8 and 9
- tor-checks, the code from Parts 7 and 8