Freeradius and unexpected TLS version ->Access-Reject
Hello everyone! I have a weird issue with freeradius 3.0.16. I try to implement an auth exchange with the RADIUS, requesting EAP-TLS. At this moment I only need to get to the phase when server responds with Access-Challenge with server certificate (so, 2 packets from NAD and 2 from the server). To generate NAD-side packets I use python3 with scapy. Freeradius was set up to use EAP-TLS for test user auth. First access-request from the NAD side is responded with Access-Challenge from the server. So far so good. But when I send the second packet, I receive an Access-Reject. Suprisingly, the server reports I'm using unsupported TLS version ?0304?. Why "surprizingly"? Well, because I use earlier TLS version, and it is well visible even in server debugs (if you check "eap message" part, where is "0301"). I also checked in Wireshark (captured both on the server machine and "NAD" machine) - the packet is correctly dissected by latest wireshark and has TLS1.1 inside. Caching is disabled. OpenSSL is already at the newest version (1.1.1-1ubuntu2.1~18.04.5). I tried to rebuild my VM from scratch (so again, installed Ubuntu 18, freeradius 3.0.16, etc) - but the issue persists. Here is the debug: Ready to process requests (0) Received Access-Request Id 200 from 192.168.0.14:53256 to 192.168.0.59:1812 length 67 (0) Service-Type = Framed-User (0) User-Name = "test" (0) Framed-MTU = 1500 (0) EAP-Message = 0x020500090174657374 (0) Message-Authenticator = 0xefe697c97fd0118935d39e9a25d6baff (0) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default (0) authorize { (0) policy filter_username { (0) if (&User-Name) { (0) if (&User-Name) -> TRUE (0) if (&User-Name) { (0) if (&User-Name =~ / /) { (0) if (&User-Name =~ / /) -> FALSE (0) if (&User-Name =~ /@[^@]@/ ) { (0) if (&User-Name =~ /@[^@]@/ ) -> FALSE (0) if (&User-Name =~ /../ ) { (0) if (&User-Name =~ /../ ) -> FALSE (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+).(.+)$/)) { (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+).(.+)$/)) -> FALSE (0) if (&User-Name =~ /.$/) { (0) if (&User-Name =~ /.$/) -> FALSE (0) if (&User-Name =~ /@./) { (0) if (&User-Name =~ /@./) -> FALSE (0) } # if (&User-Name) = notfound (0) } # policy filter_username = notfound (0) [preprocess] = ok (0) auth_log: EXPAND /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d (0) auth_log: --> /var/log/freeradius/radacct/192.168.0.14/auth-detail-20200214 (0) auth_log: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d expands to /var/log/freeradius/radacct/192.168.0.14/auth-detail-20200214 (0) auth_log: EXPAND %t (0) auth_log: --> Fri Feb 14 15:03:01 2020 (0) [auth_log] = ok (0) [digest] = noop (0) suffix: Checking for suffix after "@" (0) suffix: No '@' in User-Name = "test", looking up realm NULL (0) suffix: No such realm "NULL" (0) [suffix] = noop (0) eap: Peer sent EAP Response (code 2) ID 5 length 9 (0) eap: EAP-Identity reply, returning 'ok' so we can short-circuit the rest of authorize (0) [eap] = ok (0) } # authorize = ok (0) Found Auth-Type = eap (0) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (0) authenticate { (0) eap: Peer sent packet with method EAP Identity (1) (0) eap: Calling submodule eap_tls to process data (0) eap_tls: Initiating new EAP-TLS session (0) eap_tls: Setting verify mode to require certificate from client (0) eap_tls: [eaptls start] = request (0) eap: Sending EAP Request (code 1) ID 6 length 6 (0) eap: EAP session adding &reply:State = 0xe879495de87f44cf (0) [eap] = handled (0) } # authenticate = handled (0) Using Post-Auth-Type Challenge (0) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (0) Challenge { ... } # empty sub-section is ignored (0) Sent Access-Challenge Id 200 from 192.168.0.59:1812 to 192.168.0.14:53256 length 0 (0) EAP-Message = 0x010600060d20 (0) Message-Authenticator = 0x00000000000000000000000000000000 (0) State = 0xe879495de87f44cfa950f055cfc4b84d (0) Finished request Waking up in 4.9 seconds. (1) Received Access-Request Id 201 from 192.168.0.14:53256 to 192.168.0.59:1812 length 163 (1) Service-Type = Framed-User (1) User-Name = "test" (1) Framed-MTU = 1500 (1) EAP-Message = 0x020600570d800000004d16030100480100004403015e43c51b0000000000000000000000000000000000000000000000000000000000001600040005000a0009006400620003000600130012006301000005ff01000100 (1) State = 0xe879495de87f44cfa950f055cfc4b84d (1) Message-Authenticator = 0x70eca9c059289b575655c08683064d67 (1) session-state: No cached attributes (1) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default (1) authorize { (1) policy filter_username { (1) if (&User-Name) { (1) if (&User-Name) -> TRUE (1) if (&User-Name) { (1) if (&User-Name =~ / /) { (1) if (&User-Name =~ / /) -> FALSE (1) if (&User-Name =~ /@[^@]@/ ) { (1) if (&User-Name =~ /@[^@]@/ ) -> FALSE (1) if (&User-Name =~ /../ ) { (1) if (&User-Name =~ /../ ) -> FALSE (1) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+).(.+)$/)) { (1) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+).(.+)$/)) -> FALSE (1) if (&User-Name =~ /.$/) { (1) if (&User-Name =~ /.$/) -> FALSE (1) if (&User-Name =~ /@./) { (1) if (&User-Name =~ /@./) -> FALSE (1) } # if (&User-Name) = notfound (1) } # policy filter_username = notfound (1) [preprocess] = ok (1) auth_log: EXPAND /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d (1) auth_log: --> /var/log/freeradius/radacct/192.168.0.14/auth-detail-20200214 (1) auth_log: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d expands to /var/log/freeradius/radacct/192.168.0.14/auth-detail-20200214 (1) auth_log: EXPAND %t (1) auth_log: --> Fri Feb 14 15:03:01 2020 (1) [auth_log] = ok (1) [digest] = noop (1) suffix: Checking for suffix after "@" (1) suffix: No '@' in User-Name = "test", looking up realm NULL (1) suffix: No such realm "NULL" (1) [suffix] = noop (1) eap: Peer sent EAP Response (code 2) ID 6 length 87 (1) eap: No EAP Start, assuming it's an on-going EAP conversation (1) [eap] = updated (1) } # authorize = updated (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 0xe879495de87f44cf (1) eap: Finished EAP session with state 0xe879495de87f44cf (1) eap: Previous EAP request found for state 0xe879495de87f44cf, 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: Continuing EAP-TLS (1) eap_tls: Peer indicated complete TLS record size will be 77 bytes (1) eap_tls: Got complete TLS record (77 bytes) (1) eap_tls: [eaptls verify] = length included (1) eap_tls: (other): before SSL initialization (1) eap_tls: TLS_accept: before SSL initialization (1) eap_tls: TLS_accept: before SSL initialization (1) eap_tls: <<< recv UNKNOWN TLS VERSION ?0304? [length 0048] (1) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal handshake_failure (1) eap_tls: ERROR: TLS Alert write:fatal:handshake failure tls: TLS_accept: Error in error (1) eap_tls: ERROR: Failed in FUNCTION (SSL_read): error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher (1) eap_tls: ERROR: System call (I/O) error (-1) (1) eap_tls: ERROR: TLS 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 6 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 What could be wrong here? Where should I debug further? Thanks a ton in advance for any hints! Cheers, Iron
On Feb 21, 2020, at 12:25 PM, iilinasi <Irina.Ilina-Sidorova@ulb.ac.be> wrote: I have a weird issue with freeradius 3.0.16.
I try to implement an auth exchange with the RADIUS, requesting EAP-TLS. At this moment I only need to get to the phase when server responds with Access-Challenge with server certificate (so, 2 packets from NAD and 2 from the server). To generate NAD-side packets I use python3 with scapy.
Freeradius was set up to use EAP-TLS for test user auth. First access-request from the NAD side is responded with Access-Challenge from the server. So far so good.
But when I send the second packet, I receive an Access-Reject. Suprisingly, the server reports I'm using unsupported TLS version ?0304?. Why "surprizingly"? Well, because I use earlier TLS version, and it is well visible even in server debugs (if you check "eap message" part, where is "0301").
That's for TLS 1.3. You cannot do TLS 1.3 with EAP-TLS. The standard has not yetis been written. It is not yet supported. wpa_supplicant has code which *should* work, if the proposed standards don't change. We're waiting for the standards to be finalized before implementing anything.
I also checked in Wireshark (captured both on the server machine and "NAD" machine) - the packet is correctly dissected by latest wireshark and has TLS1.1 inside.
If it's complaining about "TLS version 0304", then it's likely using TLS 1.3. The other option is to upgrade to 3.0.20, which has been out for a while. There isn't much reason to do a new install of 3.0.16 at this point.
Caching is disabled.
OpenSSL is already at the newest version (1.1.1-1ubuntu2.1~18.04.5).
I tried to rebuild my VM from scratch (so again, installed Ubuntu 18, freeradius 3.0.16, etc) - but the issue persists.
Here is the debug:
Ready to process requests
(0) Received Access-Request Id 200 from 192.168.0.14:53256 to 192.168.0.59:1812 length 67 (0) Service-Type = Framed-User (0) User-Name = "test" (0) Framed-MTU = 1500 (0) EAP-Message = 0x020500090174657374 (0) Message-Authenticator = 0xefe697c97fd0118935d39e9a25d6baff (0) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default (0) authorize { (0) policy filter_username { (0) if (&User-Name) { (0)
Hmm... mangled and unreadable. Alan DeKok.
Alan, thank you for the prompt answer! On 21.02.2020 14:29, Alan DeKok wrote:
On Feb 21, 2020, at 12:25 PM, iilinasi <Irina.Ilina-Sidorova@ulb.ac.be> wrote: I have a weird issue with freeradius 3.0.16.
I try to implement an auth exchange with the RADIUS, requesting EAP-TLS. At this moment I only need to get to the phase when server responds with Access-Challenge with server certificate (so, 2 packets from NAD and 2 from the server). To generate NAD-side packets I use python3 with scapy.
Freeradius was set up to use EAP-TLS for test user auth. First access-request from the NAD side is responded with Access-Challenge from the server. So far so good.
But when I send the second packet, I receive an Access-Reject. Suprisingly, the server reports I'm using unsupported TLS version ?0304?. Why "surprizingly"? Well, because I use earlier TLS version, and it is well visible even in server debugs (if you check "eap message" part, where is "0301").
That's for TLS 1.3. You cannot do TLS 1.3 with EAP-TLS. The standard has not yetis been written. It is not yet supported.
wpa_supplicant has code which *should* work, if the proposed standards don't change. We're waiting for the standards to be finalized before implementing anything.
Yes, I totally understand that 1.3 is not supported. The thing is: I construct the packet myself and fill in the version to be 1.1.
I also checked in Wireshark (captured both on the server machine and "NAD" machine) - the packet is correctly dissected by latest wireshark and has TLS1.1 inside.
If it's complaining about "TLS version 0304", then it's likely using TLS 1.3.
I attach the packet in question, so you'll be able to see yourself (well, I attached the conversation with all 4 packets of course, see testauth.pcapng).
The other option is to upgrade to 3.0.20, which has been out for a while. There isn't much reason to do a new install of 3.0.16 at this point.
Standard package for Ubuntu is 3.0.16 now, that's why I'm using it. I'd avoid blind upgrade. Any specific reason to go with 3.0.20 in regards with my issue?
Caching is disabled.
OpenSSL is already at the newest version (1.1.1-1ubuntu2.1~18.04.5).
I tried to rebuild my VM from scratch (so again, installed Ubuntu 18, freeradius 3.0.16, etc) - but the issue persists.
Here is the debug:
Ready to process requests
(0) Received Access-Request Id 200 from 192.168.0.14:53256 to 192.168.0.59:1812 length 67 (0) Service-Type = Framed-User (0) User-Name = "test" (0) Framed-MTU = 1500 (0) EAP-Message = 0x020500090174657374 (0) Message-Authenticator = 0xefe697c97fd0118935d39e9a25d6baff (0) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default (0) authorize { (0) policy filter_username { (0) if (&User-Name) { (0)
Hmm... mangled and unreadable.
Well, I'm sorry for that. It's a copy-paste from the command line. I redirected the output to a file and recollected (testauth.txt). It's attached as well as the packet capture.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cheers, Iron
On Feb 21, 2020, at 4:43 PM, iilinasi <Irina.Ilina-Sidorova@ulb.ac.be> wrote:
Yes, I totally understand that 1.3 is not supported. The thing is: I construct the packet myself and fill in the version to be 1.1.
How do you construct the packet yourself? Are you writing your own TLS library?
Standard package for Ubuntu is 3.0.16 now, that's why I'm using it. I'd avoid blind upgrade. Any specific reason to go with 3.0.20 in regards with my issue?
Because it's newer and will likely solve any issues. It's faster to install 3.0.20 than to wait for replies on a mailing list. Alan DeKok.
Hi, Alan, On 21.02.2020 23:26, Alan DeKok wrote:
On Feb 21, 2020, at 4:43 PM, iilinasi <Irina.Ilina-Sidorova@ulb.ac.be> wrote:
Yes, I totally understand that 1.3 is not supported. The thing is: I construct the packet myself and fill in the version to be 1.1.
How do you construct the packet yourself? Are you writing your own TLS library?
TLS library for 2 packets would be an overkill... I construct packets in my python script (can share it - but it's really very ugly at the moment). That's why I can tell you the version I send exactly - I fill it in as "0x0301", as per specification. Is there anything I miss? You can see 0x0301 in EAP message part of debug (and TLS 1.3 would correspond to 0x0304). Again, I understand that wireshark is not the ultimate source of truth, but it does not complain on anything and correctly dissects the packet as EAP-TLS 1.0.
Standard package for Ubuntu is 3.0.16 now, that's why I'm using it. I'd avoid blind upgrade. Any specific reason to go with 3.0.20 in regards with my issue?
Because it's newer and will likely solve any issues.
It's faster to install 3.0.20 than to wait for replies on a mailing list.
I installed 3.0.20 (didn't went without a few hiccups, but it's not related to this thread). The issue is still exactly the same, just debugs now a bit more readable. I attach them together with the packet capture. Thanks a lot!
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cheers, Iron
On Feb 24, 2020, at 5:09 AM, iilinasi <Irina.Ilina-Sidorova@ulb.ac.be> wrote:
TLS library for 2 packets would be an overkill... I construct packets in my python script (can share it - but it's really very ugly at the moment). That's why I can tell you the version I send exactly - I fill it in as "0x0301", as per specification. Is there anything I miss?
Well, if you're creating your own TLS implementation, there isn't much we can do to help. FreeRADIUS uses OpenSSL for its TLS implementation. We rely on OpenSSL to do all TLS work, including reporting to us the TLS version.
You can see 0x0301 in EAP message part of debug (and TLS 1.3 would correspond to 0x0304). Again, I understand that wireshark is not the ultimate source of truth, but it does not complain on anything and correctly dissects the packet as EAP-TLS 1.0.
Ask the OpenSSL people how they implement TLS. Further, this really isn't a FreeRADIUS issue. If you're writing your own TLS implementation (even if it's 2 packets), then you need to debug your code. Or, debug Wireshark / OpenSSL to see what they do. Alan DeKok.
Thanks Alan! Yup, I will continue with OpenSSL then Have a great day! -------- Original message -------- From: Alan DeKok <aland@deployingradius.com> Date: Mon, 24 Feb 2020, 12:30 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Freeradius and unexpected TLS version ->Access-Reject On Feb 24, 2020, at 5:09 AM, iilinasi <Irina.Ilina-Sidorova@ulb.ac.be> wrote: > TLS library for 2 packets would be an overkill... I construct packets in my python script (can share it - but it's really very ugly at the moment). That's why I can tell you the version I send exactly - I fill it in as "0x0301", as per specification. Is there anything I miss? Well, if you're creating your own TLS implementation, there isn't much we can do to help. FreeRADIUS uses OpenSSL for its TLS implementation. We rely on OpenSSL to do all TLS work, including reporting to us the TLS version. > You can see 0x0301 in EAP message part of debug (and TLS 1.3 would correspond to 0x0304). Again, I understand that wireshark is not the ultimate source of truth, but it does not complain on anything and correctly dissects the packet as EAP-TLS 1.0. Ask the OpenSSL people how they implement TLS. Further, this really isn't a FreeRADIUS issue. If you're writing your own TLS implementation (even if it's 2 packets), then you need to debug your code. Or, debug Wireshark / OpenSSL to see what they do. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
iilinasi -
irina.ilina-sidorova＠ulb.ac.be