Authentication problems with some devices: TLS version too low

[Lars Veldscholte]

Hello everyone,

I have problems with authenticating some clients using PEAP-MSCHAP. I've
seen two (unrelated) devices having this issue so far: an Android phone
and a Windows 7 PC. Other clients do not have this problem.

The debug output is:

(2) eap: Peer sent packet with method EAP PEAP (25)
(2) eap: Calling submodule eap_peap to process data
(2) eap_peap: Continuing EAP-TLS
(2) eap_peap: Peer indicated complete TLS record size will be 99 bytes
(2) eap_peap: Got complete TLS record (99 bytes)
(2) eap_peap: [eaptls verify] = length included
(2) eap_peap: (other): before SSL initialization
(2) eap_peap: TLS_accept: before SSL initialization
(2) eap_peap: TLS_accept: before SSL initialization
(2) eap_peap: <<< recv TLS 1.2 [length 005e]
(2) eap_peap: >>> send TLS 1.0 Alert [length 0002], fatal protocol_version
(2) eap_peap: ERROR: TLS Alert write:fatal:protocol version
tls: TLS_accept: Error in error
(2) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read):
error:1417D18C:SSL routines:tls_process_client_hello:version too low
(2) eap_peap: ERROR: System call (I/O) error (-1)
(2) eap_peap: ERROR: TLS receive handshake failed during operation
(2) eap_peap: ERROR: [eaptls process] = fail
(2) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module
failed
(2) eap: Sending EAP Failure (code 4) ID 230 length 4
(2) eap: Failed in EAP select
(2) [eap] = invalid
(2) } # authenticate = invalid
(2) Failed to authenticate the user

I'm not sure if I'm interpreting this correctly, but it seems that the
client is trying to talk in TLSv1.2 while FreeRADIUS doesn't support that?

I don't know what started this problem. PEAP always worked in the past,
until now. The only thing I can think of is that I've recently generated
new certificates (old ones were expired). There has also been a
FreeRADIUS update (just regular Debian updates, I'm on 3.0.15 now).
Could that be related?

Thanks in advance for your help,

Lars

[Alan DeKok]

I have problems with authenticating some clients using PEAP-MSCHAP. I've seen two (unrelated) devices having this issue so far: an Android phone and a Windows 7 PC. Other clients do not have this problem.

Vendors are starting to move to TLS 1.2 everywhere.

...

(2) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417D18C:SSL routines:tls_process_client_hello:version too low
(2) eap_peap: ERROR: System call (I/O) error (-1)
(2) eap_peap: ERROR: TLS receive handshake failed during operation
(2) eap_peap: ERROR: [eaptls process] = fail
(2) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed
(2) eap: Sending EAP Failure (code 4) ID 230 length 4
(2) eap: Failed in EAP select
(2) [eap] = invalid
(2) } # authenticate = invalid
(2) Failed to authenticate the user
I'm not sure if I'm interpreting this correctly, but it seems that the client is trying to talk in TLSv1.2 while FreeRADIUS doesn't support that?

Pretty much. They *should* be able to negotiate a compatible TLS version, if your local version of OpenSSL supports TLS 1.2

I don't know what started this problem. PEAP always worked in the past, until now.

The clients upgraded, and now only allow TLS 1.2.

The only thing I can think of is that I've recently generated new certificates (old ones were expired). There has also been a FreeRADIUS update (just regular Debian updates, I'm on 3.0.15 now). Could that be related?

No.

You will need to update OpenSSL to a version which supports TLS 1.2. And then re-build and re-install FreeRADIUS.

Given that *everything* depends on OpenSSL, you're probably better off just installing a new VM with a recent version of Debian. Then, copy your current configuration over to the new machine.

Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius

[Lars Veldscholte]

Hi Alan,

Thanks for your reply.

I am running a recent Debian install (Buster) with OpenSSL 1.1.0f, which
should support TLSv1.2 to my knowledge.

Regards,

Lars

Post by Alan DeKok

