Feature: Tor Support

With mass surveillance everywhere Tor support for syncthing is needed IMHO. There are a couple of ways to go about this.

Pure p2p mode for 2 parties on Tor, no boostrapping needed:

  1. SOCKS5 proxy support because Tor is a socks proxy
  2. hostname support because there is no such thing as IP addresses on Tor. Hidden Services use the pseudo TLD .onion. Each party would configure a Hidden services are needed for incoming connections from other clients on the network.

In Tor mode syncthing wouldn’t broadcasting anything UDP to not leak metadata. No bootstrapping nodes needed with this mode, it would be enough to listen on a port and wait for a connection and carry out authentication when it happens.

Adding support for TCP in bootstrapping nodes via websockets. All broadcasts are TCP only and obey socks proxy rules. This is good for other reasons besides Tor. Sometimes the only internet connection there is has a restrictive firewall that drops all UDP traffic.


Just a question, but would it be possible to run syncthing over OnionCat as a way of using tor (assuming all nodes are running OnionCat)?

We support SOCKS proxies now, so in theory it should work to connect out using Tor at least. Set the environment variable all_proxy=socks5://ip:port prior to starting Syncthing.

Although frankly I’m not sure what you gain by running Syncthing over Tor? Hiding your source IP from your trusted friends and own devices? Hiding the fact that you’re using Syncthing from your ISP?


For me it’s not so much as hidding syncthing and an easy way for me to avoid router configuration and changing ip addresses. Not just syncthing, but in general. If I am running things on a laptop or other mobile device, my servers stay (well reconnect) as I move about and connect to other hotspots (my phone runs a webserver that is available via tor while I sit in the coffee shop connected to their free wifi - yes it goes down when I move between networks, but it’s a personal site, not production).

Once I have tor up an running on each machine, then running over tor have a good chance of connecting.

Also, I am quite happy to hide anything and everything from my ISP and any other snoopers, just on principle :smile:

1 Like

Hi, I am also interested in using syncthing via Tor as a hidden service. I am volunteer of an NGO ( www.peacebrigades.org ) which activity is protective nonviolent accompanying in areas where the Human Rights are threatened, such as Colombia, Honduras, Mexico, Guatemala, Kenya. Our teams on the field already use ST to share folders which contain important information about the persons we accompany. Information that we must protect as long as we can. In such a context, surveillance by governmental and nongovernmental entities is almost certain. I have already set up a network of nodes which all connect to a central node in Europe via VPN (we also have timezone problems). Discovery and relays are disabled on all nodes, even though in other contexts they are great features.

It works fine, but it would be better for us to be able to connect over Tor in order to hide the IP and location of the central node.

I have tried to configure ST to use the socks proxy by setting the all_proxy variable and setting the device address of the central node to tcp://hiddenservicename.onion:22000 but it does not connect. I have set STTRACE=connection,dialer,main and run ST -verbose but no helpful message appears in the log file. We are running the latest version of the software (0.12.11).

It would be great to receive some help in getting it work. Thanks in advance for your attention and congratulations for the great work you all do.
Best regards

I have given a wrong info in my previous post. The test I did was from a Windows box. No error in the log file. I have tested again from a Linux box and I get this error: [UTXVT] 2016/01/05 18:33:04.124328 connections_tcp.go:37: DEBUG: lookup xxx.onion on no such host It does not use the proxy for the lookup, so it fails.

I think OnionCat may be a possible solution (at least on linux) although I don’t have the hardware to a able to properly try this out at the moment.
AFAIK, OnionCat creates a new IPv6 interface that tunnels through tor. As it uses IPv6 addresses dns would not be necessary…
Or maybe I’m just barking up the wrong tree (chasing an OnionCat)

Unfortunately it is not a viable solution for us because we have a mix of OSs in the cluster: Windows (different versions of it), Linux, OS X and Android.

@tonirug Try proxychains-ng

also you might want to use letsencrypt for your website since it is non-ssl goverments can start by tracking your users activity on the site.

This is probably something we should look into; we shouldn’t be trying DNS resolution at all when using a proxy.

I’d argue it’s sometimes wanted: in the case of a corporate proxy, it’s likely that DNS is available (separately to the proxy), but the proxy is required to reach the outside world.

Surly, as long as the proxy can get to your dns? Unless you need to resolve the address of the proxy.

It’s a problem I’ve encountered with other apps too, not just ST. I guess it’s a balance between resolving the address and passing the ip to the proxy, against passing the name, and have the proxy resolve it. Unfortunately, with .onion addresses, there is no IP to resolve.

So. Can (should) ST work with other ST nodes completely over tor using the all_proxy environment, or is it more complicated?

I have started to play around with OnionCat but the documentation I have found so far is leaving me scratching my head a bit. It should be usable on OSX, Win, Linux and Android so might still be viable for @tonirug, but so far I’ve only had any success between an Ubuntu box and a Debian box

Thanks to all for the answers. Actually, we already have a workaround in place, which is connecting ST through an OpenVPN server running as a Tor hidden service. It would be nice to avoid this extra layer and being able to reach a ST node as a Tor hidden service. At the moment it is not possible due to the .onion hostname resolution problem. I hope it will be possible in a future version of Syncthing.

Try this build and see if it makes the difference (in combination with all_proxy=socks5://...):

http://build3.syncthing.net/job/syncthing-pr/1436/ (click “Expand” under “Build Artifacts”)

It looks like we’re simply doing a resolve where we can get away with not doing one and letting the dialer (or proxy, as the case may be) do it.


It works!!! It connects and syncs fine. Tested on the Windows box. I will test it better in the next days. Thanks a lot Jacob!


I’m getting an error trying to un-compress the syncthing-windows-amd64-v0.12.11+14-g1506973.zip file :frowning:

Please copy and paste the error message so we can read it.

It’s been merged, so you can use the latest development build or wait for the release on Sunday otherwise.

1 Like

It was a zip error, probably corrupted during down load, but it repeated after 2 more downloads to the corrupted file was probably cached somewhere. I’ll probably wait until Sunday to try it now as I’m busy breaking other things today :open_mouth: