Hi all, I'm trying to do an EAP TLS connection with TLS 1.3 Device is running wpa_supplicant V 2.10 and openssl 1.1.1q. Server is running Freeradius 3.2.1, openssl 1.1.1f on Ubuntu 20.04. I have set min and max tls version to 1.3 in mods-enabled/eap. I'm running into the following error: (9) Received Access-Request Id 249 from 192.168.0.1:35335 to 192.168.0.109:1812 length 336 (9) User-Name = "babycam" (9) NAS-IP-Address = 192.168.0.1 (9) NAS-Identifier = "RalinkAP0" (9) NAS-Port = 0 (9) Called-Station-Id = "AC-84-C6-60-76-8E" (9) Calling-Station-Id = "08-FB-EA-CF-70-C2" (9) Framed-MTU = 1400 (9) NAS-Port-Type = Wireless-802.11 (9) EAP-Message = 0x020200c40d0016030100b9010000b50303470176dc576b264b7154e9bfedb49482d8ec94cb131322a2700ad8115cf99678000038c02cc030009fcca9cca8ccaac02bc02f009ec024c028006bc023c0270067c00ac0140039c009c0130033009d009c003d003c0035002f00ff01000054000b000403000102000a000c000a001d0017001e001900180016000000170000000d0030002e040305030603080708080809080a080b080408050806040105010601030302030301020103020202040205020602 (9) State = 0xa6ed9180a6ef9cf4c53afbdf101f92ad (9) Message-Authenticator = 0x17fafa7bdf53feccf5af9f4e6411bf3d (9) Restoring &session-state (9) &session-state:Framed-MTU = 994 (9) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default (9) authorize { (9) policy filter_username { (9) if (&User-Name) { (9) if (&User-Name) -> TRUE (9) if (&User-Name) { (9) if (&User-Name =~ / /) { (9) if (&User-Name =~ / /) -> FALSE (9) if (&User-Name =~ /@[^@]*@/ ) { (9) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (9) if (&User-Name =~ /\.\./ ) { (9) if (&User-Name =~ /\.\./ ) -> FALSE (9) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (9) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (9) if (&User-Name =~ /\.$/) { (9) if (&User-Name =~ /\.$/) -> FALSE (9) if (&User-Name =~ /@\./) { (9) if (&User-Name =~ /@\./) -> FALSE (9) } # if (&User-Name) = notfound (9) } # policy filter_username = notfound (9) [preprocess] = ok (9) [chap] = noop (9) [mschap] = noop (9) [digest] = noop (9) suffix: Checking for suffix after "@" (9) suffix: No '@' in User-Name = "babycam", looking up realm NULL (9) suffix: No such realm "NULL" (9) [suffix] = noop (9) eap: Peer sent EAP Response (code 2) ID 2 length 196 (9) eap: No EAP Start, assuming it's an on-going EAP conversation (9) [eap] = updated (9) files: users: Matched entry babycam at line 1 (9) [files] = ok (9) [expiration] = noop (9) [logintime] = noop (9) pap: WARNING: Auth-Type already set. Not setting to PAP (9) [pap] = noop (9) } # authorize = updated (9) Found Auth-Type = eap (9) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (9) authenticate { (9) eap: Expiring EAP session with state 0xa6ed9180a6ef9cf4 (9) eap: Finished EAP session with state 0xa6ed9180a6ef9cf4 (9) eap: Previous EAP request found for state 0xa6ed9180a6ef9cf4, released from the list (9) eap: Peer sent packet with method EAP TLS (13) (9) eap: Calling submodule eap_tls to process data (9) eap_tls: (TLS) EAP Got final fragment (190 bytes) (9) eap_tls: WARNING: (TLS) EAP Total received record fragments (190 bytes), does not equal expected expected data length (0 bytes) (9) eap_tls: (TLS) EAP Done initial handshake (9) eap_tls: (TLS) Handshake state - before SSL initialization (9) eap_tls: (TLS) Handshake state - Server before SSL initialization (9) eap_tls: (TLS) Handshake state - Server before SSL initialization (9) eap_tls: (TLS) recv TLS 1.3 Handshake, ClientHello (9) eap_tls: (TLS) send TLS 1.2 Alert, fatal protocol_version (9) eap_tls: ERROR: (TLS) Alert write:fatal:protocol version (9) eap_tls: ERROR: (TLS) Server : Error in error (9) eap_tls: ERROR: (TLS) Failed reading from OpenSSL: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol (9) eap_tls: ERROR: (TLS) System call (I/O) error (-1) (9) eap_tls: ERROR: (TLS) EAP Receive handshake failed during operation (9) eap_tls: ERROR: [eaptls process] = fail (9) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed (9) eap: Sending EAP Failure (code 4) ID 2 length 4 (9) eap: Failed in EAP select (9) [eap] = invalid (9) } # authenticate = invalid (9) Failed to authenticate the user (9) Using Post-Auth-Type Reject (9) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (9) Post-Auth-Type REJECT { (9) attr_filter.access_reject: EXPAND %{User-Name} (9) attr_filter.access_reject: --> babycam (9) attr_filter.access_reject: Matched entry DEFAULT at line 11 (9) [attr_filter.access_reject] = updated (9) [eap] = noop (9) policy remove_reply_message_if_eap { (9) if (&reply:EAP-Message && &reply:Reply-Message) { (9) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (9) else { (9) [noop] = noop (9) } # else = noop (9) } # policy remove_reply_message_if_eap = noop (9) } # Post-Auth-Type REJECT = updated (9) Delaying response for 1.000000 seconds Waking up in 0.3 seconds. Waking up in 0.6 seconds. (9) (9) Discarding duplicate request from client masutest port 35335 - ID: 249 due to delayed response (9) Sending delayed response (9) Sent Access-Reject Id 249 from 192.168.0.109:1812 to 192.168.0.1:35335 length 44 (9) EAP-Message = 0x04020004 (9) Message-Authenticator = 0x00000000000000000000000000000000 Waking up in 3.9 seconds. Please assist me with this. Boby Tharappel
On Dec 14, 2022, at 2:09 AM, Boby Tharappel <bobytharappel.mec@gmail.com> wrote:
I'm trying to do an EAP TLS connection with TLS 1.3 Device is running wpa_supplicant V 2.10 and openssl 1.1.1q.
I'm not sure wpa_supplicant 2.10 supports TLS 1.3
(9) eap_tls: (TLS) send TLS 1.2 Alert, fatal protocol_version
(9) eap_tls: ERROR: (TLS) Alert write:fatal:protocol version
That seems pretty clear. The protocol versions don't match. a) allow TLS 1.2 in FreeRADIUS b) force wpa_supplicant 2.10 to use TLS 1.3 c) upgrade wpa_supplicant to a version (from git) which supports TL 1.3. Pick one. (b) might not work, but (a) or (c) definitely work Alan DeKok.
On Wed, 14 Dec 2022, 18:29 Alan DeKok, <aland@deployingradius.com> wrote:
That seems pretty clear. The protocol versions don't match.
a) allow TLS 1.2 in FreeRADIUS
b) force wpa_supplicant 2.10 to use TLS 1.3
c) upgrade wpa_supplicant to a version (from git) which supports TL 1.3.
Pick one. (b) might not work, but (a) or (c) definitely work
Alan Dekok.
a works, but I'm trying to get Tls 1.3 connections only. Supplicant 2.10 supports tls 1.3 according to their documentations. The protocol version doesn't match---> I have a question here, it seems the server received a 1.3 handshake, but returned a 1.2 alert? What might be causing that?
On Dec 14, 2022, at 8:39 AM, Boby Tharappel <bobytharappel.mec@gmail.com> wrote:
a works, but I'm trying to get Tls 1.3 connections only. Supplicant 2.10 supports tls 1.3 according to their documentations.
Then it needs to be configured to use TLS 1.3. We test v3 with TLS 1.3 and wpa_supplicant, but we use a version from git, which works.
The protocol version doesn't match---> I have a question here, it seems the server received a 1.3 handshake, but returned a 1.2 alert? What might be causing that?
TLS nonsense. The version in the TLS packets is 1.2... or 1.3... mostly, until it's negotiated. And then the version becomes stable. So the error is important. The TLS versions printed before that are less useful, and don't really mean much. Alan DeKok.
W dniu 14.12.2022 o 16:11, Alan DeKok pisze:
On Dec 14, 2022, at 8:39 AM, Boby Tharappel<bobytharappel.mec@gmail.com> wrote:
a works, but I'm trying to get Tls 1.3 connections only. Supplicant 2.10 supports tls 1.3 according to their documentations. Then it needs to be configured to use TLS 1.3.
To make TLS 1.3 working with wpa_supplicnant v2.10 it has to be explicitly enabled; wpa_supplicant.conf must include: |phase1="tls_disable_tlsv1_3=0"|
The protocol version doesn't match---> I have a question here, it seems the server received a 1.3 handshake, but returned a 1.2 alert? What might be causing that?
(9) eap_tls: (TLS) recv TLS 1.3 Handshake, ClientHello
From my experience the server is always replying this way when it's configured to support TLS 1.3.
-- Marek Zarychta
W dniu 14.12.2022 o 17:03, Marek Zarychta pisze:
W dniu 14.12.2022 o 16:11, Alan DeKok pisze:
On Dec 14, 2022, at 8:39 AM, Boby Tharappel<bobytharappel.mec@gmail.com> wrote:
a works, but I'm trying to get Tls 1.3 connections only. Supplicant 2.10 supports tls 1.3 according to their documentations. Then it needs to be configured to use TLS 1.3.
To make TLS 1.3 working with wpa_supplicnant v2.10 it has to be explicitly enabled; wpa_supplicant.conf must include:
|phase1="tls_disable_tlsv1_3=0"|
The protocol version doesn't match---> I have a question here, it seems the server received a 1.3 handshake, but returned a 1.2 alert? What might be causing that?
(9) eap_tls: (TLS) recv TLS 1.3 Handshake, ClientHello
From my experience the server is always replying this way when it's configured to support TLS 1.3. I wasn't clear. Not replying, but logging TLS 1.2 client handshake as TLS 1.3 attempt.
-- Marek Zarychta
On Dec 14, 2022, at 11:55 AM, Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> wrote:
I wasn't clear. Not replying, but logging TLS 1.2 client handshake as TLS 1.3 attempt.
That's a side effect of how TLS works. It's unfortunately confusing, but there's not much we can do about that. Alan DeKok.
Marek, thanks. Your suggestion worked like a charm. When I searched online for that flag, I saw a working document by Alan DeKok himself, mentioning the same :D https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/ Cheers! Boby Tharappel
participants (3)
-
Alan DeKok -
Boby Tharappel -
Marek Zarychta