Thanks for that. Had a look at the debug logs: ... new connection request on TCP socket Listening on auth from client (188.220.xx.xx, 57095) -> (*, 2083, virtual-server=radsec) Waking up in 0.6 seconds. (0) (TLS) Initiating new session (0) (TLS) Setting verify mode to require certificate from client (0) (TLS) Handshake state - before SSL initialization (0) (TLS) Handshake state - Server before SSL initialization (0) (TLS) Handshake state - Server before SSL initialization (0) (TLS) recv TLS 1.3 Handshake, ClientHello (0) (TLS) Handshake state - Server SSLv3/TLS read client hello (0) (TLS) send TLS 1.2 Handshake, ServerHello (0) (TLS) Handshake state - Server SSLv3/TLS write server hello (0) (TLS) send TLS 1.2 Handshake, Certificate (0) (TLS) Handshake state - Server SSLv3/TLS write certificate (0) (TLS) send TLS 1.2 Handshake, ServerKeyExchange (0) (TLS) Handshake state - Server SSLv3/TLS write key exchange (0) (TLS) send TLS 1.2 Handshake, CertificateRequest (0) (TLS) Handshake state - Server SSLv3/TLS write certificate request (0) (TLS) send TLS 1.2 Handshake, ServerHelloDone (0) (TLS) Handshake state - Server SSLv3/TLS write server done (0) (TLS) Server : Need to read more data: SSLv3/TLS write server done (0) (TLS) In Handshake Phase Waking up in 0.6 seconds. (0) (TLS) Server : Need to read more data: SSLv3/TLS write server done (0) (TLS) In Handshake Phase (0) (TLS) Application data. (0) FAILED in TLS handshake receive Closing TLS socket from client port 57095 Client has closed connection ... shutting down socket auth from client (188.220.xx.xx, 57095) -> (*, 2083, virtual-server=radsec) I can't see any mention of TLS1.0. Only tls_min_version has been set to 1.2 in the TLS config. The cipher_list has also been set to DEFAULT. I've been unable to find much about the default security policies of Openssl / Alpine. Is this something I can update myself, that could potentially solve the problem? Thanks, Emile On Tue, Sep 14, 2021 at 1:42 PM Alan DeKok <aland@deployingradius.com> wrote:
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.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html