Global discovery server as Onion Service

bt90 · July 4, 2022, 7:10am

It would improve the resilience of the network if our global discovery server would also be reachable as a Tor Onion Service. This would allow users to circumvent states from blocking access which already happened previously.

From the clients perspective there’s not much to do as the discovery server is already configurable and Syncthing supports Tors SOCKS5 proxy. It would be enough to create the service and document how to access it.

In the long run a decentralized approach would be the best solution:

github.com/syncthing/syncthing

Use decentralized discovery (DHT)

opened 07:06AM - 05 Jul 16 UTC

calmh

enhancement

It's probably time to investigate decentralizing discovery. Doing so would reduc…e our infrastructure burden and reduce centralized knowledge of the network. In a DHT we want to be able to look up the contact details for a given device ID. We want to publish our own contact details into the DHT. We don't necessarily want to make it simple for a passive observer to map the entire network, so it would be nice if the contact details were encrypted. --- I suggest that we could use a key-value database laid out like: Key: SHA256(device ID) Value: The contact details, in protobuf format, encrypted using the device ID as a shared secret. Given that I know the device ID I'm looking for, I can then hash it and look it up, and decrypt the answer. For other nodes in the network, the data is mostly gibberish as you need to know the device ID it represents to be able to interpret it and reversing the SHA256(device ID) to an actual device ID is not feasible. As far as an actual implementation goes I've surveyed the Go ecosystem to try to find a suitable DHT package. So far I've not really succeeded. Here are the ones I've looked at and some notes on them; it would be lovely if someone did find or develop a good package for this. - https://github.com/nictuku/dht seems to be the best candidate, but a partial implementation - only supports looking up nodes for an "info hash", not storing or retrieving actual values? maybe could be built upon - https://github.com/fastfn/dendrite looks like a full implementation and may be usable, though annoying dependencies (0MQ transport), may require some rewriting - https://github.com/distributed/malus toy project, last commit 6 years ago - https://github.com/cfromknecht/kademlia partial implementation, uses TCP? - https://github.com/worldveil/peerchat student project, abandoned?, no license - https://github.com/zhujun1980/dhtrobot looks sort of promising, need to get past the chinese docs - https://github.com/gr0gmint/godht incomplete, abandoned - https://github.com/chuckha/dht partial implementation, TCP based - https://github.com/Hermes/ghord bare bones, maybe usable as a base for something - https://github.com/benjojo/NorthStar the authors themselves hate this code - https://godoc.org/github.com/r-medina/gmaj partial, lots of TODOs If anyone wants to pick this up and run with it, please do so, and announce yourself in the comments below :)

But for now it would improve things without too much effort.

AudriusButkevicius · July 4, 2022, 8:02am

This doesn’t make much sense to me, as discovery is there to find ip address you can connect to.

If you reach discovery via onion network, the discovery server will see some non-sense ip address, and advertise that.

This would also require listening on the tor network, whatever that even means.

acolomb · July 4, 2022, 8:43am

Of course that doesn’t make sense for the announcement part. But strictly just for discovery, asking for other devices’ addresses, it would help. So only one device must be able to contact the discosrv directly.

As for the announced addresses, we also send LAN IPs to the discosrv and probably whatever STUN happened to find, so even that part would be helpful without having a usable source IP address on the Tor connection. Maybe we could add a flag in the announcement that the source IP should not be recorded, which gets set when the discosrv connection is made via Tor?

calmh · July 4, 2022, 9:00am

From my admittedly very limited understanding of Tor and Onions this seems like it would be a lethally dangerous thing to implement. Aren’t most unmasking attacks against Tor users about correlating traffic within the Tor network with traffic outside the Tor network? And aren’t Onion services about hiding the service provider, which we’re not particularly interested in?

Whereas if a user sends all their traffic through Tor, things should just work (apart from incoming connections of course).

bt90 · July 4, 2022, 10:25am

The filtering for the announcement is pretty easy as the request would originate from the server itself Tor proxy -> discovery service. So it would be enough to drop announcements for 127.0.0.1 and ::1

As for the security of the users: the requests never leaves the Onion network. This kind of attack would only work if an Exit Node is passed. e.g trying to open a public website via Tor.

Routing everything via Tor would certainly slow things down. Tor is not really suitable for that.

Others also offer onion services to bypass blocks:

calmh · July 4, 2022, 10:37am

I’m not sure I understand the point then. ~~You talk to the discovery server via the onion network. It gives you an IP address to talk to. Then what?~~

Edit: I re-read the OP and understood that you’re after resilience against blocking. That’s … something, I guess. Not something I’m interested in spending any effort on, but it’s a point.