Syncthing and PCI Compliance

Has anyone passed PCI compliance with ports open to Syncthing nodes? Tests want all certificate signed by CAs (fake sense of security, but these are the requirements).

I have a business to run. It is sad that there is such a low a level of understanding of real security, and that real security actually comes back as a vulnerability. If one uses Google Drive, Onedrive, Dropbox, and iCloud to store client payment information all is well for PCI purposes, but a Syncthing node is unsecure? What a joke.

If anyone has passed PCI compliance without the obvious temporary solution please let me know.

I am not sure what’s involved in PCI compliance, but you can use your own certs that can be signed by your own CA. That will change the device id, but not sure it matters to you.

If thd subject name is not syncthing, there is certName param on the device config object that you can use to set the expected subject name (check docs for details, might got the name wrong).

Syncthing will however only accept connections that involve exactly one certificate on the wire and in the CA-signed world you typically have at least one intermediate certificate send by the server. This is something syncthing does not currently support, so one would need a CA signed cert that can work without an intermediate.

Do the requirements actually check the chain involved, or can you get away with just sending something that looks like it’s signed?

I generally have the feeling that this will not work well, as requirements for “public” certificates differ significantly from internal certificates. I’m not sure what the PCI requirements are, but for publicy trusted certificates you have lifetime restrictions etc that will work horribly (or not at all) with syncthing (e.g the requirement of replacing certificates every n days). There are simply different design philosophy involved that oppose each other (out of band authentication vs the CA trust model).

Syncthing doesn’t check if it’s signed or not, so as long as whatever process checks for compliance is aware of the CA, it should be enough to have the leaf certificate.

But yes, the certs changing every some time, means the device id changes, which means you’ve got to re-setup everything from scratch.

We all learned something from this that should be kept in mind (although obvious when think about it). Changing a cert will disconnect nodes.

Am not going to test it, but assume the fake security scan will find any cert invalid if the chain is invalid (same as every web browser).

I know a little about PCI from the point of view of providing a PCI compliant service. My opinion based on the experience I have is that you are best following the path of least resistance, using an approved service, unless you want to spend a massive amount of time on it.

When I did DSS PCI compliance testing (some years back so it might have changed, and this is in the UK), it’s usually to check that there’s no open ports / bad fwding on the router and in some cases, checks if the PC is patched up to date. I would guess that Syncthing would be fine since you wouldn’t normally manually port forward. I doubt it would even be picked up.

You could simply turn off Syncthing during the test.

Or, if it’s just to have a card reader, they are usually directly connected to the internet so put it on it’s own Vlan then it’s totally invisible to the rest of your network.

I have a feeling that the CA is a red herring since you are not hosting a website that people are logging into and PCI is about ensuring your system is secure internally.

Prefer to use Syncthing directly (without relays using port forwarding) for two reasons. First, syncing is not limited by relay speed. Second, it is a little more secure because relays cannot intercept encrypted packets. Relays are great (run one), but why use if don’t need to.

PCI compliance requires compliance at the time of the scan. The path of least resistance is to be compliant with their fake security standards at the time of the scan.