Desktop: Subfolder of E2E encrypted folder does not get encrypted

[ntimo]

Expected behaviour

Creating a subfolder of e E2E encrypted folder should also encrypt the contents of this subfolder.

Actual behaviour

The content of the subfolder is not E2E encrypted

Steps to reproduce

1. Create a subfolder in a E2E encrypted folder
2. place file in this folder
3. take a look at the data directory on the server file / filename is not encrypted
4. take a look at the iOS app the subfolder is not marked as encrypted

Client configuration

Client version: 2.5.0 rc2

Operating system: macOS Mojave 10.14.1 (18B75)

OS language: German

Installation path of client: /Applications/Nextcloud.app

Filezilla on server:

iOS app, missing E2E lock:

[ntimo]

Kind of but the decryption works, its only the encryption of new subfolders that does not work.

[e-alfred]

This issue is a dealbreaker for E2EE in Nextcloud. I just created a subfolder and it got uploaded completely unencrypted without even giving any notification whatsoever. On the server the folder is not accessible, only by checking on the CLI I saw that everything is stored unencrypted on the server. This is highly worrisome because people depending on E2EE get a completely false sense of security without even realizing that they got compromised 100%.

[rugk]

(Posted in wrong issue)

[rugk]

BTW this misses the "e2e crypto" label.

[SonRiab]

Personally I think this is a duplicate. Have you tried adding a subfolder to the encrypted one using the iOS app and checked if the content is decrypted by the desktop client @ntimo?

[ntimo]

@SonRiab Hello,
Yes I have checked that. When I create a new subfolder using the iOS App it is E2E encrpyted, and the content of this folder is also decrypted by the macOS client correctly.

[augustseptember]

On the Android app i did the following:

• create folder "secret"
• "set encryption" on folder "secret"
• create a subfolder in it: /secret/subfolder
• enter subfolder and uploaded a file named _version1.test.zip_ into it --> everything seems to get encrypted

On Ubuntu with Desktop-Client 2.5:

• Client syncs folders and file
• the uploaded file doesn't get decryted. The filename is now 4f62cb7d22a34710a6d71cf... and the content is not readable

PS: I see now, that it's already described in https://github.com/nextcloud/desktop/issues/774

[SonRiab]

@augustseptember That's why this issue is still open. Doing this using the iOS app seems to work. I will try to reproduce this.

[shwebstart]

Same issue with Version 2.5.0v2.5.0 (build 20181112).
Windows 10 - 1803 Build 17134.407
Nextcloud 14.04 server installation

[ntimo]

Has this been fixed in 2.5.1?

[mossy-nw]

no, the behavior persists on Fedora 29 AppImage Version 2.5.1final (build 20181204).

[ntimo]

@mossy-nw Oh nice... lets hope its getting fixed very soon. Since this is a true deal breaking security issue.

[mossy-nw]

@ntimo Honestly any (in)security feature should be disabled, and only made available once functional and at least minimally tested. A false sense of security can be dangerous, and as @e-alfred points out, most users will be totally in the dark--what ordinary user would be checking the encryption with an e2ee-disabled nextcloud client?

The willingness to enable e2ee (with a known critical security issue) in a production release severely undermines my trust in the nextcloud team to do end to end encryption safely. I was eagerly anticipating nextcloud e2ee and have wanted to support and recommend this platform (despite commercial e2ee alternatives) but I feel no choice but to direct security-conscious people elsewhere -- closed/costly but polished: tresorit, spideroak; open source but less polished: cryptpad, cryptomator, kbfs using keybase.io.

[tcanabrava]

It would be helpfull to have people trying to fix the issue instead of
bashing it.
I'm the original developer of such feature but my time for opensource is
severely limited, I'll add support for more folders when I can.
Opensource also means that users should care about the software providing
patches and fixing issues, and not just waiting for the company to fix
everything.

On Mon, Dec 10, 2018 at 2:32 AM m0ss [e-mail] wrote:

@ntimo https://github.com/ntimo Honestly any (in)security feature
should be disabled, and only made available once functional at at least
minimally tested. A false sense of security can be dangerous, and as
@e-alfred https://github.com/e-alfred points out, most users will be
totally in the dark--what ordinary user would be checking the encryption
with an e2ee-disabled nextcloud client?

The willingness to enable e2ee (with a known critical security issue) in a
production release severely undermines my trust in the nextcloud team to do
end to end encryption safely. I was eagerly anticipating nextcloud e2ee and
have wanted to support and recommend this platform (despite commercial e2ee
alternatives) but I feel no choice but to direct security-conscious people
elsewhere -- closed/costly but polished: tresorit, spideroak; open source
but less polished: cryptpad, cryptomator, kbfs using keybase.io.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nextcloud/desktop/issues/816#issuecomment-445615026,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD1zUJPA_pCnYCNa0YDYeeEGXD1HOCJ1ks5u3bmXgaJpZM4Yab7U
.

[augustseptember]

