I checked and enabled TLS 1.1 and 1.2 as described. With 1.0 + 1.1 + 1.2 enabled, the problem stays the same. With 1.0 disabled, and 1.1 + 1.2 enabled, the problem changes. I now get a "WARNING: !! EAP session for state 0x*************** did not finish!". I searched: this is usually a certificate or MTU problem. I do not use certificates at the moment. In Windows configuration 'check server certificate' is not checked. I changed the MTU of the client from 1500 to 1250 and 1000, without success. What else can be causing this? Jochem IOLAN B.V. • Mon Plaisir 26 • 4879 AN Etten-Leur • The Netherlands T +31 (0)76 50 26 100 • F +31 (0)76 50 26 199 E iolan@iolan.com • I http://www.iolan.com/ De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents here in and notify the sender immediately by return e-mail. -----Oorspronkelijk bericht----- Van: Freeradius-Users [mailto:freeradius-users-bounces+j.sparla=iolan.com@lists.freeradius.org] Namens L.P.H. van Belle via Freeradius-Users Verzonden: vrijdag 20 november 2020 16:37 Aan: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> CC: L.P.H. van Belle <belle@bazuin.nl> Onderwerp: RE: EAP fails on TLS protocol version with Windows 7, works fine with Windows 10 Google KB3140245 and/or https://manage.accuwebhosting.com/knowledgebase/3008/How-do-I-enable-TLS-1-2... might help you. Greetz, Louis

-----Oorspronkelijk bericht----- Van: Freeradius-Users [mailto:freeradius-users-bounces+belle=bazuin.nl@lists.freerad ius.org] Namens Jochem Sparla Verzonden: vrijdag 20 november 2020 16:33 Aan: freeradius-users@lists.freeradius.org Onderwerp: EAP fails on TLS protocol version with Windows 7, works fine with Windows 10

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] (2) eap_peap: >>> send TLS 1.0 Alert [length 0002], fatal protocol_version (2) eap_peap: ERROR: TLS Alert write:fatal:protocol version tls: TLS_accept: Error in error (2) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol (2) eap_peap: ERROR: System call (I/O) error (-1) (2) eap_peap: ERROR: TLS receive handshake failed during operation (2) eap_peap: ERROR: [eaptls process] = fail (2) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed (2) eap: Sending EAP Failure (code 4) ID 3 length 4 (2) eap: Failed in EAP select (2) [eap] = invalid (2) } # authenticate = invalid (2) Failed to authenticate the user (2) Using Post-Auth-Type Reject

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 (2) eap_peap: >>> send TLS 1.2 [length 003d] (2) eap_peap: TLS_accept: SSLv3/TLS write server hello (2) eap_peap: >>> send TLS 1.2 [length 0308] (2) eap_peap: TLS_accept: SSLv3/TLS write certificate (2) eap_peap: >>> send TLS 1.2 [length 014d] (2) eap_peap: TLS_accept: SSLv3/TLS write key exchange (2) eap_peap: >>> send TLS 1.2 [length 0004] (2) eap_peap: TLS_accept: SSLv3/TLS write server done (2) eap_peap: TLS_accept: Need to read more data: SSLv3/TLS write server done (2) eap_peap: TLS - In Handshake Phase (2) eap_peap: TLS - got 1194 bytes of data (2) eap_peap: [eaptls process] = handled (2) eap: Sending EAP Request (code 1) ID 4 length 1004 (2) eap: EAP session adding &reply:State = 0x30a058ae32a441c4 (2) [eap] = handled (2) } # authenticate = handled (2) Using Post-Auth-Type Challenge

TLS is configured in mods-enabled/eap: tls_max_version = "1.2" tls_min_version = "1.0"

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. 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.

Thanks in advance, Jochem

IOLAN B.V. • Mon Plaisir 26 • 4879 AN Etten-Leur • The Netherlands T +31 (0)76 50 26 100 • F +31 (0)76 50 26 199 E iolan@iolan.com • I http://www.iolan.com/

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents here in and notify the sender immediately by return e-mail.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

...

I checked and enabled TLS 1.1 and 1.2 as described. With 1.0 + 1.1 + 1.2 enabled, the problem stays the same.

Was this on the Windows system?

Yes.

