E2E: Is it ready?

e2e

#1

Development for Nextcloud is very active, and it is very hard to evaluate the current status, particularly with respect to new features such as client-side encryption.

Deciding whether to adopt the feature depends on understanding whether it is mature enough to be safe and stable. I have had difficulty finding a consensus opinion on this subject. My understanding is that E2E is included in recent releases, but how thoroughly has it been tested to date? Does it yet meet its promise to avoid data corruption while at the same time providing a high level of security against attack? Can someone better informed about recent developments offer a summary of the current status?

(Note, I am aware of a serious problem on the desktop client, affecting any site for which E2E is enabled administratively, regardless of whether data any folders are marked for encryption. At minimum, this problem would need to be resolved before adoption is feasible.)

Thanks for the help.


#2

Unless all clients support this feature reliably, I wouldn’t call this feature ready and well tested. There is a schedule for the desktop client (https://github.com/nextcloud/desktop/wiki/Desktop-Client-Roadmap) and the 2.5 branch was supposed to add the end to end encryption. To be stable, it probably still needs some releases. But on the desktop client, it is hard to predict the development. With the main server branch the releases come more regularly and it is easier to see new features coming (related beta tests etc.).

I don’t know if there was an external review process or if something is planned. You normally speak of a high level security if a product has been out for some time, was tested by different experts and no major bugs have been found for some time. Due to the open source code, everybody can do a security audit or ask someone to do it (or via crowd funding). If you have an enterprise subscription, you get dedicated support on Nextcloud and they can afford the resources to improve features.


#3

No, it is not. Actually, it is dangerous to rely on it because of these bugs:

This means subfolders in a supposedly encrypted folder (showing the lock sign on the client) are uploaded unencrypted. But because normal users cannot open the folder in the web UI to see at least the encrypted data to verify it got encrypted they feel “safe” while everybody else (malicious admin or an attacker who compromised the server) can read the data from all the subfolders uploaded unencrypted to the server while giving the user a complete false sense of security. This bug is still not fixed even though it is probably the most serious security issue of all.

Aside from that, the encryption and upload process is really slow for even tiny files (which is not surprising because it was officially announced that this would be the case), so for the time being, relying on E2EE provided by Nextcloud is not a good idea (even though I would really like to see taking off because a well integrated solution is much better than having to rely on additional tools).


#4

Thanks for the useful replies.

Do you have a reference? Is the implication that the per-file overhead would be resolved in upcoming releases, or does it reflect a design limitation that we would have to accept long term as a consequence of choosing E2E?

More generally, have any announcements been made about audits or testing, done by any independent security expert groups, that would help us evaluate reliability and security when the appropriate point is reached in development efforts?

One final question, is support for E2E planned to expand to extension apps, for example, if a user wanted bookmarks or notes to be shared across devices but encrypted on the client side? So far, I have only heard about folder-level encryption, whereas substantial metadata are currently persisted in database tables, and sent in both directions over the RESTful interface.


#5

Here you go (last paragraph):

Good question, the specification on how it works is located here:

This was already discussed several times here (for example for CalDAV/CardDAV), the problem is that at least for both those there is no standard and adding encryption would make it basically a proprietary format not supported by any other client out there. Aside from that, for other apps it would have to be implemented separately for every single app because they are more or less independent. Additionally the web interface would be pretty useless if everything is encrypted because accessing all of this from a browser requires a trusted server if the credentials are sent to this specific server which defeats client side encryption completely.