> I'm not entirely sure how tor does this without root priviliges It's not really opening that port on the host. The kernel will never see a "Listen on port 80

> I'm not entirely sure how tor does this without root priviliges It's not really opening that port on the host. The kernel will never see a "Listen on port 80" syscall if you're running a Tor server. Tor can also 'punch' through NAT just fine because it doesn't open any listening sockets at all - It only connects _out_ to the Tor network and then does the rest through its proxy system. The firewall sees a completely legit outgoing, long-lived TCP connection (or several) and has no idea that you're actually accepting connections inside the tunnel. Countless remote desktop apps work this way, the same as a TURN server in WebRTC - Connect out to a relay, and pretend you're doing P2P by just shuffling data through the relay. Tor is already connecting to 3 middle nodes [1] to act as relays, and the direction of client --> server connections and the port numbers involved are already totally arbitrary. With Tor you're either in or out. Once you're inside the Tor network, it's kind of like having an anarcho-libertarian ISP. Put what you want on any port, connect to anyone else. No traffic shaping. Run an open SMTP relay if you wanna. It's equivalent to SSH port forwarding, sort of like a VPN in user space with fewer features. You don't get an IP address, and Tor only supports TCP connections, but you don't need any permissions because it's so abstract. You could probably run a "server" on a crappy cell connection, or a Starbucks open wifi once you already have a relay in the cloud. [1] The firewall will only see the entry node, though.