New user questions and clarifications

[Drizzt321]

So new to SyncThing, have done some reading on the documentation, wanted to be sure my understanding was correct.

First, SyncThing isn’t exactly a “server” and “clients”, it’s 2 or more peer hosts that, via Device ID, allow each other to sync folders and files between each other. However, this relies on being on the same LAN to see each other directly.

To overcome this, there’s some global servers and relays that essentially allow for rendezvous and relay connections so that data/syncing can go between each of the hosts. The global servers (SyncThing run) and relays (nice strangers on the Internet) are required so, for example, my NAS at home and my phone when I’m elsewhere can talk to each other when they need to sync.

If I want to directly connect the hosts, I’ll need to run my own Relay (private or publicly listed), and point my non-home devices (e.g. phone, laptop, etc) to the hostname I setup on my dyndns (with port forward rules) which points to where I’ve setup my relay.

Global listing and global relays can be turned off on the hosts, which means I’d need to be on the local network and/or private relay.

Due to the design of the system, I can’t, for example, use Nginx reverse proxy with Lets Encrypt auto-updating certificates?

Security is TLS, and I can configure keys/certificates, but there’s no automatic Lets Encrypt auto-update certs for a given domain/host. Not necessarily a problem, the Device ID (e.g. TLS/cert fingerprint) of the requesting host is compared to a list of allowed IDs. Since it’s computed/sent by the Private key, and can be verified by the Public key, this provides assurances it’s the actual remote host you want to allow.

However…it’s potentially possible to intercept these certificate exchanges, which would then allow impersonating of devices.

This certificate exchange is done once, whenever a new device is setup on the other hosts to allow access? So if I’m on my own local network, with the other devices, should be secure because it’s done once locally, and thereafter the public/private key generates the session keys/etc as per TLS/SSL? This isn’t made clear to me in Security Principles — Syncthing documentation

Otherwise, I should just do SSH tunneling, or VPN setup to my own network so it appears I’m local.

EDIT: Found this doc page Understanding Device IDs — Syncthing documentation does a better job of explaining to me the key exchange/device id. Basically the TLS public key (or cryptographic part) is hashed to generate the Device ID. As part of the TLS connection/setup/key exchange, each device on the other side confirms the Device ID via the Public Key, and the Public Key is validated that it’s talking to the correct other end due to the correctness of the TLS exchange/validation protocol.

[bt90]

@Drizzt321

However…it’s potentially possible to intercept these certificate exchanges, which would then allow impersonating of devices.

In short: no

Syncthing is using plain old public-key cryptography. The only thing that needs to stay safe is the private key of each device. And these are never transfered.

[Drizzt321]

Ha! Just did an edit on my post, found Understanding Device IDs — Syncthing documentation. Makes a lot more sense, since it’s part of the public key that it uses to generate the Device ID. So the TLS protocol assures we’re getting the right Public Key, and the hashing of the Public Key assures we’re getting the right Device ID.

Got it now.

And if I’m paranoid enough, I can generate my own self-signed or externally signed keys with a different Common Name, and set my systems config to use that alternative Common Name.

[acolomb (André Colomb)]

Regarding reverse proxies, you can do that for remote GUI access for example. But for the BEP protocol ports, you need to make sure that the other end sees the correct certificate, not some man-in-the-middle intercepting TLS proxy with a different (e.g. Let’s Encrypt) certificate.

You can run fine over the Internet, not only locally, without even using global discovery or relay servers. But then you must point at least one of the devices to a fixed address of the other, and port forwarding / firewall ports must be configured appropriately.

Using SSH or VPN tunneling is usually not necessary if you can configure the network to be accessible. It doesn’t really increase security, but on the contrary opens up another service that could theoretically be abused for different accesses. Like when you have the SSH port open externally, one could try a direct attack on that and possibly gain shell access, while exposing only Syncthing’s ports will expose your Syncthing instance at worst.

[AudriusButkevicius]

Note that syncthing tries very hard to connect directly even in absence of relays etc, via various NAT bypass techniques. So “in needs to be in LAN to connect directly” is sort of false if the network conditions are good, unless you also opt out of discovery and didn’t configure port forwarding manually.