freeradius3-common: Shouldn't it be depended on `libopenssl-legacy`?

[galeksandrp]

Maintainer: common packages maintainers and personally @cotequeiroz Environment: arch: aarch64, model: Xiaomi AX3600 global, OpenWrt version: OpenWrt SNAPSHOT (r23422-e0fb38f4ee) Packages: freeradius3-common 3.0.26-1 libopenssl-legacy 3.0.9-2

What happened:

• Well, I happily overlooked moment in February 2023 when openssl was bumped from 1.1.1t to 3.0.8 and destroyed freeradius3.
• So I upgraded my snapshot, and freeradius3 radiusd failed to start, blabbed something TLS: failed loading legacy provider.
• As the error freeradius3 radiusd spits implies, installing libopenssl-legacy fixed it.

So the question is: Shouldn't freeradius3-common be depended on libopenssl-legacy?

P.S.

• Yep, freeradius3 neediness of libopenssl-legacy may heavily depend on how freeradius3 configured (ciphersuites and such)
• but since my freeradius3 configured absoultely standard, I think that for us copypaste /etc/freeradius3 from wiki and don't touch-folks freeradius3-common better be depended on libopenssl-legacy.

[cotequeiroz]

Hi

Here's OpenSSL's description of the legacy provider:

The OpenSSL legacy provider supplies OpenSSL implementations of algorithms that have been deemed legacy. Such algorithms have commonly fallen out of use, have been deemed insecure by the cryptography community, or something similar. We can consider this the retirement home of cryptographic algorithms.

It means those algorithms have been retired, and we shall stop using them, or at least prepare ourselves for life without them. If the default configuration needs something from the legacy provider, we should consider changing the defaults, not cripple the security.

I believe that installing libopenssl-legacy should be treated as an "expert users-only" option, to be used by people who know what they are doing, and not the copypaste folks. We should not make it easy to use a bad configuration.

I'm not familiar with freeradius and its configuration, so I can't attest what parts of the config breaks without legacy cipher suites, but I see MSCHAPv2 docs mentioning DES, RC4 and MD4, all of which have been moved to legacy. DES is not being handled by OpenSSL, apparently.

Grepping through the code I see MD4 being used, but it has an internal implementation that we can use instead of relying on OpenSSL. This should be enough to fix the freeradius3-common dependency.

RC4 is used only in the mschap module, so here's a legit candidate for a legacy dependency. Do you know if mschapv2 can be used without RC4?

[protectivedad]

I have a PR that switches 3.2.x to use the internal MD4 so that it is no longer dependent on OpenSSL legacy the code only mentions using legacy for MD4. I'll be happy to submit it when FreeRADIUS gets bumped. There is some discussion about using the internal MD4/MD5 on the FreeRADIUS github. The only issue is there is a "significant performance penalty" to using the internal routines. This does argue for using the legacy for as long as possible. When I looked the legacy option seems to be needed by the hostapd/wpa/wpad openssl so doesn't it get compiled in anyway?

[predators46]

@galeksandrp

What attributes are needed for freeradius-3.0.26

including configuration file /etc/freeradius3/sites-enabled/default
/etc/freeradius3/sites-enabled/default[1054]: Parse error in condition
/etc/freeradius3/sites-enabled/default[1054]: (EAP-Key-Name && &reply:EAP-Session-Id) {
/etc/freeradius3/sites-enabled/default[1054]:  ^ Expected a module return code
Errors reading or parsing /etc/freeradius3/radiusd.conf