I have problems with authenticating some clients using PEAP-MSCHAP. I've seen two (unrelated) devices having this issue so far: an Android phone and a Windows 7 PC. Other clients do not have this problem.

Vendors are starting to move to TLS 1.2 everywhere.
...

(2) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417D18C:SSL routines:tls_process_client_hello:version too low
(2) eap_peap: ERROR: System call (I/O) error (-1)
(2) eap_peap: ERROR: TLS receive handshake failed during operation
(2) eap_peap: ERROR: [eaptls process] = fail
(2) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed
(2) eap: Sending EAP Failure (code 4) ID 230 length 4
(2) eap: Failed in EAP select
(2) [eap] = invalid
(2) } # authenticate = invalid
(2) Failed to authenticate the user
I'm not sure if I'm interpreting this correctly, but it seems that the client is trying to talk in TLSv1.2 while FreeRADIUS doesn't support that?

Pretty much. They *should* be able to negotiate a compatible TLS version, if your local version of OpenSSL supports TLS 1.2

I don't know what started this problem. PEAP always worked in the past, until now.

The clients upgraded, and now only allow TLS 1.2.

The only thing I can think of is that I've recently generated new certificates (old ones were expired). There has also been a FreeRADIUS update (just regular Debian updates, I'm on 3.0.15 now). Could that be related?

No.
You will need to update OpenSSL to a version which supports TLS 1.2. And then re-build and re-install FreeRADIUS.
Given that *everything* depends on OpenSSL, you're probably better off just installing a new VM with a recent version of Debian. Then, copy your current configuration over to the new machine.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Sven Hartge]

Post by Lars Veldscholte
I am running a recent Debian install (Buster) with OpenSSL 1.1.0f, which
should support TLSv1.2 to my knowledge.

Are you sure? Buster is Testing right now and might pose a different
problem: They switched off any TLS-version *but* TSL1.2, so older
Devices like Windows 7, Windows 8/8.1 and any Android below 6.0 will now
longer work.

Grüße,
Sven.
-
List info/subscribe/unsubscribe? See http://www.freer

[Lars Veldscholte]

Hi Sven,

That's right, I'm on testing.

So that's it then... So I was reading the debug log exactly the wrong
way around (client wants to talk in TLSv1.0 but server doesn't support
that)?

Any way to enable that again, or do I have to find another solution?

Regards,

Lars

Post by Sven Hartge

Post by Lars Veldscholte
I am running a recent Debian install (Buster) with OpenSSL 1.1.0f, which
should support TLSv1.2 to my knowledge.

Are you sure? Buster is Testing right now and might pose a different
problem: They switched off any TLS-version *but* TSL1.2, so older
Devices like Windows 7, Windows 8/8.1 and any Android below 6.0 will now
longer work.
GrÌße,
Sven.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Sven Hartge]

Post by Lars Veldscholte
That's right, I'm on testing.
So that's it then... So I was reading the debug log exactly the wrong
way around (client wants to talk in TLSv1.0 but server doesn't support
that)?
Any way to enable that again, or do I have to find another solution?

The "solution" proposed by Kurt Roeckx, the DD maintaining OpenSSL in
Debian, is to change every program to use the new APIs in OpenSSL 1.1+
to specify the minimum TLS version supported.

Or to convince every user to upgrade to a OS supporting TLS1.2.

My solution was to recompile the openssl package and reverting those
changes back to the former default.

This is not complicated, just "apt-get source openssl" and then comment
"tls1_2_default.patch" in SRCDIR/debian/patches/series.

Rebuild, install, "apt-mark hold libssl1.1 openssl" and your are done.

You need to repeat this procedure every update to the package, of course.

Grüße,
Sven.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/

[Lars Veldscholte]

Thanks a lot! I'll do that.

Regards,

Lars

Post by Sven Hartge

Post by Lars Veldscholte
That's right, I'm on testing.
So that's it then... So I was reading the debug log exactly the wrong
way around (client wants to talk in TLSv1.0 but server doesn't support
that)?
Any way to enable that again, or do I have to find another solution?

