From the website:
Encrypted. All communication is secured using TLS. The encryption used includes perfect forward secrecy to prevent any eavesdropper from ever gaining access to your data.
This is so misleading, I would call it a lie. TLS only encrypts the connection so the data is unencrypted on all devices. That means that compromising one of the endpoints at any point in time will compromise all the data and perfect forward secrecy for the transmitted data is almost meaningless.
It’s perfectly accurate so I don’t really see your point of view here. Your files are indeed unencrypted, unless you encrypt them. That has nothing to do with the communication protocol. The point of a secure communication protocol is to transfer information without disclosing it.
“All communication is encrypted, with a scheme which includes perfect forward secrecy” means "If someone eavesdrops on your communication (that is, they don’t have access to either device directly, but they can see the communication between them, e.g. someone sniffing traffic on a network) they won’t be able to see what data is being transferred, either now or at some point in the future).
Generally speaking, PFS means:
Yes, it’s formally correct. Hence my comment about misleading. I’m not saying the claim is wrong I just really dislike this kind of marketing.
Essentially the data at rest is unencrypted and then you make all kinds of statements about the connection. Which are technically true but besides the point.
Specifically perfect forward secrecy protects the data in transit (in the past) from a future server breach. But a server breach trivially compromises your data anyway because it is not encrypted at rest.
I dislike these claims because they imply that data on the server is somehow protected in a fashion which makes perfect forward secrecy relevant which they are iiuc not. (I would be happy to be corrected, that’s why I’m looking at this project anyway.)
I really don’t get your point, since the quoted sentence from the documentation in the original post talks all about “All communication is secured using TLS.”
It does not need to be a server breach, since you might leak your private key otherwise. Maybe there is a security issue in syncthing in the future which let’s you dump the private key over the network (I hope it won’t!)… Or you store your key on an unencrypted usb stick and you throw the stick away in the public transport. In these scenarios an attacker cannot make use of recorded syncthing traffic. That’s the sentence is all about.
I don’t see that claim being made in any way. Encrypting data at rest and data in transit are two very different things.
If Syncthing encrypted your data at rest, you would not be able to access your files! (This can be a good thing in a limited number of scenarios, but not in the majority of cases). Someone can gain access to your computer and read your files whether or not Syncthing is installed: Syncthing never claims that it will make your computer more secure.
The thing that Syncthing adds is the ability to transfer your files. Therefore encrypting data in transfer is important. This is what the claim relates to.
HTTPS encrypts your data in transit: if it encrypted it at rest, you would not be able to read the webpages you were browsing. That does not make all claims about HTTPS being secure “misleading”.
I don’t see any attempt there to claim (or anywhere else) that Syncthing encrypts your files on your computer. That statement is explicitly about communication, which is why it says “communication”.
How else would you word it?
Yes, but PFS is relevant in cases where there is compromise of long term secrets which is essentially a server breach.
Indeed it does not need to be a server breach but that is by far the most likely scenario since there is no real reason to have your private key on any other machine. Compromising syncthing in a way that would reveal its secret key would likely compromise the entire machine with at least syncthing rights in case which the data can be accessed anyway.
What functionality or behavior was it you expected, that you felt misled / lied to when it didn’t materialize?
As I said, PFS is basically irrelevant if data at rest is unencrypted.
In a client server scenario where I want to sync my files to/from an untrusted server it makes perfect sense to encrypt the files. That’s what I am looking for. Files should be encrypted before uploading and decrypted after downloading. If you compromise the server you get nothing.
Just don’t mention PFS. Clearly state that data is encrypted in transit with TLS and is stored unencrypted on the server. At least that’s the information that I was looking for.
I see your point and I’m sorry for my inappropriately strongly worded first post.
That was a real question, not a rhetorical one. 
If we imply something that we don’t actually do we could perhaps clarify that.
But then, as it is, it sounds like you just object to the usage of the term PFS because you don’t think it brings value. That’s fine but I disagree. Some of that may be related to the text being written a few years ago when there was a lot of discussion about intercepted communications by state actors etc. You may consider it marketing-speak for “we use a modern, sane TLS version with strong ciphers only”.
Maybe, if you want to keep it, you could just point out that the data on the server is unencrypted to avoid any confusion. I think that would be useful.
There is no server that stores your data. The point of syncthing (at least in it’s current stage of development) is to provide a way to securely synchronize several trusted devices, which are connected to each other via untrusted networks, without any central server to store your data. (basically, there is no untrusted server that stores your data, all the endpoints are “your”, trusted devices)
Regarding PFS claims: PFS is a known term in “computer world” that has specific meaning and definition. And its usage here is appropriate.
I simply consider my server to be one device which has very high availability but lower trust. Since I also don’t access the data on this device I would like it to stay encrypted.
This is not a feature offered by Syncthing, nor is it a feature advertised by Syncthing.
(There was work to implement it a while back, but it was never completed).
Too bad, would be a really cool feature. The open source sync software list on Wikipedia doesn’t even have a column for encryption.
Sounds like a useful and rather unique feature indeed. This would make having a cloud-hosted peer that others can use as a central exchange point much easier, for those cases where few cluster nodes do not happen to be online at the same time. The “server” peer could be a cheap virtual server instance without trust in memory or disk privacy.
The encrypted node would act kind of like a relay, but caching the encrypted content and would probably also need an encrypted index, only readable by other (trusted) peers. Sounds like an interesting implementation challenge to handle index updates without being able to decrypt them. Also, it’s hard to make sure the untrusted peer never gets the unencrypted data from one of the other “trusted” peers who turn out not to honor the restraint, for example because of a bug.
Anyway, I agree that the original statement regarding Syncthing’s encryption features is fully correct and not misleading. Introducing an untrusted device into the cluster leads to much bigger problems beyond data-at-rest encryption.
It is called “Encrypted Folders” in “Resilio Sync”.