opensslfreeradiusradiustls1.3

How to force TLS 1.3 in FreeRADIUS?


I'm trying to experiment some with TLS 1.3.

I have a CA setup, server & client certs generated & distributed, and I can connect successfully using these certs with openssl s_server & s_client:

TLS 1.2:

...
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: FFE0AFA10151E6E6F836F84E35D3D84F61F1811DD29B3E5F72F322A5E2529600
    Session-ID-ctx: 
...
    Start Time: 1669758448
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---

TLS 1.3:

---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: F23B37793041E458A77B180FED47B43DF02378C4A25F505A6C4942C5A195EF4E
    Session-ID-ctx: 
...
    Start Time: 1669758331
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---

Okay cool, so OpenSSL works, on to RADIUS/EAP-TLS.

These are the same certs I'm using for the RADIUS server, and for EAP-TLS authentication. In the eap.conf file, I have:

...
        tls_min_version = "1.2"
        tls_max_version = "1.2"
...

and everything works fine. If I set max_version only to 1.3, it still succeeds, but when I set both min & max version to 1.3, the handshake fails and the client is rejected. I looked at the debug messages and noticed something specifically in this excerpt:

(1) Found Auth-Type = eap
(1) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
(1)   authenticate {
(1) eap: Expiring EAP session with state 0x1d55cef11de3c377
(1) eap: Finished EAP session with state 0x1d55cef11de3c377
(1) eap: Previous EAP request found for state 0x1d55cef11de3c377, released from the list
(1) eap: Peer sent packet with method EAP TLS (13)
(1) eap: Calling submodule eap_tls to process data
(1) eap_tls: (TLS) EAP Got final fragment (184 bytes)
(1) eap_tls: WARNING: (TLS) EAP Total received record fragments (184 bytes), does not equal expected expected data length (0 bytes)
(1) eap_tls: (TLS) EAP Done initial handshake
(1) eap_tls: (TLS) Handshake state - before SSL initialization
(1) eap_tls: (TLS) Handshake state - Server before SSL initialization
(1) eap_tls: (TLS) Handshake state - Server before SSL initialization
(1) eap_tls: (TLS) recv TLS 1.3 Handshake, ClientHello
(1) eap_tls: (TLS) send TLS 1.2 Alert, fatal protocol_version
(1) eap_tls: ERROR: (TLS) Alert write:fatal:protocol version
(1) eap_tls: ERROR: (TLS) Server : Error in error
(1) eap_tls: ERROR: (TLS) Failed reading from OpenSSL: error:0A000102:SSL routines::unsupported protocol
(1) eap_tls: ERROR: (TLS) System call (I/O) error (-1)
(1) eap_tls: ERROR: (TLS) EAP Receive handshake failed during operation
(1) eap_tls: ERROR: [eaptls process] = fail
(1) eap: ERROR: Failed continuing EAP TLS (13) session.  EAP sub-module failed
(1) eap: Sending EAP Failure (code 4) ID 182 length 4
(1) eap: Failed in EAP select
(1)     [eap] = invalid
(1)   } # authenticate = invalid
(1) Failed to authenticate the user
(1) Using Post-Auth-Type Reject

Specifically from these 2 lines:

(1) eap_tls: (TLS) recv TLS 1.3 Handshake, ClientHello
(1) eap_tls: (TLS) send TLS 1.2 Alert, fatal protocol_version

It seems the client is sending a TLS 1.3 handshake in the Client Hello, but the server is falling back to TLS 1.2 and failing.

What am I missing to force TLS 1.3 from the server side? I was under the impresson that just setting the tls_min_version and tls_max_version in the eap.conf file was sufficient to change the version of TLS used server-side.

The freeradius docs give very limited info on EAP-TLS 1.3, and are not so clear about anything other than the fact that it will probably not work. Even if it doesn't end up working though, I'm interested to see what happens, but am having some trouble with this part.


Solution

  • Eventually figured this out.

    Despite these debug output & error messages heavily suggesting otherwise, as the FreeRADIUS guys have been indicating for some time now - this is a client-side issue.