Radsec Regression Alpine 3.14
Emile Swarts
emile.swarts123 at gmail.com
Tue Sep 14 18:03:51 CEST 2021
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 at deployingradius.com>
wrote:
> 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.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
More information about the Freeradius-Users
mailing list