OpenSSL reports wrong TLS version to FreeRADIUS

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSSL reports wrong TLS version to FreeRADIUS

iilinasi
Dear everyone,


I'm looking for your pointers to help me to debug&solve the issue I
have.

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 (3.0.16, 3.0.20) 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?
(which corresponds to TLS1.3). Why "surprizingly"? Well, because I use
earlier TLS version, and it is well visible (AVP "Eap-Message" - EAP
section - TLS part has "0301", that corresponds to TLS1.0, handshake
version also set to TLS1.0 (0x0301)).

I also checked in Wireshark (captured both on the server machine and
"NAD" machine - same results) - the packet is correctly dissected by
latest wireshark (no errors reported) and has TLS1.0 inside.

OpenSSL is already at the newest version (1.1.1-1ubuntu2.1~18.04.5).


After a discussion in freeradius maillist, I got to know that freeradius
receives all the TLS-related information from the OpenSSL.
I attach the packet exchange for the reference, the packet in question
is packet#3.


I'd like to understand, how does OpenSSL get to the idea of "0304"
version, if there is no such a byte sequence in the packet...
My question is: how OpenSSL determines the TLS version? How to debug it?

--
Have a great day!

Irina Ilina-Sidorova

test.pcapng (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL reports wrong TLS version to FreeRADIUS

Alfred Arnold
Hi,

>I'd like to understand, how does OpenSSL get to the idea of "0304"
>version, if there is no such a
>byte sequence in the packet...
>My question is: how OpenSSL determines the TLS version? How to debug it?

I don't see any TLS 1.3 in the capture as well, but I see that your client
is using only outdated (if not to say: historic) cryptographic algorithms:
RC4, RC2 (never seen that in practice!), 3DES and DES.  And those even
combined with export options to weaken key strength.  Many modern servers
are configured to disallow such outdated crypto: make your client use at
least

- AES128/256 (either in CBC or GCM mode)
- TLS 1.2
- no export cipher suites

Then you might get a more positive reply from the server...

Best regards

Alfred Arnold

--
Alfred Arnold                   E-Mail: [hidden email]
Computer Club at the            http://john.ccac.rwth-aachen.de:8000/alf/
Technical University            Phone: +49-241-406526
of Aachen

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL reports wrong TLS version to FreeRADIUS

Matt Caswell-2
In reply to this post by iilinasi


On 02/03/2020 11:28, iilinasi wrote:
> I'd like to understand, how does OpenSSL get to the idea of "0304"
> version, if there is no such a byte sequence in the packet...
> My question is: how OpenSSL determines the TLS version? How to debug it?
>

Very strange. I have no idea. Looking at the packet in question this
does appear to be a straight forward TLSv1.0 ClientHello. TLSv1.3 would
normally only ever be negotiated if the supported_versions extension is
present, and that extension lists 0304 as one of the supported versions.
But since the extension does not exist in the ClientHello it should be
attempting to use TLSv1.3.

> > Suprisingly, the server reports I'm using unsupported TLS version ?0304?
> (which corresponds to TLS1.3).

Is there any more detail around this? Server logs etc?

Matt

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL reports wrong TLS version to FreeRADIUS

iilinasi
In reply to this post by Alfred Arnold
Thank you Alfred!

Yup, I used old ciphers indeed. I suspect it stops even before checking
them, but I'll add newer ones and let you know.


This is the relevant part of freeradius log, just in case:
--
(1) eap_tls: TLS_accept: before SSL initialization
(1) eap_tls: TLS_accept: before SSL initialization
(1) eap_tls: <<< recv TLS 1.3  [length 0048]
(1) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal
protocol_version
(1) eap_tls: ERROR: TLS Alert write:fatal:protocol version
tls: TLS_accept: Error in error
(1) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read):
error:14209102:SSL
routines:tls_early_post_process_client_hello:unsupported protocol
(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
--


On 02.03.2020 14:15, Alfred Arnold wrote:

> Hi,
>
>> I'd like to understand, how does OpenSSL get to the idea of "0304"
>> version, if there is no such a
>> byte sequence in the packet...
>> My question is: how OpenSSL determines the TLS version? How to debug
>> it?
>
> I don't see any TLS 1.3 in the capture as well, but I see that your
> client is using only outdated (if not to say: historic) cryptographic
> algorithms: RC4, RC2 (never seen that in practice!), 3DES and DES.
> And those even combined with export options to weaken key strength.
> Many modern servers are configured to disallow such outdated crypto:
> make your client use at least
>
> - AES128/256 (either in CBC or GCM mode)
> - TLS 1.2
> - no export cipher suites
>
> Then you might get a more positive reply from the server...
>
> Best regards
>
> Alfred Arnold

--
Thanks and regards,
Irina Ilina-Sidorova
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL reports wrong TLS version to FreeRADIUS

iilinasi
Alfred, I'd like to say "thanks" once more.

I tried with newer ciphers and version 1.2 - and now freeradius (3.0.16)
indeed sends me the second "challenge". So, it's a huge progress.

However it still complains on the unknown TLS version. I attach the
server log and the packet capture, just in case.

Have a lovely day!


--
Thanks and regards,
Irina Ilina-Sidorova

On 03.03.2020 12:25, iilinasi wrote:

> Thank you Alfred!
>
> Yup, I used old ciphers indeed. I suspect it stops even before
> checking them, but I'll add newer ones and let you know.
>
>
> This is the relevant part of freeradius log, just in case:
> --
> (1) eap_tls: TLS_accept: before SSL initialization
> (1) eap_tls: TLS_accept: before SSL initialization
> (1) eap_tls: <<< recv TLS 1.3  [length 0048]
> (1) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal
> protocol_version
> (1) eap_tls: ERROR: TLS Alert write:fatal:protocol version
> tls: TLS_accept: Error in error
> (1) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read):
> error:14209102:SSL
> routines:tls_early_post_process_client_hello:unsupported protocol
> (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
> --
>
>
> On 02.03.2020 14:15, Alfred Arnold wrote:
>> Hi,
>>
>>> I'd like to understand, how does OpenSSL get to the idea of "0304"
>>> version, if there is no such a
>>> byte sequence in the packet...
>>> My question is: how OpenSSL determines the TLS version? How to debug
>>> it?
>>
>> I don't see any TLS 1.3 in the capture as well, but I see that your
>> client is using only outdated (if not to say: historic) cryptographic
>> algorithms: RC4, RC2 (never seen that in practice!), 3DES and DES.
>> And those even combined with export options to weaken key strength.
>> Many modern servers are configured to disallow such outdated crypto:
>> make your client use at least
>>
>> - AES128/256 (either in CBC or GCM mode)
>> - TLS 1.2
>> - no export cipher suites
>>
>> Then you might get a more positive reply from the server...
>>
>> Best regards
>>
>> Alfred Arnold

test_with_1_2.txt (54K) Download Attachment
test_with_1_2.pcapng (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL reports wrong TLS version to FreeRADIUS

Matt Caswell-2


On 03/03/2020 12:51, iilinasi wrote:
> Alfred, I'd like to say "thanks" once more.
>
> I tried with newer ciphers and version 1.2 - and now freeradius (3.0.16)
> indeed sends me the second "challenge". So, it's a huge progress.
>
> However it still complains on the unknown TLS version. I attach the
> server log and the packet capture, just in case.

This is the interesting part from the server log.

(1) eap_tls: TLS_accept: before SSL initialization
(1) eap_tls: <<< recv UNKNOWN TLS VERSION ?0304? [length 0048]
(1) eap_tls: TLS_accept: SSLv3/TLS read client hello

The "before SSL initialization" and the "SSLv3/TLS read client hello"
strings are generated by OpenSSL. They are the return values from a call
to the function SSL_state_string_long() and are intended to give a human
readable output of what state the SSL object is in and where in the
handshake process it has got to.

Interestingly the "UNKNOWN TLS VERSION" message appears between the
"before" state and the "read client hello" state. The latter will be
returned after the SSL object has gone through its initial setup but
before or during the processing of a ClientHello received from the
client. The TLS protocol version that server will use is chosen during
the processing of that ClientHello. Depending on exactly at what point
we're at it is possible that a call to SSL_version() will return either
the selected version or (if we haven't got as far as selecting a version
yet), the version that the SSL object was initialised with.

New SSL objects created using TLS_method(), or TLS_server_method() will
have their version initialised to TLS_MAX_VERSION. In OpenSSL 1.1.1
TLS_MAX_VERSION is 0x0304 (TLSv1.3).

The string "UNKNOWN TLS VERSION" does not appear in libssl at all. So my
guess is that this warning is actually coming from eap_tls after it has
made a call to SSL_version(). Since the version has not actually been
negotiated yet it comes back with TLSv1.3, and eap_tls doesn't know how
to handle it.

Is this actually an error? Or just a warning?

Matt
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL reports wrong TLS version to FreeRADIUS

Matt Caswell-2
In reply to this post by iilinasi


On 02/03/2020 11:28, iilinasi wrote:
> Freeradius (3.0.16, 3.0.20)

Could be this issue:

https://github.com/FreeRADIUS/freeradius-server/issues/2385

"It may be due to the issue fixed in commit fd803c9. 3.0.17 sometimes
complained that TLS 1.3 was unknown, and refused to do TLS 1.3 at all.
That patch should fix it."

Matt
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL reports wrong TLS version to FreeRADIUS

Alfred Arnold
In reply to this post by iilinasi
Hi,

>Alfred, I'd like to say "thanks" once more.
>
>I tried with newer ciphers and version 1.2 - and now freeradius (3.0.16)
>indeed sends me the second
>"challenge". So, it's a huge progress.

Indeed, the capture now looks like an EAP-TLS negotiation should go on.
The server accepted the client hello, an prepared its message flight of
messages.  Among them is the server's Certificate message, which is quite
huge, and so they cannot be sent in one packet.  Your client would next
send an empty EAP-TLS message, thereby acknowledging reception of this
message fragment.  The server would then send the next fragment of these
messages.  Since the overall length of the message flight is 3137, and
FreeRADUIS decided to send ~1000 bytes per fragment, expect another two of
those 'ping-pongs' to happen until your client is able to reassemble and
process the server's messages.

>However it still complains on the unknown TLS version. I attach the
>server log and the packet capture, just in case.

Well, no idea where the version 0x0304 is coming from.  One would probably
have to look into the FreeRADIUS sources, or ask on the proper FreeRADIUS
mailing lists for assistance.  My personal "wild guess" is that this is
some sort of 'internal default' as long as the the EAP-TLS module hasn't
yet decided about the used protocol version.  I wouldn't bother about this
too much if you're interested in other things.

There's however one other thing I wanted to mention: The Random value your
clients sends in the Client Hello is not that random...there is the time
stamp in the first four bytes, but the remaining 28 bytes are all-zero -
they should contain data from a cryptographically safe random number
generator.

Best regards

Alfred Arnold

--
Alfred Arnold                   E-Mail: [hidden email]
Computer Club at the            http://john.ccac.rwth-aachen.de:8000/alf/
Technical University            Phone: +49-241-406526
of Aachen

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL reports wrong TLS version to FreeRADIUS

iilinasi
On 03.03.2020 16:03, Alfred Arnold wrote:

> Hi,
>
>> Alfred, I'd like to say "thanks" once more.
>>
>> I tried with newer ciphers and version 1.2 - and now freeradius
>> (3.0.16) indeed sends me the second
>> "challenge". So, it's a huge progress.
>
> Indeed, the capture now looks like an EAP-TLS negotiation should go
> on. The server accepted the client hello, an prepared its message
> flight of messages.  Among them is the server's Certificate message,
> which is quite huge, and so they cannot be sent in one packet.  Your
> client would next send an empty EAP-TLS message, thereby acknowledging
> reception of this message fragment.  The server would then send the
> next fragment of these messages.  Since the overall length of the
> message flight is 3137, and FreeRADUIS decided to send ~1000 bytes per
> fragment, expect another two of those 'ping-pongs' to happen until
> your client is able to reassemble and process the server's messages.
>
Yes, this is what I'm adding to my script now.

>> However it still complains on the unknown TLS version. I attach the
>> server log and the packet capture, just in case.
>
> Well, no idea where the version 0x0304 is coming from.  One would
> probably have to look into the FreeRADIUS sources, or ask on the
> proper FreeRADIUS mailing lists for assistance.  My personal "wild
> guess" is that this is some sort of 'internal default' as long as the
> the EAP-TLS module hasn't yet decided about the used protocol version.
>  I wouldn't bother about this too much if you're interested in other
> things.
>
> There's however one other thing I wanted to mention: The Random value
> your clients sends in the Client Hello is not that random...there is
> the time stamp in the first four bytes, but the remaining 28 bytes are
> all-zero - they should contain data from a cryptographically safe
> random number generator.
>
Thank you :-) Yes, I set it to zeroes as it was easier to read the
packet with this big zeroed part (and also I wanted to be sure in
absence of "0304"). Thanks for the reminder - I'll put there some output
from /dev/urandom.


> Best regards
>
> Alfred Arnold

Have a lovely day!
--
Thanks and regards,
Irina Ilina-Sidorova