@tcanabrava First of all: thank you for this great feature and for your time you spent for this. I am really happy that there are people like you, that have the skills and the time for programming some crypto stuff. And of course I would like to help, but I have no idea about coding. So my only help can be testing and reporting bugs.
I hope you don't read the critic as personal offense, but I do understand @mossy-nw in his points. Simply because of the obviously too early release of a security relevant feature. It should have been waited until the feature is safe to use it. But the "bashing" should be adressed to the release management and not the coders who do such good work.

[tcanabrava]

I'll try to get some time this weekend to see what I can do about that part
of the project.

On Mon, Dec 10, 2018 at 1:47 PM augustseptember [e-mail]
wrote:

@tcanabrava https://github.com/tcanabrava First of all: thank you for
this great feature and for your time you spent for this. I am really happy
that there are people like you, that have the skills and the time for
programming some crypto stuff. And of course I would like to help, but I
have no idea about coding. So my only help can be testing and reporting
bugs.
I hope you don't read the critic as personal offense, but I do understand
@mossy-nw https://github.com/mossy-nw in his points. Simply because of
the obviously too early release of a security relevant feature. It should
have been waited until the feature is safe to use it. But the "bashing"
should be adressed to the release management and not the coders who do such
good work.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nextcloud/desktop/issues/816#issuecomment-445803378,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD1zUK4muW2MBwq5mnETH8o7twRwrjsHks5u3lfBgaJpZM4Yab7U
.

[mossy-nw]

@tcanabrava - my criticism was not directed at you personally as the original developer of the feature, but rather at the decisionmaking process that allowed an unfinished security feature to be enabled in a production release. If my comments seem harsh, still I stand by them -- people looking for end to end encryption are probably doing so for good reason, and should not have the opportunity to be confused by a not-quite-ready feature. Would it be better to open a bug report specifically directed at this?

And please, my intention was not to bash your project or disrespect the (volunteer?) effort you put into this, but please don't demand that any user that contributes to an open source project by reporting bugs also must have the coding skills to fix them, this would narrow the community of contributors far too much.

[tcanabrava]

On Tue, Dec 11, 2018 at 1:01 PM m0ss [e-mail] wrote:

@tcanabrava https://github.com/tcanabrava - my criticism was not
directed at you personally as the original developer of the feature, but
rather at the decisionmaking process that allowed an unfinished security
feature to be enabled in a production release. If my comments seem harsh,
still I stand by them -- people looking for end to end encryption are
probably doing so for good reason, and should not have the opportunity to
be confused by a not-quite-ready feature. Would it be better to open a bug
report specifically directed at this?

And please, my intention was not to bash your project or disrespect the
(volunteer?) effort you put into this, but please don't demand that any
user that contributes to an open source project by reporting bugs also must
have the coding skills to fix them, this would narrow the community of
contributors far too much.

I agree with you.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nextcloud/desktop/issues/816#issuecomment-446178259,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD1zUHBVFkENxYAY21WwwW8AHFG6If9kks5u356CgaJpZM4Yab7U
.

[mossy-nw]

thanks, @tcanabrava -- would you be able to please recommend the best way to approach the people who make decisions about releases & features?

[e-alfred]

@ntimo I am sorry to say, but I think you underestimate the seriousness of the situation. It is not because of you (E2EE a great feature), but it is officially announced as "stable" by somebody who manages releases at Nextcloud. Think about all the users who rely on this feature (for example journalists or people who handle sensitive data) but do not know about the implications of thinking everything works well while all their data in subfolders gets uploaded unencrypted. But because they cannot open the E2EE encrypted folder on the web interface to see the encrypted files, they get compromised 100% while not even knowing it except for all the bad actors (malicious admin, attacker who compromised the server) who can access all the subfolders and their contents.

As an intermediate step it would be at least necessary to prevent the upload of subfolders inside encrypted folders by simply giving the user a notification that subfolders inside encrypted folders are not supported in the client notification window.

[jamiljonna]

So has there been any movement on this? Virtually all of our files are in subfolders so, effectively, E2E isn't working at all. Yet this issue remains 5 months later.

[hubermic]

