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

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):

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.