[Bug] Nextcloud Encryption breaks with OpenSSL 3.x due to legacy RC4 usage

[MartB]

ℹ️ Should be fixed by #36173 (NC26)

server/apps/encryption/lib/Crypto/Crypt.php

Line 689 in 6fa62e9

if (openssl_open($encKeyFile, $plainContent, $shareKey, $privateKey, 'RC4')) {

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

[yasij]

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?

[lxk3il]

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

[brotkastn]

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

[MartB]

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

[antoniotvr]

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

[MartB]

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

[antoniotvr]

@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

[4nanook]

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?

[MartB]

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.

[solracsf]

Isn't this the PR that will fix this?
#25551

[yahesh]

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;
	}

[Rosti-dev]

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.

[hughb8on]

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

[pdolinic]

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.

[KaeTuuN]

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!

[d2x]

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

[Rosti-dev]

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.

[AkechiShiro]

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

[gautamkrishnar]

@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

[pablosavigne]

Same issue, same workaround at now!, NC 25.0.2 Ubuntu 22.04

[yahesh]

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. [...]

I thought it might be interesting for the participants of this issue to know that I developed a fix for it in #35916.

[Tokukarin]

I am surprised that this is still not fixed.

[enoch85]

I am surprised that this is still not fixed.

It will be in NC 26.

[cdponcedeleon]

Is there a way to apply the workaround to Docker? I can't find the specified directories anywhere.

[Obi-Wahn]

Is there a way to apply the workaround to Docker? I can't find the specified directories anywhere.

that would be very helpful!

[solracsf]

Should be fixed by #36173 (NC26)
Feedback welcome.

[nichogenius]

For anyone else running PHP via PHP-FPM, you need to restart the PHP-FPM service to reload the openssl config. My changes to my openssl.cnf weren't taking for some reason - took me a while to realize what was going on.
In my case, the command was: sudo systemctl restart php8.1-fpm.service

[NaggingDaivy]

Is there a way to apply the workaround to Docker? I can't find the specified directories anywhere.

that would be very helpful!

That would be very helpful indeed, because there is no workaround for docker image at the time :(

[Nikki1993]

Is there a way to apply the workaround to Docker? I can't find the specified directories anywhere.

that would be very helpful!

That would be very helpful indeed, because there is no workaround for docker image at the time :(

But there is, you can pass whatever to docker image, just have a config locally on your machine that you mount.

I am using Unraid and Nextcloud linuxserver image openssl.cnf is located in /etc/ssl/ inside the container. To override it, I placed my own config under /mnt/cache/appdata/nextcloud/ssl/ and then told docker to mount that directory in the container path /etc/ssl/. Seem to have worked for me, not getting anymore encryption errors.

[MartB]

Just fyi: I am not deploying Nextcloud anymore, so expect no feedback from me.

From looking at the code in #36173, a temporary workaround has been implemented.
Good to know that this very same PR paves the way for the usage of a more secure cipher in the future.

Feel free to close, thanks for contributing everyone!

[EchoDev]

I updated to v26 and reverted the OpenSSL changes in my config.

Nextcloud seems to work fine now with OpenSSL 3.x

[CluelessTechnologist]

I had the issue for a few weeks running linuxserver.io's NextCloud docker image. This morning I got a notification there was a upgrade available (v26). After upgrading the issue has disappeared.
Thanks for fixing the issue!

The con of using docker images are that they are quite static. Since editing the OpenSSL config seemed hard in my case, I just decided to wait for v26 and it paid off! 👍

[solracsf]

Fixed by #36173 (NC v26)