Hi Ph00lt0, is there by any chance a ticket that explains/addresses the issues with this from a theoretical POV?
(disclaimer: Nextcloud guy here, I wrote the E2EE whitepaper on our website, so while I’m no dev I know the theoretical design of our E2EE fairly well).
The entire point of our E2EE is to protect you from a fully untrusted server, even if a Bad Person is in there permanently - so if there are issues with its design, the whole E2EE would be entirely pointless and I’d like to know
The passphrase is 12 random words from a large dictionary - that WE pick (so the user can’t pick a bad password) and only store locally, never on the server - that should, well, do the trick. Does this have a better solution? I mean, a QR code could be nice, that is something we want to add to make it easier to add other devices, but it’s not too hard to use as it is.
With regards to stability, we have large customers using E2EE with the latest version of the server, and we haven’t had any data loss or other issues for quite a while.
The main issue, in my opinion, is one of usability, with the E2EE pass phrase being hard to manage, something we fixed with 25 (where you can reset the E2EE from the web UI) and the 2.7 version of our client (which is a bit smarter in handling it, release is coming in a few weeks I believe).
I would like to ask to remove the warning, as it is certainly no more unstable or risky than the other solutions mentioned - it merely has more users and exists for a longer time than other solutions, which naturally results in more complaints to be found about it. Though maybe we wait a bit, so people are running the latest versions - running old software is never a good idea of course, but people do it anyway.
Edit: need to double-check the app store status, I’m confused now.
I don’t want to say everything is perfect, by the way - but then, no product is. And we of course work to improve things, all the time.
In terms of alternatives (sorry, reading up now on the whole thread): why not recommend TressorIT? They do E2EE file sync and exist for a long time. I haven’t used it myself but I don’t really see any con’s to it vs Proton Drive, which is also not open source or self-hosted/distributed. Just curious, not proposing to add them, but people asked for other alternatives…
(on a different note, I don’t get how one could recommend a E2EE solution that works through the web - I know there are lots of tricks these days, but still, trusting javascript coming from the server means, in my book, trusting the server. Or do Proton and Cryptee use an open source browser plugin? In that case, ignore me)
Glad you used a disclaimer, I personally was already aware. Cool to see you here on the forum btw, most welcome!
With all the respect, I must start to address a concern. The fact that you wrote the E2EE whitepaper while not being a developer or cryptographer, I am not sure how that is possible? It does sound problematic. The whitepaper is also very basic and doesn’t really explain architectural decisions. The whitepaper describes that you don’t use padding for GCM, which to me sounds very obvious, but it would be good to learn why you chose GCM (not saying it is a bad choice).
Generally I don’t have a good experience with Nextcloud’ techical understanding. I once have been told by one of the developers of the E2EE app that it is technically impossible to support this in the web app, which obviously is not true.
I am not sure on which issue you are asking for a POC? For the decryption attack I actually have tried to reach out to Nextcloud several times, but had not much luck in this. This has been quite some months/years ago. I am completely unaware of the status, as I have never heard anything back. It used to be possible to by moving the metadata file, instruct the desktop client to move files to an unencrypted folder. This resulted in the desktop client than uploading the file that was supposed to be E2EE in unencrypted form. Obviously this attack will likely go noticed at some point but it defeated the trust model. Perhaps it has been mitigated, who knows? I would love to retest this, but I am currently short on time so don’t expect me to run this any time soon. Perhaps you could verify whether such attack would now be possible with your architects.
Generally Nextcloud E2EE uses 128 bits which is fairly low. This may not be a problem now but will be in the very near future see: https://keylength.com
One of the concerns on stability was raised here: "Cannot sync due to invalid modification time" · Issue #4378 · nextcloud/desktop · GitHub
I still after months of this issue receive notifications about people struggling to get this resolved. No proper solution was build. Generally mistakes like this are horrible and should have been covered by unit tests. The fact that the backup app is often not up to date and incompatible with the latest version of Nextcloud (this happened several times) does not help this case.
I am not responsible the content of this website as I am not a team member at this point. I do however share the opinion that this warning is rightfully and deserved. Other solutions are at this point a better alternative in our eyes. Generally this community only recommends encryption software that has been properly audited.
I agree that the landscape is limited. I myself have been a huge fan and promoter of Nextcloud, sadly it never has became what I thought it would be and I have lost my faith. I see the organization building on all sorts of funky features and new apps but there is no coherent support of the current app base while almost all of them lack critical improvements. (https://github.com/nextcloud/desktop/issues/4536)
If you like open an discussion for suggestion of TressorIT please go ahead, but let’s keep this thread on topic.
We do not recommend the use of browser extensions as they allow for profiling of users. I understand your concern about Javascript comes from, however if you trust the author of the code you run, you can trust their JavaScript file. There is no difference in trust level here. With products that are hosted by several other companies that is another discussion. But Proton and Cryptee being closed source this argument does not apply.
I would also like to ask if the contacts and calendars are also protected with E2EE? I would like to use a remote VPS (Linode) as a host for my Nextcloud instance and sync via CalDAV and CardDAV. Does it make more sense to self-host and sync it at home?
When I say I wrote it - our security team gave me the info, I wrote it up in a… prettier way? Then they reviewed it
I certainly didn’t come up with any of the actual design, of course. It’s just that by writing & some back and forth, I have a fairly good idea of the design and the why’s behind it (I generally don’t like to write about something unless I know more than what I need to write down). But I’m no expert and your comment on GCM, for example, already flies over my head.
Generally I don’t have a good experience with Nextcloud’ techical understanding. I once have been told by one of the developers of the E2EE app that it is technically impossible to support this in the web app, which obviously is not true.
Well, a browser isn’t really much of a client - at least in my understanding. It’s more of an extension of the server, running code coming FROM the server - and if you don’t trust the server (from a threat model POV) then you can’t trust its code and thus… you can’t do this in the browser, strictly speaking. So if that’s true, then there isn’t that much benefit from using HTTPS or GPG-in-the-browser, right? If you trust the server, well, then, why not just use disk encryption & https, what is the benefit of the extra layer of encryption? Maybe a slight improvement, but not fundamentally different - an attacker (government, or somebody who broke in) who controls the server will simply send a piece of malicious javascript that steals the key. Ok, it’s a little harder, but that is not what people expect when you say end-to-end encryption. It is just marketing bla bla.
To me, End to end only makes sense with open source clients, at the least. Of course, if the server is proprietary and run by a company with venture capital, somebody will want to earn money on its sale, so the clock is ticking. But that’s a choice.
So I think a better model is fully open client and server tech, but that is entirely my opinion on this matter, of course.
(and I know there’s demand for browser-side encryption, and esp to upload to somebody it makes quite some sense. As long as it comes with a serious warning… people need to know it isn’t the same as client side encryption.)
I am not sure on which issue you are asking for a POC? For the decryption attack I actually have tried to reach out to Nextcloud several times, but had not much luck in this. This has been quite some months/years ago. I am completely unaware of the status, as I have never heard anything back. It used to be possible to by moving the metadata file, instruct the desktop client to move files to an unencrypted folder. This resulted in the desktop client than uploading the file that was supposed to be E2EE in unencrypted form. Obviously this attack will likely go noticed at some point but it defeated the trust model. Perhaps it has been mitigated, who knows? I would love to retest this, but I am currently short on time so don’t expect me to run this any time soon. Perhaps you could verify whether such attack would now be possible with your architects.
Ah, I guess you created a H1 issue for this? It seems a valid issue that I would hope has been addressed by now, but I will ask internally. I actually meant the passphrase thing you seemed to say wasn’t safe. But that there are other issues - like that one - that can be abused, yes, that is a good catch and should be fixed.
Generally Nextcloud E2EE uses 128 bits which is fairly low.
That’s something we could address going forward. I don’t know how urgent this is. Stability and performance have been our recent focus and continue to be worked on, next are some key features like sharing. As usual, if somebody considers this super important, they can help make it happen, either financially or by doing the work.
One of the concerns on stability was raised here:
I still after months of this issue receive notifications about people struggling to get this resolved. No proper solution was build. Generally mistakes like this are horrible and should have been covered by unit tests.
Hum, a ton of work was put in fixing this, including an extensive wiki page documenting it:
and scripts that can help fix it. If a programatic fix in the client or server had been possible, it would have been done. I recall the issue and we spend a ton of time discussing how it could be fixed transparently to the users/admins. We really don’t wish to inflict problems like this!
I agree it’s a horrible mistake and should not happen, but it’s not nice to see how much work was put in fixing it, writing scripts and documentation, all without getting paid for it, and then people claim we didn’t do anything to fix it. But that is, I guess, the result if you do things open source it seems
The fact that the backup app is often not up to date and incompatible with the latest version of Nextcloud (this happened several times) does not help this case.
Well, there’s a warning when you upgrade about what apps are compatible, and you can enable them regardless of a compatibility warning as they usually work. Beyond delaying releases indefinitely or somehow forcing all app authors to spend time to update their apps, I don’t know how we can fix that. Only apps we have customers for we can maintain for free. Anything else - when not shipped as part of our core Nextcloud zip file - has exactly as much guarantees as you are paying for. We want to do better, but how? Suggestions are welcome, we are trying to improve our communication about this.
I agree that the landscape is limited. I myself have been a huge fan and promoter of Nextcloud, sadly it never has became what I thought it would be and I have lost my faith. I see the organisation building on all sorts of funky features and new apps but there is no coherent support of the current app base while almost all of them lack critical improvements.
Sorry to hear that. I’m not sure why you lost your faith. I mean, you point to frustrated users, but we have about 300-400K servers online, with in some cases millions of users on them - I think it is absolutely inevitable that there are lots of complaints. Especially as the critical feature for one is a funky, useless feature for another. And just like a bug that affects 0.1% of iPhone 14 Pro users will have more Reddit posts than one that impacts the same percentage of users of a Nokia model.
I won’t claim Nextcloud has no bugs, but we fix them as fast as we can, and generally in order of how many users are impacted (as far as we can determine that). Our engineers spend the vast majority of their time on finding and fixing bugs and doing support and improving/refactoring old code than marketing feature development. But yes, there will always be bugs as we have to keep up with demands of users and customers (like accessibility or encryption protocols), the market (basic features in collaboration platforms) and technology (new PHP versions, Vue etc).
Claims like “there is no coherent support of the current app base” are just so incredibly off-base that I don’t even know what to say - our biggest engineering team works on files and they are continuously improving performance, stability, refactoring code (like porting the Files app to Vue), supporting new PHP versions and so on. But I guess nobody notices it when stuff just works, and only when something goes wrong do you get attention.
Look, we’re doing this open source, on-prem and self-funded. So it’s a ton harder to pay your engineers then if you follow the standard IT model where you get venture capital to build up a proprietary SAAS company which you can then sell and make your investors rich. What that means in the long term - that’s something I leave to all of you to decide.
With regards to the warning, I’ll keep an eye on development, as many of you do I’m sure. E2EE will certainly work reliably in several large customer setups with the benefit of our support and fortune 500 companies are surprisingly unwilling to risk data loss, but I know the multitude of use cases home and SMB users have takes longer to stabilise. So perhaps mid 2023 we can have a conversation again about how likely it is a normal private user can run a Nextcloud E2EE setup without risk.
I agree with you that in the case of Nextcloud e2ee does not add much when the server is not trusted, because it can be manipulated. There is potential for solutions here by adding a chain of trust, but indeed open source clients are also a good solution.
The urgency of moving to 128 may not be so high now, but if one would collect this now for decryption later on this would be problematic depending on how long you want to keep it secret. I know that some governments would not accept this as a solution for this reason.
I disagree with the ‘ton’ of work in fixing that issue on stability. The solution offered is a very poor solution that doesn’t work well. As those clients were not updated (as I also wrote there) the issue would just come back every time in shared folders. The correct solution here would be to auto patch it or suggest it through the sync clients. The script did not solve the issue and caused a lot of headache.
Lately with the upgrade to Nextcloud 25 I had many local sync databases of clients getting corrupted. Only solution were was to pruge those manually and restart the syncing. This could have easily be an automatic, or remote based feature.
Also the statement about the warning is incorrect. I have automatic updates and this completely ignores those. Now with Nextcloud 25 one of your own apps “Impersonation” was disabled on update. It’s not just third party apps. I do not understand how you can release new versions without having tested it with your own apps. That would be okay for beta software, not for something running on production. Also if your test landscape would be well build this all could be automated with unit tests. I am not sure how you can say there is support when these things happen.
I think many more users are frustrated with Nextclouds way of operation. I have had quite a few clients who I helped with payed for Nextcloud setups, 50ish % of them have now moved back to Microsoft. Not because they want to, but because Nextcloud is slow and too buggy. I cannot disagree with this.
I am worried about your statement: “surprisingly unwilling to risk data loss”. If an organization has propper key management and Nextcloud would have support for this, no data loss should have to occur. This is a choice not a risk.
Personally I think that Nextcloud will completely be removed from recommendations once others come with more stable solutions. I foresee that others will agree with me to raise the bar of requirements. I honestly would love to see it being different and Nextcloud catching up with the issues. I believe nobody has hard feelings against the project and we all love the goals and mindset of the company. I however take issue with the management of problems and how things are going development wise. I am sure that the community is always open to review the software again, and I can ensure that many including myself still use Nextcloud and strongly follow the developments.
I forgot to add, that I am a bit frustrated with the argument of Nextcloud that often comes up with addressing issues. When users complain about the stability and performance often their set up and hardware is blamed, even when this is a supported set up. I always believed this argument, but I myself got account on the by Nextcloud hosted solution as well and I cannot say the performance is any better, just as well as the vague errors it outputs.
