1SYNCTHING-SECURITY(7) Syncthing SYNCTHING-SECURITY(7)
2
3
4
6 syncthing-security - Security Principles
7
8 Security is one of the primary project goals. This means that it should
9 not be possible for an attacker to join a cluster uninvited, and it
10 should not be possible to extract private information from intercepted
11 traffic. Currently this is implemented as follows.
12
13 All device to device traffic is protected by TLS. To prevent uninvited
14 devices from joining a cluster, the certificate fingerprint of each
15 device is compared to a preset list of acceptable devices at connection
16 establishment. The fingerprint is computed as the SHA-256 hash of the
17 certificate and displayed in BASE32 encoding to form a reasonably com‐
18 pact and convenient string.
19
20 Incoming requests for file data are verified to the extent that the
21 requested file name must exist in the local index and the global model.
22
23 For information about ensuring you are running the code you think you
24 are and for reporting security vulnerabilities, please see the official
25 security page <https://syncthing.net/security.html>.
26
28 Global Discovery
29 When global discovery is enabled, Syncthing sends an announcement every
30 30 minutes to the global discovery servers so that they can keep a map‐
31 ping between your device ID and external IP. The announcement contain
32 the device ID and listening port(s). Also, when connecting to other
33 devices that have not been seen on the local network, a query is sent
34 to the global discovery servers containing the device ID of the
35 requested device. The connection to the discovery server is encrypted
36 using TLS and the discovery server certificate is verified, so the con‐
37 tents of the query should be considered private between the device and
38 the discovery server. The discovery servers are currently hosted by
39 @calmh <https://github.com/calmh>. Global discovery defaults to on.
40
41 When turned off, devices with dynamic addresses not on the local net‐
42 work cannot be found and connected to.
43
44 An eavesdropper on the Internet can deduce which machines are running
45 Syncthing with global discovery enabled, and what their device IDs are.
46
47 The operator of the discovery server can map arbitrary device addresses
48 to IP addresses, and deduce which devices are connected to each other.
49
50 If a different global discovery server is configured, no data is sent
51 to the default global discovery servers.
52
53 Local Discovery
54 When local discovery is enabled, Syncthing sends broadcast (IPv4) and
55 multicast (IPv6) packets to the local network every 30 seconds. The
56 packets contain the device ID and listening port. Local discovery
57 defaults to on.
58
59 An eavesdropper on the local network can deduce which machines are run‐
60 ning Syncthing with local discovery enabled, and what their device IDs
61 are.
62
63 When turned off, devices with dynamic addresses on the local network
64 cannot be found and connected to.
65
66 Upgrade Checks
67 When automatic upgrades are enabled, Syncthing checks for a new version
68 at startup and then once every twelve hours. This is by an HTTPS
69 request to the download site for releases, currently hosted by @calmh
70 <https://github.com/calmh>. Automatic upgrades default to on (unless
71 Syncthing was compiled with upgrades disabled).
72
73 Even when automatic upgrades are disabled in the configuration, an
74 upgrade check as above is done when the GUI is loaded, in order to show
75 the “Upgrade to …” button when necessary. This can be disabled only by
76 compiling Syncthing with upgrades disabled.
77
78 The actual download, should an upgrade be available, is done from
79 GitHub, thus exposing the user to them.
80
81 The upgrade check (or download) requests do not contain any identifi‐
82 able information about the user or device.
83
84 Usage Reporting
85 When usage reporting is enabled, Syncthing reports usage data at
86 startup and then every 24 hours. The report is sent as an HTTPS POST to
87 the usage reporting server, currently hosted by @calmh
88 <https://github.com/calmh>. The contents of the usage report can be
89 seen behind the “Preview” link in settings. Usage reporting defaults to
90 off but the GUI will ask once about enabling it, shortly after the
91 first install.
92
93 The reported data is protected from eavesdroppers, but the connection
94 to the usage reporting server itself may expose the client as running
95 Syncthing.
96
97 Sync Connections (BEP)
98 Sync connections are attempted to all configured devices, when the
99 address is possible to resolve. The sync connection is based on TLS
100 1.2. The TLS certificates are sent in clear text (as in HTTPS etc),
101 meaning that the certificate Common Name (by default syncthing) is vis‐
102 ible.
103
104 An eavesdropper can deduce that this is a Syncthing connection and cal‐
105 culate the device IDs involved based on the hashes of the sent certifi‐
106 cates.
107
108 Likewise, if the sync port (default 22000) is accessible from the
109 internet, a port scanner may discover it, attempt a TLS negotiation and
110 thus obtain the device certificate. This provides the same information
111 as in the eavesdropper case.
112
113 Relay Connections
114 When relaying is enabled, Syncthing will look up the pool of public
115 relays and establish a connection to one of them (the best, based on an
116 internal heuristic). The selected relay server will learn the connect‐
117 ing device’s device ID. Relay servers can be run by anyone in the gen‐
118 eral public. Relaying defaults to on. Syncthing can be configured to
119 disable relaying, or only use specific relays.
120
121 If a relay connections is required between two devices, the relay will
122 learn the other device’s device ID as well.
123
124 Any data exchanged between the two devices is encrypted as usual and
125 not subject to inspection by the relay.
126
127 Web GUI
128 If the web GUI is accessible, it exposes the device as running Sync‐
129 thing. The web GUI defaults to being reachable from the local host
130 only.
131
133 Parties doing surveillance on your network (whether that be corporate
134 IT, the NSA or someone else) will be able to see that you use Sync‐
135 thing, and your device IDs are OK to share anyway <https://docs.sync‐
136 thing.net/users/faq.html#should-i-keep-my-device-ids-secret>, but the
137 actual transmitted data is protected as well as we can. Knowing your
138 device ID can expose your IP address, using global discovery.
139
141 Anyone who can access the Syncthing TLS keys and config file on your
142 device can impersonate your device, connect to your peers, and then
143 have access to your synced files. Here are some general principles to
144 protect your files:
145
146 1. If a device of yours is lost, make sure to revoke its access from
147 your other devices.
148
149 2. If you’re syncing confidential data on an encrypted disk to guard
150 against device theft, put the Syncthing config folder on the same
151 encrypted disk to avoid leaking keys and metadata. Or, use whole
152 disk encryption.
153
155 The Syncthing Authors
156
158 2014-2019, The Syncthing Authors
159
160
161
162
163v1 Jun 11, 2019 SYNCTHING-SECURITY(7)