-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Figuring out why encryption on S3 object storage as primary storage is not working + trying to fix it #14027
Comments
I managed to find a solution for problem 2:
ensures that always at least one full block of encrypted data is being loaded from the stream source. In combination with the fix I posted above I can successfully store encrypted files on S3 object storage and retrieve them. Tested for files up to 32 MB so far, but I don't think there should be any issues with larger files. This will not allow for decryption of files that have been stored before the fix concerning problem 1 was applied. |
I would love to see a solution here too. Thanks for you effort though @lkreher |
I will have a look at the suggested solution for problem 2. |
Both of my "fixes" are supposed to be workarounds, because the issue is with a 3rdparty library that handles the stream resource. I am however currently using Nextcloud with S3 as primary storage and encryption enabled using the two changes I mentioned above. Concerning problem 1, I don't understand why the IV is originally written as binary data when all the encrypted data is converted to base64 to prevent character encoding issues in the first place. |
I remember to have seen other issues with stream wrappers when we were developing the encryption wrapper in Encryption.php, so problem 2 doesn't really surprise me. Workarounds are fine if possible, but I first should have a look at the code. It's a while ago since I last worked on it. As for problem 1 I have not been involved in developing that part of the code. |
I would just like to chime in and offer to test or help out with any sort of pull requests that relate to this issue. I am not a PHP developer but am willing to get my hands dirty to aid in getting this issue resolved. |
Hi, is anyone working on this? |
Fixed by #15946 Would be nice if some of you with this issue could check with nextcloud 17 if the problem still exist. |
@kesselb I tested nextcloud 17 (new installation) and I can confirm that the problems mentioned in this issue are solved. Once server-side encryption is enabled new files gets correctly encrypted and they can be previewed and downloaded (from the web interface, couldn't test the clients yet). the occ commands encrypt-all and decrypt-all work too, even when called repeatedly, and the files are always accessible. There are a couple of remaining issues tho, and I'm not sure if they're related to the S3 object storage backend or if they're generic encryption issues:
|
I've also tested this setup in nextcloud 17. |
Let us track this in #22077 |
Steps to reproduce
Expected behaviour
Files should be retrieved
Actual behaviour
Nextcloud throws an error and files can't be retrieved
Server configuration
Operating system: Ubuntu 16.04.3 LTS
Web server: nginx
Database: MySQL 5.7
PHP version: 7.2 FPM
Nextcloud version: 15.0.2
Updated from an older Nextcloud/ownCloud or fresh install: fresh install
Where did you install Nextcloud from: Nextcloud web installer
Signing status:
Signing status
List of activated apps:
App list
Nextcloud configuration:
Config report
Are you using external storage, if yes which one: S3 object storage
Are you using encryption: yes
Are you using an external user-backend, if yes which one: no
Client configuration
Browser: Chrome
Operating system: Windows
Logs
Nextcloud log (data/nextcloud.log)
Nextcloud log
Report
This was previously discussed for NC14 in #11826 and others. I've been trying to fix this issue, and noticed multiple problems:
The IV generated to encrypt one block uses
random_bytes(16)
at Crypt.php#634When written to file, read back and evaluated, this block gets interpreted as different character encoding, so 16 characters turn into more or less than 16 bytes.
Changing Crypt.php#634 to
return substr(base64_encode(random_bytes(16)), 0, 16);
makes the IV safe from character encoding issues. This way I can successfully decrypt the first and the last block of each file, which means small files can be retrieved.Blocks don't get read properly. In Encryption.php#473 less than 8192 bytes of data are returned after the first block, even when there are more than 8192 bytes remaining. Retrieving a partial block is guaranteed to result in decryption errors.
I don't have a solution for this problem. The stream resource is being handled by a 3rdparty library which does not behave as expected.
Looking for someone with an idea how to tackle problem 2. I've been stepping through the process with xdebug for a while and can't figure out how to retrieve a full 8192 bytes at once.
The text was updated successfully, but these errors were encountered: