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.


#6

Well a few observations come to mind:

  1. Many of the apps are currently only using a proprietary interface, such as bookmarks and notes. If clients and the server were willing to support an E2E mode for these apps, then it would not break existing functionality. Then notes could be secure even if calendar and contacts could not be.
  2. E2E is specified as allowing enhanced security at the expense of server-side accessibility. That some users may need web access to their data more than security by no means implies that some users will not need security more. A web interface, though impossible with E2E, is not the only benefit of using the extension apps. Those that use E2E could still synchronize their devices.
  3. If apps support some granularity respecting what is encrypted, then the same users can enjoy both benefits on a case-by-case basis.
  4. If feasible, propriety extensions could be considered for the open interfaces in current use, such as CalDAV and CardDAV. (Alternatively, separate interfaces could be considered if extending the existing ones is impracticable.) Then, users could benefit from security when using clients designed for NextCloud.
  5. If such extensions are specified such that generic clients would be able to adopt the interface and integrate with them, then users could benefit from the security with generic clients that have implemented the interface.
  6. As Nextcloud is an open platform, its solutions could serve as a basis of a community standard, if the demand exists to drive development and adoption.
  7. App-level integration of encryption could be addressed by enhancing the plugin interface between app and platform (e.g. secure store and secure retrieve operations for metadata, with the security considerations occurring within the platform).