The "solution" proposed by Kurt Roeckx, the DD maintaining OpenSSL in
Debian, is to change every program to use the new APIs in OpenSSL 1.1+
to specify the minimum TLS version supported.
Or to convince every user to upgrade to a OS supporting TLS1.2.
My solution was to recompile the openssl package and reverting those
changes back to the former default.
This is not complicated, just "apt-get source openssl" and then comment
"tls1_2_default.patch" in SRCDIR/debian/patches/series.
Rebuild, install, "apt-mark hold libssl1.1 openssl" and your are done.
You need to repeat this procedure every update to the package, of course.
GrÌße,
Sven.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Lars Veldscholte]

Hi Sven,

So I tried your advice, but there doesn't seem to be a patch with that name.

/usr/src/openssl-1.1.0f/debian/patches# ls -al
total 48
drwxr-xr-x 2 root root 4096 Sep 2 17:36 .
drwxr-xr-x 5 root root 4096 Sep 2 17:35 ..
-rw-r--r-- 1 root root 1419 Jun 5 11:39
0001-Only-release-thread-local-key-if-we-created-it.patch
-rw-r--r-- 1 root root 2014 Jan 26 2017 c_rehash-compat.patch
-rw-r--r-- 1 root root 4028 Aug 6 23:38 debian-targets.patch
-rw-r--r-- 1 root root 2280 Aug 6 23:37 Fix-a-Proxy-race-condition.patch
-rw-r--r-- 1 root root 2556 May 25 20:53 man-section.patch
-rw-r--r-- 1 root root 534 Aug 4 2016 no-symbolic.patch
-rw-r--r-- 1 root root 710 May 28 2016 padlock_conf.patch
-rw-r--r-- 1 root root 5278 Aug 4 2016 pic.patch
-rw-r--r-- 1 root root 200 Aug 6 23:53 series

/usr/src/openssl-1.1.0f/debian/patches# cat series
debian-targets.patch
man-section.patch
no-symbolic.patch
pic.patch
c_rehash-compat.patch
#padlock_conf.patch
0001-Only-release-thread-local-key-if-we-created-it.patch
Fix-a-Proxy-race-condition.patch

It seems to be the current release though, with the changelog indicating
that indeed a change has been made in this version to disable TLSv1.0
and v.1.1:

/usr/src/openssl-1.1.0f/debian# head changelog
openssl (1.1.0f-4) unstable; urgency=medium

[ Sebastian Andrzej Siewior ]
* Add support for arm64ilp32, patch by Wookey (Closes: #867240)

[ Kurt Roeckx ]
* Disable TLS 1.0 and 1.1, leaving 1.2 as the only supported SSL/TLS
version. This will likely break things, but the hope is that by
the release of Buster everything will speak at least TLS 1.2. This
will be
reconsidered before the Buster release.

Regards,

Lars

Post by Sven Hartge

Post by Lars Veldscholte
That's right, I'm on testing.
So that's it then... So I was reading the debug log exactly the wrong
way around (client wants to talk in TLSv1.0 but server doesn't support
that)?
Any way to enable that again, or do I have to find another solution?

The "solution" proposed by Kurt Roeckx, the DD maintaining OpenSSL in
Debian, is to change every program to use the new APIs in OpenSSL 1.1+
to specify the minimum TLS version supported.
Or to convince every user to upgrade to a OS supporting TLS1.2.
My solution was to recompile the openssl package and reverting those
changes back to the former default.
This is not complicated, just "apt-get source openssl" and then comment
"tls1_2_default.patch" in SRCDIR/debian/patches/series.
Rebuild, install, "apt-mark hold libssl1.1 openssl" and your are done.
You need to repeat this procedure every update to the package, of course.
GrÌße,
Sven.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Sven Hartge]

Post by Lars Veldscholte
So I tried your advice, but there doesn't seem to be a patch with that name.

Ah, Testing, right. I am on Sid, where OpenSSL is one Debian release
newer. Get the source from Sid and use that to recompile it.

