Feature request: Trusted CA for automatic trust

I’ve been thinking about how Syncthing could potentially be used in a larger scale, for example in a business or a large and well-connected family.

One of my thoughts on making it easier to connect several devices is to have a Certificate Authority sign the Syncthing TLS certificate, and then have an option to automatically accept share requests from devices that have a certificate signed by a trusted CA. This could work somewhat like an extension of the “Introducer” feature, and would make it easier to share repos with numerous devices.

User story:

Bob, Fred, Alice and Jane all work for company XYZ. Their IT department has configured Syncthing for them all, and they use it to share files with each other for projects. Their TLS certificates are all signed by an XYZ CA (which is their own, not from Symantec etc).

Bob and Jane have already connected their devices and are sharing a repository project-foobar. Bob doesn’t really know how to use Syncthing, but Jane had helped him set up their shared folder.

Jane has started working with Fred on the project as well, and shares project-foobar with him. Bob had marked Jane as an Introducer in Syncthing, so now Bob will also share project-foobar with Fred.

Fred now wants to call in some help from Alice, who works in a different office. Bob previously hadn’t connected to Fred and so doesn’t have him marked as an Introducer, and neither does Jane. Because all are signed by the XYZ Certificate Authority, when Bob and Jane receive the request to share with Alice, Syncthing will automatically accept the request and all four now connect and share the repository.

What do people think about this? :grin:

1 Like

It’s a one way trip. Bob leaves the company and yet nobody can prevent bob from accessing the files.

1 Like

Ahhhhhhh no Bob why do you have to do that? But yes that does rather ruin my plan. I suppose then there would need to be certificate revocation lists, but that makes it far too hard and insecure.

Maybe something using the syncthing functionality could work. For instance store a signed list of all allowed users in a file inside the repository.

If the file is changed it is synced to all clients. When the new file’s signature is valid and newer it will update the settings (ie copy the file to the local settings folder). If the signature is invalid or older it could just do nothing and show a warning.

Bob might try to flood updates to prevent XYZ from updating the file, so that would be something to look into. I guess either one of the files would win resulting in either Bob being disconnected or XYZ seeing the warning and issuing a manual removal.

It would probably involve something like the proposal in https://github.com/syncthing/syncthing/issues/1015 “Introducers should be able to remove devices as well as add them”

But yeah perhaps something that instead of using a CA PKI model, there could be something like you suggest @HermanEldering: a certificate you designate as trusted, and a file which that certificate signs with a list of nodes you should share with if they request it. Something like a .sttrustednodes file that is synced between devices. That way when Alice joins the repository, Bob and Jane know to trust her - and when Bob leaves the company a new .sttrustednodes is synced which tells everyone to remove Bob. I suppose this is somewhat like a certificate revocation list.

To stop Bob from flooding updates to the file, Syncthing could check the time the file was signed (rather than just the filesystem level modified time) - but that would be significantly more complex than the existing file sync.

Yes, doing the signature timestamp check as part of the sync code instead of when processing the trusted nodes file would solve the flooding altogether. I don’t know about the complexity considerations, if Syncthing creates a temporary file (either on disk or in memory) it could perhaps do the check right before overwriting the original file and also apply the new settings at that time. Otherwise, if doing the check when processing the trusted nodes file it could work as a separate module from outside the Syncthing core.

Perhaps there are other Syncthing files that could also benefit from such a mechanism? Like maybe we could also do this signature checking with a global .stignore and maybe some other things too. Then it would possibly justify adding the complexity because it could be used for a variety of features.

Although then this trusted signature thing begins to sound like a solution in need of a problem. :stuck_out_tongue:

Or instead of trying to wedge something centralized in a decentralized system, you could build something on top, which queries some central server of yours and adds/removes devices on each of the peers.

1 Like

Yeah that sounds like a much better idea :grin:

I don’t necessarily think this would be any worse than the current “introducer” feature. In a corporate setting I’d set a single box as the central point, with the accept-by-CA feature enabled. Removing a device from this machine would black list it so that it doesn’t get re-added by certificate alone - much like the current “ignore” functionality for unknown devices that try to connect. Other devices in the cluster would either not get to know about the new device (everyone talks to the central point only), or would use the introducer feature with the hypothetical ability for the introducer to remove devices as well.

The other scenario is where all boxes are under the control of the same entity. Say, you want to be able to spin up a new cloud instance of whatever app and have a syncthing instance auto join and get some files. In this case the removal isn’t that much of an issue, and having a new device be accepted automatically would be neat.

For your second scenario though, I would have thought that there are more specific tools for getting files into a cloud instance of some sort - rsync for example.