This is the reason why I lost confidence in Nextcloud. E2E is promoted as the "ultimate protection feature" (https://nextcloud.com/endtoend) and I as well as some of my customers to which I recommended the use of Nextcloud trusted in this feature for quite a while until I saw that it does not work at all by auditing the file system on several servers. Ok, there is a single sentence on the project page page which indicates, that the feature might not be as reliable as it is promoted ("... still in a testing phase"), but the bottom line is it does not work at all concerning the desktop client ...

It's clear that Nextcloud is an open source project and development is done by the community - but promoting a security-relevant feature like e2e on the one hand and not fixing it for almost half a year on the other hand imho challenges security and trust in Nextcloud in general.

[jospoortvliet]

Unfortunately it is a matter of resources - believe me, we work as hard as we can.

I notice that you seem to be using Nextcloud in your company and offering Nextcloud to your customers without having a subscription with us. May I suggest getting a subscription? You would help finance the quick fixes that you seem to expect and be able to request that we prioritize those fixes. In the end, with our limited resources, we will have to focus on what our customers need most urgently.

[shwebstart]

Then stop promoting this feature until its ready for productive purposes. Users lull into a false sense of security. This was the starting point of hubermics question.

[KopfKrieg]

@shwebstart You're right. E2E encryption was promoted as the feature for Nextcloud 13 (release date was February 2018, over a YEAR ago). And it's still buggy and basically unusable.

[hubermic]

From the user’s point of view it’s not about time - it does not matter when e2e reaches a stable and fully functional level and I didn’t want to complain about that at all.

Communication / Marketing and the current state of implementation however highly differ at the moment which is somehow unlucky. The description of the E2E App clearly says Alpha state, but the feature is promoted as a kind of core feature on the Nextcloud website.

[BloodyIron]

Are we getting development on this?

[ExpandingFoam]

WOW it's a good thing I have nothing better to do on Saturday night than read reddit! Because I have learned by sheer happenstance that my plan to migrate all my personal files to NextCloud and OnlyOffice is a bad one. despite all kinds of information to the contrary from official sources. I was literally planning to start this next week. I have bought service and everything.

Somebody needs to take down that webpage (and whatever others exist) and replace it with something correcting the misinformation, apologizing for the error, and advising users _not_ to rely on this feature, or explaining precisely what it is that _does_ work.

I'm sure the technical issue to _fix_ E2EE is complex otherwise it'd be done already. But all this misleading advertising needs to be taken down about 9 months ago. Holy moly! Is there a FOSS Better Business Bureau? Even as a non programmer I know how to use <!-- --> which is at minimum what's well overdue.

This is totally nuts and you guys have just LOST me due to the willful lying and misrepresentation.

So much for my fantasy of advising all my friends switch from Google Drive to Next Cloud! Resilio it is. :(
Edit: fixing markdown

[rugk]

So much for my fantasy of advising all my friends switch from Google Drive to Next Cloud!

While I agree with much of what you said and can totally understand that you are angry, of course one has to say that a self-hosted Nextcloud or a Nextcloud hosted on a small provider is of course always better than Google Drive from a privacy point of view, even without any e2e encryption (AFAIK Google Drive does not offer that feature/any e2e encryption, anyway). That said, again, I also think this issue here is a pretty big and bad one…

[ExpandingFoam]

Fair point: with Google we _know_ data is being used for purposes other than those intended by the users. It's a pretty a low standard to hold anything to.

The difference between the reality here and the marketing speaks to a total lack of integrity. Since I am not a programmer I must rely heavily on claims made by the developers in the belief that they will act decently and not actively mislead users (the way Google does). There is human error, competing priorities, etc, and then there is deceit.

The webpage linked above was the top hit when I searched for this. It states

The Nextcloud end-to-end encryption feature is designed such that the server never has access to unencrypted files or keys, nor does server-provided code ever handle unencrypted data which could provide avenues for compromise.

Users can activate the Nextcloud end-to-end encryption feature for one or more folders. The content of each of these folders will be fully hidden from the server, including file names and directory structure.

Encryption is used by Nextcloud to protect your data in transit and on external storage – and with End-to-end Encryption even against an untrusted server.

All of which, if I understand properly, are directly contradicted by the above posts.

This makes me think, "What else is Next Cloud hoping no one will notice?"

I'm very disappointed because I really, really wanted this to work. And now I have no idea what would have to happen to make me have trust in this

I don't know how this work is structured and I don't know whose responsibility it is to fix it. Maybe there are underlying communication problems, or personnel issues, or a tyrannical manager.. I don't know. But all this stuff needs to be taken down and corrected, even if just to say "please don't rely on this right now, we made a mistake, we're working on it." (Or, if more truthful, "Please don't rely on this right now. We are not able to fix this in the foreseeable future.") I don't think this could be a community problem because it's on nextcloud.com which is presumably not subject to editing by anyone on GitHub.

Anyway I guess I am not contributing much because it's all been said above more succinctly. Sorry for wasting everyone's kilobytes.

[rugk]

"What else is Next Cloud hoping no one will notice?"

Again, I totally understand that question, but AFAIK I can honestly answer, nothing else. And I do say this as a user, I am not affiliated with Nextcloud at all.
That said, as mentioned, this is really a weak point of Nextcloud and it's only honest to point it out. I agree, they probably should not be marketing the feature in such a way. (or e.g. put a big "beta" banner somewhere)

[claell]

@ntimo @SonRiab What is different in this issue than in #774? Also, is that relevant or could those issues be merged by adding more information to #774?

[SonRiab]

Personally I think this could be merged. The only difference is that using the iOS app encrypted files in subfolders seems to be decrypted by desktop clients which is not happening when using the Android app. But honestly both issues are already really old and I don't use and want to use e2e anymore, so I have no clue if this is still a problem or not.

[claell]

Ah ok, thanks for clarifying. I really had a hard time figure out what was the difference between these two issues. Since that is not really a difference in the main issue and rather an addition that it works with the iOS app, I edited your description of #774 now and added that information. Thus I will mark this as a duplicate of #774 and propose to further track everything related there. Feel free to reopen or add a comment if you think this is not correct.

[claell]

Duplicate of #774