GrÌße,
Sven.

[Lars Veldscholte]

I tried it using packages from sid, but that wouldn't compile on my
system (with dpkg-buildpackage). So initially I gave up, but currently
Buster is on the same OpenSSL version as Sid (1.1.0f-5), so I did the
same thing with the packages downloaded from apt source.

They built fine and I think my change in OpenSSL worked. I can
successfully connect using TLS1.0 (tested with openssl s_client -connect
google.com:443 -tls1). I should note that I haven't tested this *before*
(with the 'unmodded' OpenSSL) though, but I assume that the above test
would have failed.

However it did not have any effect on FreeRADIUS, I'm getting the same
error as before. Of course I did restart my FreeRADIUS service.

How can I check what libssl FreeRADIUS is using? I noticed that there
are two libssl versions installed on my system: libssl1.0.2 and
libssl1.1. I only made the change in libssl1.1. Could it be that
FreeRADIUS is using the former instead?

Thanks,

Lars

Post by Sven Hartge

Post by Lars Veldscholte
So I tried your advice, but there doesn't seem to be a patch with that name.

Ah, Testing, right. I am on Sid, where OpenSSL is one Debian release
newer. Get the source from Sid and use that to recompile it.
GrÌße,
Sven.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Kamil Jońca]

***@tuxplace.nl (Lars Veldscholte) writes:

[...]

Post by Lars Veldscholte
How can I check what libssl FreeRADIUS is using? I noticed that there

ldd /usr/sbin/freeradius

[...]
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f00826c8000)
[...]

Post by Lars Veldscholte
are two libssl versions installed on my system: libssl1.0.2 and
libssl1.1. I only made the change in libssl1.1. Could it be that
FreeRADIUS is using the former instead?

Try to install and hold:
--8<---------------cut here---------------start------------->8---
hi libssl1.1:amd64 1.1.0f-3
--8<---------------cut here---------------end--------------->8---

(1.1.0f-4 is "broken")

for example from here
http://ftp.us.debian.org/debian/pool/main/o/openssl/libssl1.1_1.1.0f-3_amd64.deb
KJ

[Alan DeKok]

I tried it using packages from sid, but that wouldn't compile on my system (with dpkg-buildpackage). So initially I gave up, but currently Buster is on the same OpenSSL version as Sid (1.1.0f-5), so I did the same thing with the packages downloaded from apt source.
They built fine and I think my change in OpenSSL worked. I can successfully connect using TLS1.0 (tested with openssl s_client -connect google.com:443 -tls1). I should note that I haven't tested this *before* (with the 'unmodded' OpenSSL) though, but I assume that the above test would have failed.
However it did not have any effect on FreeRADIUS, I'm getting the same error as before. Of course I did restart my FreeRADIUS service.
How can I check what libssl FreeRADIUS is using?

$ freeradius -XxC | grep ssl

And you'll see the OpenSSL version.

I noticed that there are two libssl versions installed on my system: libssl1.0.2 and libssl1.1. I only made the change in libssl1.1. Could it be that FreeRADIUS is using the former instead?

Yes.

It's really not a good idea to install multiple versions of OpenSSL.

Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freer

[Lars Veldscholte]

Post by Alan DeKok

I tried it using packages from sid, but that wouldn't compile on my system (with dpkg-buildpackage). So initially I gave up, but currently Buster is on the same OpenSSL version as Sid (1.1.0f-5), so I did the same thing with the packages downloaded from apt source.
They built fine and I think my change in OpenSSL worked. I can successfully connect using TLS1.0 (tested with openssl s_client -connect google.com:443 -tls1). I should note that I haven't tested this *before* (with the 'unmodded' OpenSSL) though, but I assume that the above test would have failed.
However it did not have any effect on FreeRADIUS, I'm getting the same error as before. Of course I did restart my FreeRADIUS service.
How can I check what libssl FreeRADIUS is using?

$ freeradius -XxC | grep ssl
And you'll see the OpenSSL version.

