NAME

       syncthing-security - Security Principles

       Security  is  one of the primary project goals. This means that it should not be possible for an attacker
       to join a cluster uninvited,  and  it  should  not  be  possible  to  extract  private  information  from
       intercepted traffic. Currently this is implemented as follows.

       All  device  to  device traffic is protected by TLS. To prevent uninvited devices from joining a cluster,
       the certificate fingerprint of each device is  compared  to  a  preset  list  of  acceptable  devices  at
       connection  establishment.  The  fingerprint  is  computed  as  the  SHA-256  hash of the certificate and
       displayed in a human-friendly encoding, called Device ID.

       Incoming requests for file data are verified to the extent that the requested file name must exist in the
       local index and the global model.

       For information about ensuring you are running the code you think you  are  and  for  reporting  security
       vulnerabilities, please see the official security page <https://syncthing.net/security>.

INFORMATION LEAKAGE

   Global Discovery
       When  global  discovery  is  enabled,  Syncthing  sends  an  announcement  every 30 minutes to the global
       discovery servers so that they  can  keep  a  mapping  between  your  device  ID  and  external  IP.  The
       announcement  contain  the  device  ID and listening port(s). Also, when connecting to other devices that
       have not been seen on the local network, a query is sent to the global discovery servers  containing  the
       device  ID of the requested device. The connection to the discovery server is encrypted using TLS and the
       discovery server certificate is verified, so the contents of  the  query  should  be  considered  private
       between  the  device  and  the  discovery  server.  The  discovery servers are currently hosted by @calmh
       <https://github.com/calmh>. Global discovery defaults to on.

       When turned off, devices with dynamic addresses not on the local network cannot be  found  and  connected
       to.

       An  eavesdropper  on  the  Internet can deduce which machines are running Syncthing with global discovery
       enabled, and what their device IDs are.

       The operator of the discovery server can map arbitrary device addresses to IP addresses, and deduce which
       devices are connected to each other.

       If a different global discovery server is configured, no data is sent to  the  default  global  discovery
       servers.

   Local Discovery
       When  local  discovery  is  enabled, Syncthing sends broadcast (IPv4) and multicast (IPv6) packets to the
       local network every 30 seconds. The packets contain the device ID and  listening  port.  Local  discovery
       defaults to on.

       An eavesdropper on the local network can deduce which machines are running Syncthing with local discovery
       enabled, and what their device IDs are.

       When turned off, devices with dynamic addresses on the local network cannot be found and connected to.

   Upgrade Checks
       When  automatic  upgrades  are enabled, Syncthing checks for a new version at startup and then once every
       twelve hours. This is by an HTTPS request to the download site for releases, currently hosted  by  @calmh
       <https://github.com/calmh>.   Automatic  upgrades  default  to  on  (unless  Syncthing  was compiled with
       upgrades disabled).

       Even when automatic upgrades are disabled in the configuration, an upgrade check as above  is  done  when
       the  GUI  is loaded, in order to show the “Upgrade to …” button when necessary. This can be disabled only
       by compiling Syncthing with upgrades disabled.

       The actual download, should an upgrade be available, is done from GitHub, thus exposing the user to them.

       The upgrade check (or download) requests do not contain any identifiable information about  the  user  or
       device.

   Usage Reporting
       When  usage  reporting  is  enabled, Syncthing reports usage data at startup and then every 24 hours. The
       report  is  sent  as  an  HTTPS  POST  to  the  usage  reporting  server,  currently  hosted  by   @calmh
       <https://github.com/calmh>.  The  contents  of  the usage report can be seen behind the “Preview” link in
       settings. Usage reporting defaults to off but the GUI will ask once about enabling it, shortly after  the
       first install.

       The  reported  data  is  protected  from  eavesdroppers, but the connection to the usage reporting server
       itself may expose the client as running Syncthing.

   Sync Connections (BEP)
       Sync connections are attempted to all configured devices, when the address is possible  to  resolve.  The
       sync  connection is based on TLS 1.2 or TLS 1.3. The TLS certificates can be obtained by an eavesdropper,
       although it is more difficult to do so in TLS 1.3. This means that the contents of  the  certificate  are
       visible, which includes certificate Common Name (by default syncthing).

       An  eavesdropper can deduce that this is a Syncthing connection and under certain circumstances calculate
       the device IDs involved based on the hashes of the sent certificates.

       Likewise, if the sync port (default 22000) is accessible from the internet, a port scanner  may  discover
       it,  attempt a TLS negotiation and thus obtain the device certificate. This provides the same information
       as in the eavesdropper case.

   Relay Connections
       When relaying is enabled, Syncthing will look up the pool of public relays and establish a connection  to
       one  of  them  (the  best,  based  on  an  internal  heuristic). The selected relay server will learn the
       connecting device’s device ID. Relay servers can be run  by  anyone  in  the  general  public.   Relaying
       defaults to on. Syncthing can be configured to disable relaying, or only use specific relays.

       If a relay connections is required between two devices, the relay will learn the other device’s device ID
       as well.

       Any  data  exchanged  between  the two devices is encrypted as usual and not subject to inspection by the
       relay.

   Web GUI
       If the web GUI is accessible, it exposes the device as running Syncthing. The web GUI defaults  to  being
       reachable from the local host only.

IN SHORT

       Parties  doing  surveillance on your network (whether that be corporate IT, the NSA or someone else) will
       be  able  to  see  that  you  use  Syncthing,  and   your   device   IDs   are   OK   to   share   anyway
       <https://docs.syncthing.net/users/faq.html#should-i-keep-my-device-ids-secret>,     but     the    actual
       transmitted data is protected as well as we can. Knowing your device ID can expose your IP address, using
       global discovery.

PROTECTING YOUR SYNCTHING KEYS AND IDENTITY

       Anyone who can access the Syncthing TLS keys and config file on your device can impersonate your  device,
       connect  to  your  peers,  and then have access to your synced files. Here are some general principles to
       protect your files:

       1. If a device of yours is lost, make sure to revoke its access from your other devices.

       2. If you’re syncing confidential data on an encrypted disk  to  guard  against  device  theft,  put  the
          Syncthing  config  folder on the same encrypted disk to avoid leaking keys and metadata. Or, use whole
          disk encryption.

AUTHOR

       The Syncthing Authors

COPYRIGHT

       2014-2019, The Syncthing Authors

v1.27.0                                           Dec 21, 2023                             SYNCTHING-SECURITY(7)