New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subfolder of E2E encrypted folder does not get encrypted #816

Open
ntimo opened this Issue Nov 12, 2018 · 21 comments

Comments

9 participants
@ntimo
Copy link

ntimo commented Nov 12, 2018

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:
bildschirmfoto 2018-11-12 um 22 05 57

iOS app, missing E2E lock:
img_3913

@michaelstingl

This comment has been minimized.

Copy link
Contributor

michaelstingl commented Nov 12, 2018

duplicate for #774 ?

@ntimo

This comment has been minimized.

Copy link

ntimo commented Nov 13, 2018

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

@e-alfred

This comment has been minimized.

Copy link

e-alfred commented Nov 15, 2018

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

This comment has been minimized.

Copy link

rugk commented Nov 20, 2018

(Posted in wrong issue)

@rugk

This comment has been minimized.

Copy link

rugk commented Nov 20, 2018

BTW this misses the "e2e crypto" label.

@SonRiab

This comment has been minimized.

Copy link

SonRiab commented Nov 21, 2018

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

This comment has been minimized.

Copy link

ntimo commented Nov 21, 2018

@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

This comment has been minimized.

Copy link

augustseptember commented Nov 22, 2018

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 #774

@SonRiab

This comment has been minimized.

Copy link

SonRiab commented Nov 22, 2018

@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

This comment has been minimized.

Copy link

shwebstart commented Nov 23, 2018

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

@camilasan camilasan added this to To do in Desktop Client 2.5 Series via automation Nov 27, 2018

@ntimo

This comment has been minimized.

Copy link

ntimo commented Dec 6, 2018

Has this been fixed in 2.5.1?

@mossy-nw

This comment has been minimized.

Copy link

mossy-nw commented Dec 8, 2018

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

@ntimo

This comment has been minimized.

Copy link

ntimo commented Dec 8, 2018

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

@mossy-nw

This comment has been minimized.

Copy link

mossy-nw commented Dec 10, 2018

@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

This comment has been minimized.

Copy link
Collaborator

tcanabrava commented Dec 10, 2018

@augustseptember

This comment has been minimized.

Copy link

augustseptember commented Dec 10, 2018

@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

This comment has been minimized.

Copy link
Collaborator

tcanabrava commented Dec 10, 2018

@mossy-nw

This comment has been minimized.

Copy link

mossy-nw commented Dec 11, 2018

@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

This comment has been minimized.

Copy link
Collaborator

tcanabrava commented Dec 11, 2018

@mossy-nw

This comment has been minimized.

Copy link

mossy-nw commented Dec 12, 2018

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

@e-alfred

This comment has been minimized.

Copy link

e-alfred commented Jan 11, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment