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.


  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