nextcloud
[Bug] Nextcloud Encryption breaks with OpenSSL 3.x due to legacy RC4 usage
https://github.com/nextcloud/server/blob/6fa62e9266d4dc57c34d30392bc066b6e1a9eb2d/apps/encryption/lib/Crypto/Crypt.php#L689
Completely breaks the encryption on any system with the default openssl 3.0 config (legacy ciphers are now disabled).
Error example if this inevitably starts happening for fedora 36 et. al
OCA\Encryption\Exceptions\MultiKeyDecryptException: multikeydecrypt with share key failed:error:0308010C:digital envelope routines::unsupported
Workaround (from within the distribution openssl.conf)
# Configure as (add or uncomment as needed)
[provider_sect]
default = default_sect
legacy = legacy_sect
[default_sect]
activate = 1
[legacy_sect]
activate = 1
I ran into this after upgrading to Ubuntu 22.04 LTS with Nextcloud 24rc1. Is there a plan to migrate to a nonlegacy cipher for server-side encryption?
Same Issue here. Users are not able to download their data and get a general server error when trying to download files via webbrowser. Thanks to @MartB I was able to get access to the files again. Log contains the following statements:
-
OCA\Encryption\Exceptions\MultiKeyDecryptException: multikeydecrypt with share key failed:error:0480006C:PEM routines::no start line -
OCA\Encryption\Exceptions\MultiKeyDecryptException: multikeydecrypt with share key failed:error:0308010C:digital envelope routines::unsupported -
Sabre\DAV\Exception\ServiceUnavailable: Encryption not ready: multikeydecrypt with share key failed:error:0308010C:digital envelope routines::unsupported
Hello, i upgraded my personal Nextcloud from Ubuntu 21.10 to 22.04 yesterday, and was unable to access my files after the Upgrade.
I can confirm that the changes to the openssl.cnf as suggested by @MartB got everything working again, so thank you for that.
Will this affect every Nextcloud-User with enabled encryption, or just those who have enabled 'encryption.legacy_format_support' => true, ?
Thank you for your work, have a nice day, Michael
Same problem here, after upgrading Ubuntu from 20.04 to 22.04.
My openssl.cnf file has not the legacy lines mentioned above. So I've tried to comment just the remaining lines but no luck for me.
There is something else I can do? Thanks!
EDIT: my log points to a different line where code breaks (I'm running the latest 24.0.1 Nextcloud version): https://github.com/nextcloud/server/blob/b7bce42078369fc48df8234fb8e2f110f7b6484d/apps/encryption/lib/KeyManager.php#L479
Solved: actually my problem was really that I need to ADD the legacy lines and activate them (no comment)!
@lum4chi Just follow the code for a bit you will eventually end up at the RC4 line i quoted. I added it this way, so the Nextcloud devs know the direct cause.
They indeed need to be added without the ##, as outlined in the comment from the developers "Uncomment the sections that start with ## below to enable the legacy provider. [...]"
[provider_sect]
default = default_sect
legacy = legacy_sect
[default_sect]
activate = 1
[legacy_sect]
activate = 1
@brotkastn I never had legacy_format_support enabled. This breaking change affects every installation. The cipher needs to be changed in order to get rid of the legacy workaround in openssl.
Hi.
@MartB the openssl.cnf that must be modified is that one present in /etc/ssl folder?
Because I have tried to modify this file but encrypted files still not could be decrypted.
Thank you
@antoniotvr a safe bet is to refer to your specific distribution manual.
If you do have php-cli support it is possible to use php --info | grep "Openssl"
If this does not work for whatever reason and your php is using the same openssl as your system, running openssl version -a | grep OPENSSLDIR should yield a path for you.
For Fedora 36 it is OPENSSLDIR: "/etc/pki/tls" and the config resides there.
@MartB thank you. I am on Ubuntu 22.04 at the moment.
The OPENSSLDIR is /usr/lib/ssl and the openssl.cnf is a symbolic link to that one contained in /etc/ssl folder.
/usr/lib/ssl# ls -l total 4 lrwxrwxrwx 1 root root 14 Mar 16 09:35 certs -> /etc/ssl/certs drwxr-xr-x 2 root root 4096 Jun 6 12:42 misc lrwxrwxrwx 1 root root 20 May 5 10:04 openssl.cnf -> /etc/ssl/openssl.cnf lrwxrwxrwx 1 root root 16 Mar 16 09:35 private -> /etc/ssl/private
I don't know why I have activated legacy_sect as you have indicated but still not works.
Thank you
Wouldn't it be better for NextCloud to upgrade to a current secure encryption rather than requiring that we enable one that is basically as good as plaintext?
Wouldn't it be better for NextCloud to upgrade to a current secure encryption rather than requiring that we enable one that is basically as good as plaintext?
Exactly and that's the reason I labeled the above as a workaround only. The core devs need to figure out an RC4->X key-migration solution sooner or later.
RC4 was acceptable in the past, but security and packaging issues like this one, make it impossible to justify continued usage.
Isn't this the PR that will fix this? https://github.com/nextcloud/server/pull/25551
A possibility could be to wrap openssl_seal() and openssl_open so that an alternative RC4 implementation could be used in the short term. I implemented something like that for openssl_open() for my Nextcloud Server-Side Encryption rescue tool. The solution looks like this:
// define as a constant to speed up decryptions
define("REPLACE_RC4_ALGO", checkReplaceRC4Algo());
function checkReplaceRC4Algo() {
// with OpenSSL v3 we assume that we have to replace the RC4 algo
$result = (OPENSSL_VERSION_NUMBER >= 0x30000000);
if ($result) {
// maybe someone has re-enabled the legacy support in OpenSSL v3
$result = (false === openssl_encrypt("test", "rc4", "test", OPENSSL_RAW_DATA, null, $tag, null, 0));
}
return $result;
}
// hands-down implementation of RC4
function rc4($data, $secret) {
$result = false;
// initialize $state
$state = [];
for ($i = 0x00; $i <= 0xFF; $i++) {
$state[$i] = $i;
}
// mix $secret into $state
$indexA = 0x00;
$indexB = 0x00;
for ($i = 0x00; $i <= 0xFF; $i++) {
$indexB = ($indexB + ord($secret[$indexA]) + $state[$i]) % 0x100;
$tmp = $state[$i];
$state[$i] = $state[$indexB];
$state[$indexB] = $tmp;
$indexA = ($indexA + 0x01) % strlen($secret);
}
// decrypt $data with $state
$indexA = 0x00;
$indexB = 0x00;
$result = "";
for ($i = 0x00; $i < strlen($data); $i++) {
$indexA = ($indexA + 0x01) % 0x100;
$indexB = ($state[$indexA] + $indexB) % 0x100;
$tmp = $state[$indexA];
$state[$indexA] = $state[$indexB];
$state[$indexB] = $tmp;
$result .= chr(ord($data[$i]) ^ $state[($state[$indexA] + $state[$indexB]) % 0x100]);
}
return $result;
}
function wrapped_openssl_open($data, &$output, $encrypted_key, $private_key, $cipher_algo, $iv = null) {
$result = false;
if ((0 === strcasecmp($cipher_algo, "rc4")) && REPLACE_RC4_ALGO) {
if (openssl_private_decrypt($encrypted_key, $intermediate, $private_key, OPENSSL_PKCS1_PADDING)) {
$output = rc4($data, $intermediate);
$result = (false !== $output);
}
} else {
$result = openssl_open($data, $output, $encrypted_key, $private_key, $cipher_algo, $iv);
}
return $result;
}
The workaround works great. It has some issues in the webpage, but at least I could save my data. For ubuntu server users, the file is in /usr/lib/ssl/openssl.cnf Change it as advised by MartB and you will get access again. For the noobs like me -> the ending cnf is correct, I thought they meant that was a typo.
Please post in this thread in case they fixed the status quo. Won't update or touch it while it ain't totally broken. Thanks to everyone. Edit: Sorry for the misspell in the data path.
The workaround works great. It has some issues in the webpage, but at least I could save my data. For ubuntu server users, the file is in /usr/lib/sslopenssl.cnf Change it as advised by MartB and you will get access again. For the noobs like me -> the ending cnf is correct, I thought they meant that was a typo.
On the two Ubuntu 22.04 servers I've looked at the file is /usr/lib/ssl/openssl.cnf
I experienced this as well tonight after an upgrade to 22.04 and can confirm the mentioned fix works. Hopefully developers can do something about it.
Since OpenSSL 3.x will soon be the preferred SSL Library in most Distributions this issue should be fixed in the near future I think!
Would be great to hear some comment from a Dev on that Topic!
Problem still exists in Nextcloud 25.0.0 RC3 and RC4 requiring the overrides from @MartB
Note: On Debian / Ubuntu based systems, the changes / additions need to be added to /etc/ssl/openssl.cnf
Workaround (from within the distribution openssl.conf)
# Configure as (add or uncomment as needed) [provider_sect] default = default_sect legacy = legacy_sect [default_sect] activate = 1 [legacy_sect] activate = 1
This is not helpful in fixing or diagnosing the problem. After I changed it according to these posts it is working, but as a beginner I do not remember and have not backed up the original openssl.cnf file. The reason for trying that is to test if the issue persists now and in the future. Is there a way to find the default configuration for these settings? My best guess would be:
[provider_sect]
default = default_sect
#legacy = legacy_sect commented out
[default_sect]
activate = 1
#[legacy_sect]
#activate = 0
I am dependent on the service I am hosting and have broken my MariaDB to an unfixable degree once, so I had to reformat everything. However I would like to get rid of the current legacy limitations in the web view. I do not understand how this issue is not grabbing more attention. Is this limited to the specific os version or an ARM issue? (Running on a raspberry pi 4.) Thanks to the community for being so helpful and easy to follow fixes.
@Noob3103 I can confirm you this is not an ARM specific issue, running on x86_64 (on a server) I've encountered the same issue. As long as your OpenSSL version is updated to a certain version, the RC4 is deprecated and breaks the server side encryption on the webview.
Yep 2.x and later this is the case.
---------------------------------------_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Thu, 27 Oct 2022, Samy Lahfa wrote:
Date: Thu, 27 Oct 2022 20:15:15 -0700 From: Samy Lahfa @.> Reply-To: nextcloud/server @.> To: nextcloud/server @.> Cc: Robert Dinse @.>, Comment @.***> Subject: Re: [nextcloud/server] [Bug] Nextcloud Encryption breaks with OpenSSL 3.x due to legacy RC4 usage (Issue #32003)
@Noob3103 I can confirm you this is not an ARM specific issue, running on x86_64 (on a server) I've encountered the same issue. As long as your OpenSSL version is updated to a certain version, the RC4 is deprecated and breaks the server side encryption on the webview.
-- Reply to this email directly or view it on GitHub: https://github.com/nextcloud/server/issues/32003#issuecomment-1294395087 You are receiving this because you commented.
Message ID: @.***>
If this is not ARM related, I am confused as to how this issue isn't affecting the businesses hosting it. Running it with outdated software and operating system shouldn't be acceptable for them, or do they have the same or better fixes? Not sure what features are lost with the legacy mode, but I have noticed some restrictions and errors.
As at least one of those businesses, it has. I've changed my openssl
configuration to enable RC4 for nextcloud, though I'd much rather see nextcloud adopt a currently secure protocol.
---------------------------------------_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Thu, 27 Oct 2022, Noob3103 wrote:
Date: Thu, 27 Oct 2022 22:28:41 -0700 From: Noob3103 @.> Reply-To: nextcloud/server @.> To: nextcloud/server @.> Cc: Robert Dinse @.>, Comment @.***> Subject: Re: [nextcloud/server] [Bug] Nextcloud Encryption breaks with OpenSSL 3.x due to legacy RC4 usage (Issue #32003)
If this is not ARM related, I am confused as to how this issue isn't affecting the businesses hosting it. Running it with outdated software and operating system shouldn't be acceptable for them, or do they have the same or better fixes? Not sure what features are lost with the legacy mode, but I have noticed some restrictions and errors.
-- Reply to this email directly or view it on GitHub: https://github.com/nextcloud/server/issues/32003#issuecomment-1294476736 You are receiving this because you commented.
Message ID: @.***>
@Noob3103 Is there a way to find the default configuration for these settings? yes you can check: https://github.com/openssl/openssl/blob/master/apps/openssl.cnf#L56-L72
Also for people who are trying out the workaround on php8.1-fpm, you may need to restart it via the following command to reload the OpenSSL config.
sudo /etc/init.d/php8.1-fpm restart
A possibility could be to wrap
openssl_seal()andopenssl_openso that an alternative RC4 implementation could be used in the short term. I implemented something like that foropenssl_open()for my Nextcloud Server-Side Encryption rescue tool. [...]
I thought it might be interesting for the participants of this issue to know that I developed a fix for it in https://github.com/nextcloud/server/pull/35916.
Is there a way to apply the workaround to Docker? I can't find the specified directories anywhere.
Is there a way to apply the workaround to Docker? I can't find the specified directories anywhere.
that would be very helpful!
Should be fixed by https://github.com/nextcloud/server/pull/36173 (NC26) Feedback welcome.