I’ve read the Documentation and scoured the forums.
I just wanted an additional opinion regarding the Relay WAN connection type and whether I’m understanding it correctly. Because I have to use relays for numerous reasons.
Everything is E2E encrypted via TLS and the relays cannot read/inspect any of the data passing through.
On top of TLS, the syncthing protocol only allows authorised devices to communicate with each other.
So if somehow there’s a vulnerability in TLS (which will have global catastrophic implications, not only affecting Syncthing) the relays still won’t be able to see the data passing through as they are not authorised, correct?
A MiTM man-in-the-middle attack isn’t realistically possible.
The only thing the relays see is your IP and Syncthing ID.
Please let me know if I’m incorrect and/or I’m missing something, thanks a lot !!
Authentication - is the other side really who they claim they are?
Confidentiality - the only parties who can read the data are ourselves and the other side
Integrity - has the data been manipulated while being transmitted?
A relay is, by definition, a MiTM (though generally not an attacker, so not evil). Protection against MiTM attacks is what TLS is all about: If no one looks at your data, you wouldn’t need TLS in the first place.
Technically the relays see a bit of metadata as well: Who’s talking to who, how much data is exchanged? This is a minor amount of information, but it’s more than zero. However, this information is also available to anyone who listens to your internet traffic - and that’s a significantly larger attack surface than the relays themselves.
Yes and No. AES is a cryptographic primitive: It is an algorithm used within many security protocols, but it’s only a (medium-sized) cog in the machine. Breaking TLS is not the same as breaking AES.
However, worrying about this is roughly equivalent to worrying about being killed by a meteorite falling from the sky. It’s not that TLS exploits don’t happen: There were multiple in the past (though security has improved a lot on various levels since then). It’s just that there are far, far more likely problems to occur to you first. Think about this way: If someone wants your data so desperately that they’re willing to invest multiple millions of dollars for an attack, they’re just going to break into your house and steal everything. No TLS is going to protect you from that.
Double-encryption is unlikely to bring any benefit in practice. You’re primarily wasting CPU power for no actual reason.
Wow this is brilliant, thanks a lot for all the clarifications.
This is everything I needed to fill the gaps in my knowledge/understanding.
So using cryptomator in addition to Syncthing is essentially a waste of CPU power and time.
Plus, not to mention all the drawbacks that come with cryptomator like filenames being too long for android, corrupting data irreversibly due to inefficient communication between cryptomator and syncthing, etc.
Thanks a ton for your time. I really appreciate it.
I think if you do want to add one more layer, just enabling the encryption feature in Syncthing would suffice. It’s meant to share with other, untrusted devices which will hold the data and distribute to other devices, but cannot make sense of the encrypted blobs received. Unless they also have the password set when the originating device shared the folder with them. Then the data gets decrypted (the inner layer) locally after being pulled over the already encrypted TLS connection / possibly relays.
Hope someone will correct me if anything above is not accurate.
If you happen to have a need for “untrusted” devices in your Syncthing cluster, then this feature will get you the additional encryption layer as a side-effect.
Not inaccurate, but it’s a beta feature used in a mode that probably works, but isn’t the intent of the feature. So personally I’d consider any possible benefit to be dwarfed by the potential for complications.