[RADIATOR] UNS: Re: TLS v1.3

Fri Oct 21 21:15:21 UTC 2022

Hi Cassidy,

from my experience you have two options :
* set system SSL library to work only wit TLS v1.3
* set RADIATOR configuration to accept only TLS v1.3 by setting 
TLS_Protocols to TLSv1.3

Also be aware that from many recent reports client which declare that 
work only with TLS v1.3 doesnt do that on correct way or not work at all 
with v1.3.

Regards,
Dubravko Penezic
Srce

On 10/21/22 22:54, Cassidy B. Larson via radiator wrote:
> More specifically, here's the debug output:
> 
> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL Handling EAP type 1 (Identity), 
> code: 2 (Response), identifier: 191, length: 20
> Fri Oct 21 14:52:17 2022: DEBUG: Initialised SSL library: Net::SSLeay 
> 1.92, OpenSSL 1.1.1o-freebsd  3 May 2022
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x9 (9) for Net::SSLeay 
> constant ERROR_WANT_ASYNC
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0xa (10) for Net::SSLeay 
> constant ERROR_WANT_ASYNC_JOB
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0xb (11) for Net::SSLeay 
> constant ERROR_WANT_CLIENT_HELLO_CB
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0xc (12) for Net::SSLeay 
> constant ERROR_WANT_RETRY_VERIFY
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x8 (8) for Net::SSLeay 
> constant SSL2_MT_CLIENT_CERTIFICATE
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x3 (3) for Net::SSLeay 
> constant SSL2_MT_CLIENT_FINISHED
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x2 (2) for Net::SSLeay 
> constant SSL2_MT_CLIENT_MASTER_KEY
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x0 (0) for Net::SSLeay 
> constant SSL2_MT_ERROR
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x6 (6) for Net::SSLeay 
> constant SSL2_MT_REQUEST_CERTIFICATE
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x6 (6) for Net::SSLeay 
> constant SSL2_MT_SERVER_FINISHED
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x4 (4) for Net::SSLeay 
> constant SSL2_MT_SERVER_HELLO
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x5 (5) for Net::SSLeay 
> constant SSL2_MT_SERVER_VERIFY
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x2 (2) for Net::SSLeay 
> constant TLSEXT_ERR_ALERT_FATAL
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x1 (1) for Net::SSLeay 
> constant TLSEXT_ERR_ALERT_WARNING
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x3 (3) for Net::SSLeay 
> constant TLSEXT_ERR_NOACK
> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x0 (0) for Net::SSLeay 
> constant TLSEXT_ERR_OK
> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL setting TLS protocols to: TLSv1.3
> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL setting EAPTLS_Ciphers to: 
> DEFAULT:!EXPORT:!LOW at SECLEVEL=1
> Fri Oct 21 14:52:17 2022: DEBUG: EAP result: 3, EAP-TTLS Challenge
> Fri Oct 21 14:52:17 2022: DEBUG: Radius::AuthGROUP:  result: CHALLENGE, 
> EAP-TTLS Challenge
> Fri Oct 21 14:52:17 2022: DEBUG: AuthBy GROUP result: CHALLENGE, 
> EAP-TTLS Challenge
> Fri Oct 21 14:52:17 2022: DEBUG: Access challenged for <....>: EAP-TTLS 
> Challenge
> 
> 
> Fri Oct 21 14:52:17 2022: DEBUG: Handling with Radius::AuthGROUP:
> Fri Oct 21 14:52:17 2022: DEBUG: Handling with AuthSQL
> Fri Oct 21 14:52:17 2022: DEBUG: Handling with Radius::AuthSQL:
> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL Handling EAP type 21 (TTLS), 
> code: 2 (Response), identifier: 192, length: 196
> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS state: before SSL 
> initialization
> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS state: before SSL 
> initialization
> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS state: before SSL 
> initialization
> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS handshake: 
> Direction IN, Version: TLS 1.3, Record content: (22) Handshake, message 
> type: (1) ClientHello
> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS handshake: 
> Direction OUT, Version: TLS 1.2, Record content: (21) Alert, level: (2) 
> fatal, description: (70) protocol version
> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS state: error
> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS state: error
> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS SSL_accept result: -1, 
> reason/error: 'SSL_ERROR_SSL, state: 'error'
> Fri Oct 21 14:52:17 2022: ERR: AuthSQL EAP-TTLS TLS Handshake error: 
> result: -1, reason/error: 'SSL_ERROR_SSL', state: 'error', 
> error:14209102:SSL 
> routines:tls_early_post_process_client_hello:unsupported protocol
> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP Failure, elapsed time 0.050957
> Fri Oct 21 14:52:17 2022: DEBUG: EAP result: 1, EAP-TTLS TLS Handshake 
> error: unsupported protocol
> Fri Oct 21 14:52:17 2022: DEBUG: Radius::AuthGROUP:  result: REJECT, 
> EAP-TTLS TLS Handshake error: unsupported protocol
> Fri Oct 21 14:52:17 2022: DEBUG: AuthBy GROUP result: REJECT, EAP-TTLS 
> TLS Handshake error: unsupported protocol
> Fri Oct 21 14:52:17 2022: INFO: Access rejected for 888901007406545: 
> EAP-TTLS TLS Handshake error: unsupported protocol
> 
> We're running OpenSSL 1.1.1o and Net:SSLeay 1.92 as detailed above.
> 
> 
> On Fri, Oct 21, 2022 at 1:39 PM Cassidy B. Larson <alandaluz at gmail.com 
> <mailto:alandaluz at gmail.com>> wrote:
> 
>     We're spinning up a new EAP-TTLS source. Installed latest dev of
>     4.26-24. When I force EAP_TLS_Protocols to TLSv1.3 alone, I see the
>     TLSv1.3 handshake request come in, but outbound handshake is
>     TLSv1.2.  Apparently our vendor only allows TLSv1.3 right now.
> 
>     Any ideas how to get outbound handshakes to use TLSv1.3?
> 
>     Fri Oct 21 13:30:12 2022: DEBUG: AuthSQL EAP-TTLS TLS handshake:
>     Direction IN, Version: TLS 1.3, Record content: (22) Handshake,
>     message type: (1) ClientHello Fri Oct 21 13:30:12 2022: DEBUG:
>     AuthSQL EAP-TTLS TLS handshake: Direction OUT, Version: TLS 1.2,
>     Record content: (21) Alert, level: (2) fatal, description: (70)
>     protocol version
> 
> 
>     Thanks!
> 
>     -c
> 
> 
> _______________________________________________
> radiator mailing list
> radiator at lists.open.com.au
> https://lists.open.com.au/mailman/listinfo/radiator