What could a malicious discovery or relay server do?

General
1

The discovery server sees the device ID (the hash of the private certificate) and the IP address of each device, so this server knows which IP address is talking to which IP address using Synchting. The discovery server doesn’t exchange data, and even if it does, as in the relay server, the data is end to end encrypted, and cannot be accessed.

These servers can be run by anyone on the public Internet. It’s plausible to assume that some of them are malicious.

What kind of attacks are possible? How much is the attack surface?

For example, a malicious server could send a cleverly crafted packet. Which code in Synchting handles this packet?

1 Like
2

The certificate isn’t really “private”. It can be seen by anyone listening on the wire and contains a public key. Though in general your assessment is correct.

I’m assuming you’re referring to the relay servers here. The discovery servers syncthing uses by default are run only by the Syncthing Foundation (they can be changed to self-hosted ones in the settings).

The obvious and realistic attack for both malicious discovery server and relay servers is denial of service: A relay server can refuse to relay data, hence preventing successful sync. A discovery server can refuse to hand out connection information (or hand out wrong information, which is equivalent), also preventing sync.

Other than that, there isn’t anything possible without an explicit security vulnerability.

For relay servers, most of the data transferred is TLS-encrypted between the two syncthing peers. A relay server trying to inject or modify data packets would immediately fail data authentication in golang’s TLS implementation and the connection would be shutdown.

There is an exception though: The syncthing peer also has to exchange control information with the relay server itself. This data is, perhaps confusingly, also TLS encrypted, but in this case the relay server is the other end of the connection and hence can read the plain data. A security vulnerability in the relay protocol or its implementation might have more severe consequences. However, note that syncthing is written in Go, a memory safe language, which automatically prevents many common software vulnerabilities such as buffer overflow attacks. There has been one reported security vulnerability in the relay protocol implementation in the past, resulting in a client crash without data leaks.

The discovery server speaks HTTPS with the syncthing client. The implementation is golang’s standard HTTP client. Only connection metadata is exchanged via it. Its primary point of concern is privacy, since it can track IP addresses over a period of time (possibly geoprofiling users).

The TLS and http implementations used in syncthing are both widely used and were written by security professionals working for Google.

7 Likes
3

What about a “Harvest Now, Decrypt Later” attack?

1 Like
4

Yes, that attack works. But it works for all l https traffic, not specific to syncthing.

When TLS goes post quantum soon, this attack will no longer work.

5

Go (the language syncthing is written in) supports the Post-Quantum hybrid key exchange X25519MLKEM768 in current Go releases (1.24+). As such, if you trust Kyber to be secure in a PQ-environment, Go TLS handshakes can be reasonably secure.

Recent syncthing releases (1.29.3+) are using Go 1.24. However, I had a look with Wireshark, and all of my syncthing instances do not announce ML-KEM (Kyber) capabilities. All handshakes are still “traditional” X25519 (which is not PQ-secure). I could not identify the reason for this - a search of the syncthing code base does not reveal any settings that might disable Kyber in syncthing.

2 Likes
6

Yeah, PQ handshake is now available in GO, but syncthing has to use it. Syncthing itself probably needs a small code.

Maybe they are waiting to see how PQ key Exchange works in the wild before switching.

7

The “in Go x.y” features are a bit tricky, it’s not enough to build with the new compiler you also need to specify the new language version in go.mod, and we currently set that to 1.23 to enable building with a one generation old compiler. While it shouldn’t matter for things like this (as opposed to new language features), I think it means that as far as the build is concerned it still disables things that are only default-on in 1.24. Y’all who are interested could try with a rebuild after setting the language version to 1.24.

2 Likes
8

While I use a mesh VPN between my Syncthing devices mostly for other purposes, it’s the obvious way to avoid discovery and relay issues if your threat model requires that you mitigate “harvest now and decrypt later” attacks or other potential security issues.

9

Those are not PQ. Tailscale uses Go implementation of Wireguard which uses ed25519 for key exchange, just like syncthing.

In fact, while syncthing will probably get PQ soon, Tailscale has to wait for Wireguard which may take longer.

2 Likes
10

WireGuard supports key exchanges with an additional preshared key, which (if the preshared key has sufficient entropy) is PQ-secure. You cannot configure those PSKs in Tailscale though, this is documented as a known issue.

(Also: PSKs do not scale in a large system, so eventually the KEX should be upgraded. There’s work to add that to WireGuard, but PQC is still fairly new and experience levels are low. There’s a reason the current protocols are all hybrids…)

2 Likes
11

Nord claims to be (although it does not appear to be enabled by default). And whether they are or not, the “harvest now” threat doesn’t work for operators of malicious relays or discovery servers. Using mesh VPN means you can disable those options.

12

A lot of things do support PQ: just symmetrically encrypt client side, like with a preshared key. Point is, none of mesh VPNs do that (the user above says Nord has a mesh vpn offering does PQ, I haven’t checked).

Even if you build such mesh VPN, you have to think how to share that key in the first place. Maybe SSH or PQ TLS but it’s not really a good idea. At some point it’s going leak and is not forward secure.