The issue isn't that TLS 1.0, etc. are enabled. The issue is that TLS 1.3 is enabled. You need to turn that off.

That seems odd. As far as I can find, Windows 7 does not support TLS 1.3. Also, I disabled the possibility of TLS 1.3 in the registry, in the same way I enabled TLS 1.1 and TLS 1.2 on the Windows 7 client. When I view the data with Wireshark, it recognizes TLS as version 1.0: Transport Layer Security TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 84 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 80 Version: TLS 1.0 (0x0301) However, FreeRADIUS recognizes it as TLS 1.3, or at least an unsupported protocol version: (2) eap_peap: <<< recv TLS 1.3 [length 0062] (2) eap_peap: >>> send TLS 1.0 Alert [length 0002], fatal protocol_version (2) eap_peap: ERROR: TLS Alert write:fatal:protocol version tls: TLS_accept: Error in error (2) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol With FreeRADIUS 3.0.16 on Ubuntu 18.04, the same Windows client works fine, because the 'unknown protocol version' does not cause a fatal error: (2) eap_peap: <<< recv UNKNOWN TLS VERSION ?0304? [length 0062] (2) eap_peap: TLS_accept: SSLv3/TLS read client hello (2) eap_peap: >>> send TLS 1.0 Handshake [length 003d], ServerHello It still shows TLS version '0304' which indicates TLS 1.3. But FreeRADIUS then proposes TLS 1.0 and that's used. How is it possible that Wireshark shows TLS 1.0, while FreeRADIUS receives TLS 1.3? Jochem IOLAN B.V. • Mon Plaisir 26 • 4879 AN Etten-Leur • The Netherlands T +31 (0)76 50 26 100 • F +31 (0)76 50 26 199 E iolan@iolan.com • I http://www.iolan.com/ De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents here in and notify the sender immediately by return e-mail.

On Nov 24, 2020, at 7:57 AM, Jochem Sparla <J.Sparla@iolan.com> wrote:

After finding this link: https://askubuntu.com/questions/1233186/ubuntu-20-04-how-to-set-lower-ssl-se... I managed to set the SSL security level for OpenSSL 1.1.1f on Ububtu 20.04 to 1, as described in the link.

Now FreeRADIUS 3.0.20 on Ubuntu 20.04 behavior is more like FreeRADIUS 3.0.16 on Ubuntu 18.04: (2) eap_peap: TLS_accept: before SSL initialization (2) eap_peap: <<< recv UNKNOWN TLS VERSION ?0304? [length 0062] (2) eap_peap: TLS_accept: SSLv3/TLS read client hello (2) eap_peap: >>> send TLS 1.0 Handshake [length 003d], ServerHello

It still (thinks it) receives TLS 1.3 from the Windows 7 client, but the 'unknown TLS version' does not cause a fatal error and the process finishes normal.

Are there any (known) issues between FreeRADIUS and/or OpenSSL (or setting parameters between them) on Ubuntu 20.04?

The tls_max_version = "1.2" and tls_min_version = "1.0" in FreeRADIUS eap config are set, but that does not seem to be enough.

I'd blame OpenSSL. :( FreeRADIUS passes that setting to OpenSSL, which may or may not pay attention. Alan DeKok.

On Nov 24, 2020, at 10:10 AM, Jochem Sparla <J.Sparla@iolan.com> wrote:

It's the 'CipherString = DEFAULT@SECLEVEL=1' that makes a difference.

You can do this in FreeRADIUS. See the "eap" module configuration. Set "cipher_list" to that value, and it will work.

The 'MinProtocol = TLSv1.2' can be left out of openssl.cnf, as long as 'tls_min_version' is set in FreeRADIUS eap config.

It now works, with 'eap_peap: <<< recv UNKNOWN TLS VERSION ?0304?' and using 'TLS 1.0' further on according to the debug logging. I'm sure it's not the best or prettiest way, but I do not understand enough of all the techniques and protocols to make it better. Like solving why it still says TLS 1.3 on the first message, and why it doesn't use TLS 1.1/1.2 even though those are enabled in Windows 7, and why the process just stops when forcing TLS 1.1/1.2 by disabling TLS 1.0 in Windows.

Windows is magic. :( Alan DeKok.