Middle relays

[jim3692]

I just found this repo and the Reddit post. I hope there is still interest in this project.

One of the key features of Tor is that it routes the traffic through random nodes, for better security. Those nodes require open ports, as the Tor network is baesd on TCP.

However, wireguard uses UDP and can run behind firewalls. This unlocks the possibility of allowing virtually anyone to run such a node at home.

There is this project that implements P2P connectivity using wireguard: https://github.com/jwhited/wgsd

So, probably a wireguard-based alternative to Tor is possible, with even better performance, and the added benefit of supporting UDP traffic (Tor does not support UDP traffic to pass through it).

Edit: Forgot to mention that Tor also has the Snowflake service, which allows middle nodes to use WebRTC and run behind firewall.

Edit2: I think Tailscale uses a similar approach to wgsd for P2P connectivity.

[JeWe37]

Well firstly, this project is rather outdated. Since I made this initial experiment, I first migrated to namespaced-wireguard-vpn, see chrisbouchard/namespaced-wireguard-vpn#7, which sets network namespaces up via simple bash scripts and systemd services. From there I moved to wg-netns, see dadevel/wg-netns#9, which makes layering wireguard tunnels easily composable. I'm also working on an Ansible playbook to easily spin up a VM and configure all of that with different VPNs and even load balancing between multiple VPNs for even better performance, but that is still in the works.

Secondly, really what I am trying to do here is not emulating TOR as a whole. While it seems conceptually very interesting, there are a lot of moving parts within TOR that to replicated likely requires a dedicated protocol. This is mostly designed for the threat model of having untrusted VPN providers and wanting to eliminate the possibility of them being a single point of failure.

As for what you are proposing, there has been a lot of work in P2P wireguard already, mostly as part of mesh VPN projects. The big name in the space is tailscale, but there are also lots of more open alternatives such as netbirdio/netbird or gravitl/netmaker. These however mostly focus on creating VPNs in the classical sense, i.e. overlay networks to allow easy direct connectivity. wgsd seems to be much like these, but making heavy use of existing tools.

The issue with UDP hole punching is primarily that is that there exist a lot of scenarios in which it won't work without a central exchange. That's what TURN exists to do in STUN implementations. Tailscale actually has a great blog post on all the ins-and-outs of NAT traversal. Their approach is not based on standard STUN/TURN but the concepts are the same. Therefore, "no open ports" isn't entirely accurate nor is it necessarily all that crucial for security, so long as the service running behind those ports is trusted. Wireguard and TOR(and alongside SSH and the big name reverse proxies the only services I would trust) are both services I would feel quite comfortable exposing.

Finally as for performance, the main bottleneck with TOR is not the protocol. Rather it is the nature of a triply layered network: Everything requires triple the bandwidth in the network and compared to the number of users, there are simply too new nodes to get good throughput. This is an issue that is rather difficult to remedy while retaining easy accessibility for people that do not want to potentially end up being exit nodes for illicit traffic themselves.

TLDR; TOR and layered wireguard VPNs both have their own, different, use cases. I don't think it's necessarily realistic to try and extend wireguard to do all of this. I like the concept a lot to be fully honest, but neither am I a security expert, nor do I myself have a use for such a system. I hope though I have been able to give you a couple pointers what you might want to look at if you want to pursue this further!

[jim3692]

Thank you for the input. I have some ideas on how it could be done without the need of a custom protocol. But there are some points that need some more research. I will probably open a discussion in r/tor about this, as I really believe that there will be performance gains switching to UDP. While writing this, I found this article from Tor showing with plans to switch to UDP in 2011: https://blog.torproject.org/moving-tor-datagram-transport/