Freeradius and unexpected TLS version ->Access-Reject

iilinasi Irina.Ilina-Sidorova at ulb.ac.be
Fri Feb 21 16:43:06 CET 2020


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 at 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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testauth.txt
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20200221/0d4589a8/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testauth.pcapng
Type: application/octet-stream
Size: 996 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20200221/0d4589a8/attachment-0001.obj>


More information about the Freeradius-Users mailing list