On Nov 20, 2020, at 10:33 AM, Jochem Sparla <J.Sparla@iolan.com> wrote:
I have a setup with a Windows 7 and Windows 10 computer authenticating with FreeRADIUS 3.0.20 running on Ubuntu 20.04.
The Windows 7 client fails due to a TLS protocol version error: (2) eap_peap: TLS_accept: before SSL initialization (2) eap_peap: <<< recv TLS 1.3 [length 0062]
Don't use TLS 1.3. There is no standard for it. Windows 7 is sending different TLS negotiation than Windows 10. This means that FreeRADIUS can't send a "please use TLS 1.2" message.
The Windows 10 client, with the same settings on both the client, switch and the same RADIUS server, works fine: (2) eap_peap: TLS_accept: before SSL initialization (2) eap_peap: <<< recv TLS 1.3 [length 0097] (2) eap_peap: TLS_accept: SSLv3/TLS read client hello
That is *requesting* TLS 1.3.
(2) eap_peap: >>> send TLS 1.2 [length 003d] (2) eap_peap: TLS_accept: SSLv3/TLS write server hello
FreeRADIUS says "no, do TLS 1.2" And then it works.
TLS is configured in mods-enabled/eap: tls_max_version = "1.2" tls_min_version = "1.0"
So FreeRADIUS is configured correctly.
I have been breaking my head and searching this for multiple days. The problem does not seem to be in the lack of TLS 1.3 support in FreeRADIUS/OpenSSL1.1.1f, because the Win10 client works fine. It starts by asking for TLS 1.3, but gets set to TLS 1.2 and works.
Yes. So it is *not* doing TLS 1.3. Because the client asks, and FreeRADIUS says "no".
I seems my standard Windows 7 client (fully up to date) sends a bad TLS message, but I have no clue where to look for a solution.
Fix the Windows system so that it doesn't ask for TLS 1.3. Alan DeKok.