On Sep 14, 2021, at 8:12 AM, Emile Swarts <emile.swarts123@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-avail... 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.