I noticed that there are two libssl versions installed on my system: libssl1.0.2 and libssl1.1. I only made the change in libssl1.1. Could it be that FreeRADIUS is using the former instead?

Yes.
It's really not a good idea to install multiple versions of OpenSSL.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

I never did that manually; both versions are installed as a consequence
of packages that depend on them. (if I try to remove libssl1.0.2, apt
wants to remove a whole bunch of (rather essential) packages, including
OpenSSH.

Thanks to Kamil's hint I know for sure that FreeRADIUS is using
libssl1.1. "freeradius -XxC | grep ssl" also confirms that.

I can also confirm that installing openssl 1.1.0f-3 works!

Lars

[Lars Veldscholte]

Post by Lars Veldscholte
Hi Sven,
So I tried your advice, but there doesn't seem to be a patch with that name.
/usr/src/openssl-1.1.0f/debian/patches# ls -al
total 48
drwxr-xr-x 2 root root 4096 Sep  2 17:36 .
drwxr-xr-x 5 root root 4096 Sep  2 17:35 ..
-rw-r--r-- 1 root root 1419 Jun  5 11:39
0001-Only-release-thread-local-key-if-we-created-it.patch
-rw-r--r-- 1 root root 2014 Jan 26  2017 c_rehash-compat.patch
-rw-r--r-- 1 root root 4028 Aug  6 23:38 debian-targets.patch
-rw-r--r-- 1 root root 2280 Aug  6 23:37 Fix-a-Proxy-race-condition.patch
-rw-r--r-- 1 root root 2556 May 25 20:53 man-section.patch
-rw-r--r-- 1 root root  534 Aug  4  2016 no-symbolic.patch
-rw-r--r-- 1 root root  710 May 28  2016 padlock_conf.patch
-rw-r--r-- 1 root root 5278 Aug  4  2016 pic.patch
-rw-r--r-- 1 root root  200 Aug  6 23:53 series
/usr/src/openssl-1.1.0f/debian/patches# cat series
debian-targets.patch
man-section.patch
no-symbolic.patch
pic.patch
c_rehash-compat.patch
#padlock_conf.patch
0001-Only-release-thread-local-key-if-we-created-it.patch
Fix-a-Proxy-race-condition.patch
It seems to be the current release though, with the changelog indicating
that indeed a change has been made in this version to disable TLSv1.0
/usr/src/openssl-1.1.0f/debian# head changelog
openssl (1.1.0f-4) unstable; urgency=medium
  [ Sebastian Andrzej Siewior ]
  * Add support for arm64ilp32, patch by Wookey (Closes: #867240)
  [ Kurt Roeckx ]
  * Disable TLS 1.0 and 1.1, leaving 1.2 as the only supported SSL/TLS
    version. This will likely break things, but the hope is that by
    the release of Buster everything will speak at least TLS 1.2. This
will be
    reconsidered before the Buster release.
Regards,
Lars

Post by Sven Hartge

Post by Lars Veldscholte
That's right, I'm on testing.
So that's it then... So I was reading the debug log exactly the wrong
way around (client wants to talk in TLSv1.0 but server doesn't support
that)?
Any way to enable that again, or do I have to find another solution?

The "solution" proposed by Kurt Roeckx, the DD maintaining OpenSSL in
Debian, is to change every program to use the new APIs in OpenSSL 1.1+
to specify the minimum TLS version supported.
Or to convince every user to upgrade to a OS supporting TLS1.2.
My solution was to recompile the openssl package and reverting those
changes back to the former default.
This is not complicated, just "apt-get source openssl" and then comment
"tls1_2_default.patch" in SRCDIR/debian/patches/series.
Rebuild, install, "apt-mark hold libssl1.1 openssl" and your are done.
You need to repeat this procedure every update to the package, of course.
GrÌße,
Sven.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

A yes, of course, LDD. It shows 1.1 so it should work...

Installing 1.1.0f-3 is even a simpler solution than downloading the
source, removing the patch and rebuilding. I'll try that. It's the same
upstream version so that will work without breaking stuff, right?

Regards,

Lars