Switched a node to use Tor: an unknown device wanted to join all my other devices within minutes


(Daniel) #1

I switched my Android phone node to use Tor. Just to see if it would work more than anything. After a few seconds I could confirm that it did indeed work: it could connect, and send and receive data from my other nodes.

However, about two minutes later an unknown device ID attempted to connect to all my other nodes (excluding my phone). The new device was connecting from the IP address of a Tor exit node.

Any idea how that unknown device got my device IDs? I’m assuming it was observed traveling out of the Tor network either at or immediately upstream of the the Tor exit node.

I’d disabled local device discovery prior to enabling Tor. Tor drops UDP packets so it shouldn’t really have made any difference.

In the future, I’ll consider using Syncthing over I2P instead.


(Antony Male) #2

Any idea how that unknown device got my device IDs?

Anyone who was sniffing your Syncthing traffic can easily get your Device ID .


(uok) #3

How did you see that, did you get a popup in the GUI?
Are you sure it is not one of your own devices? Or a friend?


(Daniel) #4

How did you see that, did you get a popup in the GUI? Are you sure it is not one of your own devices? Or a friend?

It popped up in the web UI of all my nodes and the device ID and IP showed up six–eight times in the logs of all my devices.

All of my own devices and device IDs are accounted for. The ID was not mine. I only use Syncthing for my own private use and haven’t shared my device IDs with anyone else.


(Jakob Borg) #5

You can probably count on all Tor traffic being very invasively monitored and any interesting endpoints probed. Probably it’s such probes you’re seeing. Maybe it’s a Syncthing specific probe that will grab your files if you accept, maybe it’s just a HTTPS/TLS probe.

I realise there are varied reasons for using Tor, but conversely you should realise that by using tor you are sending your traffic to be man-in-the-middled by an unknown, likely shady, third party. Syncthing is resistant to that as long as you don’t do something unwise like accept connection requests from unknown devices.


(uok) #6

@Daniel: have you looked at the IP - another TOR node?

But what happens if you accept the request from the unknown IP? You get request for folder sharing next, e.g. “please upload your files here”? :laughing: I don’t understand the idea behind this.


(Jakob Borg) #7

If someone mistakenly does accept the new device, I’d put even odds on them also sharing a folder or two.

Syncthing is probably also a good de-anonymizer on its own, as you’ll likely be able to look up the IP of the other side once you know their device ID, no accept needed.

If the connection was accepted Syncthing will also try hard to reach out to the added device via any available connection inside or outside of Tor.


(Daniel) #8

The new device was connecting from the IP address of a Tor exit node.

@Daniel: have you looked at the IP - another TOR node?

Indeed.

But what happens if you accept the request from the unknown IP? You get request for folder sharing next, e.g. “please upload your files here”? :laughing: I don’t understand the idea behind this.

I didn’t accept the request so I don’t really know what they wanted.


(Daniel) #9

I realise there are varied reasons for using Tor, but conversely you should realise that by using tor you are sending your traffic to be man-in-the-middled by an unknown, likely shady, third party.

I personally don’t need the anonymity but I occasionally “play” with Tor just to see how it works. My own boring use of Tor is mostly limited to doing a few generic web searches and reading a blog or two. However, my boring use of Tor does help hide the traffic for people who do need the anonymity offered by Tor.

In this case, I was considering setting up a Tor hidden service for Syncthing on my phone to not having to deal with Syncthing’s relays or NATing. (My home ISP disabled IPv6 two years ago following an acquisition by another ISP who — I guess — wanted to save on peering and infrastructure costs.)

Syncthing is resistant to that as long as you don’t do something unwise like accept connection requests from unknown devices.

It’s an opportune moment to try something like this, though. Say you’re adding a new device through Tor and you expect to see a new device prompt. Who is crazy enough to actually check on device IDs manually? (Other than me, that is.)

I believe people would be less likely to accept random devices if the permission GUI also displayed the IP address that the request originated from. In this case it would have shown a completely unknown ID coming from a completely unknown IP address.


(Daniel) #10

It could be interesting to check on the device ID in any logs for the discovery servers or any other places where the device ID might be used. Assuming there is anywhere in Syncthing’s centralized infrastructure that logs the device ID.

I can provide the device ID in question to anyone emailing me through the email address I’m registered with on this forum. (It’s a unique address for this forum so knowing it will serve as your proof of admin credentials.)


(Jakob Borg) #11

There’s no central logging. You can look it up in the discovery servers, if it has announced itself there:

$ curl -ks https://discovery.syncthing.net/?device=PSEUDOP-...-E2SWOA2 | jsonfmt
{
  "seen": "2019-02-05T13:16:34.092941799Z",
  "addresses": [
    "tcp://...:22000"
  ]
}

Also depending on precisely what prompt you got it might not necessarily be a syncthing at all, just someone negotiating TLS and providing a certificate when asked.


(uok) #12

@calmh I think this is a good idea. Maybe if possible also display DNS name?
This would help e.g. if you work in Germany and get a request from unknown IP you will see “device from dialin123.example.jp (111.222.333.444) wants to connect to you” which gives you more info that this request should be blocked (if you don’t know anybody in Japan)

Open new issue?

@Aeyoun you could try to run a completely new Syncthing instance and see if it happens again if you are connected using TOR


(Jakob Borg) #13

I’m skeptical. A reverse lookup might help, but the IP on its own will be completely meaningless for most users. Also, it might legitimately be consumer broadband in Japan even if the device is in Germany, because relays… We could maybe then hide it for relay connections…

But again, I’m not convinced of the value here. If you’re not expecting a new device connection you should not accept it, regardless.


(uok) #14

Ok, I see your point. Does Syncthing know if a request comes via relay?


(Jakob Borg) #15

It does, so as I mentioned you could skip showing it in that case. But then if you were malicious, why would you not use a relay? It both hides your real source and makes us not display it.


(Audrius Butkevicius) #16

We already show device names (in terms of what is set in syncthing) by reading the hello message. If the connections have no name, it’s probably just a tls probe which did not get past hello message.

No, no new issues.


(Antony Male) #17

If Syncthing can tell the difference between a random TLS connection and a connection from an actual Syncthing device, why don’t we only show the popup if an actual Syncthing device tries to connect?


(Audrius Butkevicius) #18

I think (I am not sure, would have to check), that’s just how it’s implemented to support backwards compatability before hello messages. Perhaps this was a genuine syncthing specific probe and I am just talking garbage.


(Jakob Borg) #19

I’m 99% sure we only show the “add device” dialog when the other side actually does speak our protocol. But other connection attempts that get at least as far as presenting a certificate, and then error out by talking unintelligeble gibberish, also generate a “popup” as they cause a warning level log message - “Connecting to $deviceID: protocol error: unknown perhaps newer protocol version” or something like that like Audrius mentions. So it depends on what exactly the popup / message was.

(There’s also the certificate common name check, but this happens quite late. It needs to look up the device in the config to see if it might have a custom common name, and the “add device” happens prior to that… For some reason.)


(Audrius Butkevicius) #20

Actually having checked the code at home, the trying to connect pop up would only come up if valid hello magic was sent.