Radsec Regression Alpine 3.14
Alan DeKok
aland at deployingradius.com
Tue Sep 14 14:42:10 CEST 2021
On Sep 14, 2021, at 8:12 AM, Emile Swarts <emile.swarts123 at gmail.com> wrote:
> I recently upgraded Alpine from v3.12 to v3.14.
Upgrades generally change OpenSSL, and/or the default security policies.
> I'm currently looking through all the dependencies that upgraded as part of
> the OS upgrade but it's difficult to pinpoint which one broke Radsec. Noted
> that openssl has stayed on the same version.
Debian also changed their default security policies
> FreeRadius versions went from:
> freeradius-lib-3.0.21-r3
> freeradius-3.0.21-r3
> freeradius-eap-3.0.21-r3
>
> To:
> freeradius-lib-3.0.23-r0
> freeradius-3.0.23-r0
> freeradius-eap-3.0.23-r0
That's good. 3.0.23 has MUCH better debugging messages for TLS.
> The rest of the package upgrades can be found here:
> https://gist.github.com/emileswarts/fd7d46556eacac096d318170aea7a19d
>
> Does anyone have any pointers on how to narrow down this bug?
I'll give it 99% that it's the security policies.
https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-available/eap#L428
Run the server in debug mode, and see which TLS version it's using.
Note that you *can't* set "tls_min_version=1" and have it work. Blame OpenSSL. You *also* have to set the cipher_list.
Why? OpenSSL magic. You can't use TLS 1.0 or 1.1, because they're insecure. If you ask, OpenSSL says "no".
Then you ask "pretty please?", and OpenSSL says "oh, fine then."
It's a little frustrating.
Alan DeKok.
More information about the Freeradius-Users
mailing list