Understanding the current Server-Side Encryption Tools

[Toorero]

Short Summary

I was migrating my Nextcloud instance running on a Raspberry-Pi to a new UGREE NAS where I faced problems with the signing verification of the server-side encryption (because of my own laziness) I had enabled on my server.

This led me into a rabbit hole of further investigating the current tools available for administering server side encryption. I faced many surprises and still don’t understand if all is intended as is. This post is a mix of (potential) bugs I encountered and questions in general on how to employ the available tools of server-side encryption.

Goal

The initial goal was: Fix the failing verification of files that got changed after the last DB backup. After the attempt went now my goal is to simply disable server-side encryption all together.

The reasons are:

• tools seem very fragile and immature, without proper backups I would have lost my data 10x
• not using it for the intended use case (zero trust external storage) in the first place, so normal dm-crypt is superior, more mature and robust I think

Basic Setup

• Nextcloud Server version:
  • 31.0.9
• Operating system and version:
  • Arch Linux
• Web server and version:
  • Apache 2.4.65
• Reverse proxy and version
  • --- (none employed)
• PHP version (e.g, 8.3):
  • php-legacy 8.2.29
• Is this the first time you’ve seen this error? (Yes / No):
  • I guess so, yes?
• When did this problem seem to first start?
  • When I was to lazy to make a fresh mariadb dump but used fresh userdata.
• Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
  • bare metal (basically following Arch Linux Wiki advises)
• Are you using CloudfIare, mod_security, or similar? (Yes / No)
  • No
• Server Side Encryption Setup:
  • all defaults (master key)
  • only for local attached storage

Resolving Initial Goal

I simply tried running encryption:fix-encrypted-version because that was the exact issue I was facing:

• The signature in the DB backup enrolled was outdated to the current file present.
• This caused the signature verification to fail.
• Couldn’t download the current version as stated

But then came the big suprise:

Instead of “Fix[ing] the encrypted version” as stated by the description of the program. This innocent sounding command resets files to the most recent version passing the signature verification, completly discarding all other non-working more recent versions of the file. WHAT?!! How is this expected? This could cause serious data-loss (almost always). There should be a clear warning.

Disabling Server Side Encryption (Second Goal)

After this big surprise, I was not very eager to keep the server side encryption at all and simply wanted to disable server side encryption.

So I simply run occ encryption:decrypt-all as suggested by the official documentation. After I came back the other day, the command completed successfully and my Nextcloud happily running. WRONG

The tool does nothing. All files are still encrypted, but the default encryption module is disabled, so I can’t access any of my encrypted files. At least this time there is no data-loss

---

Then I found the encryption-recovery-tools. So I digged through the README and this command actually works:

sudo env SECRET=“foo” DATADIRECTORY=“/var/lib/nextcloud/data” INSTANCEID=“bar” php-legacy recover.php “/run/media/system/tmp_recovery” "/var/lib/data/user123"

But there are two critical flaws with this method:

1. It “decrypts” every file. If the file is not encrypted, it just copies the plain file over.
2. No in-place method available like I hoped occ encryption:decrypt-all would provide

Questions

1. Is it intended behaviour that occ encryption:decrypt-allliterally nothing? If this is unintended, I will file a bug on GitHub. Otherwise:
   1. Is it simply a cli-hook for other custom encryption modules to provide a user-friendly option to decrypt?
   2. Why does the default module rely on external tools rather than implementing the hook correctly or at least stating that it is unsupported and redirecting you to the external recovery tools?
2. Is there an in-place recovery tool available.

Strong suggestion

I thinkencryption:fix-encrypted-version needs a big disclaimer that it will likely cause data-loss of most-recent versions, and/or a better documentation on what it does exactly. I needed to dig through the PHP code to actually understand what it does.

[Toorero]

Okay, after doing further research, I think I can provide further information and an actual solution to my problem.

Initially I thought occ:decrypt-all it does nothing, but it actually does what I wanted all along but misses a crucial step: It doesn’t update the information in the database. The server still thinks the file is encrypted. You need to manually tell the server to unmark the files…

UPDATE oc_filecache SET encrypted = 0 WHERE encrypted = 1;

Otherwise, you’re going to experience the error I experienced

Error   webdav              Sabre\DAV\Exception: Unable to get header size for <redacted_file_name_that_is_totally_not_secret_and_should_ideally_be_encrypted_too...>, file doesn't start with encryption header at apps/dav/lib/Connector/Sabre/File.php line 600