Authentication problems with some devices: TLS version too low
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
On Sep 1, 2017, at 1:16 PM, Lars Veldscholte <lars@tuxplace.nl> wrote:
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.
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 On 01/09/2017 20:20, Alan DeKok wrote:
On Sep 1, 2017, at 1:16 PM, Lars Veldscholte <lars@tuxplace.nl> wrote:
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
On 01.09.2017 20:24, Lars Veldscholte wrote:
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.
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 On 01/09/2017 20:40, Sven Hartge wrote:
On 01.09.2017 20:24, Lars Veldscholte wrote:
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
On 01.09.2017 20:48, Lars Veldscholte wrote:
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.
Thanks a lot! I'll do that. Regards, Lars On 01/09/2017 21:12, Sven Hartge wrote:
On 01.09.2017 20:48, Lars Veldscholte wrote:
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
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 On 01/09/2017 21:12, Sven Hartge wrote:
On 01.09.2017 20:48, Lars Veldscholte wrote:
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
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 On 02/09/2017 18:24, Sven Hartge wrote:
On 02.09.2017 17:56, Lars Veldscholte wrote:
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
lars@tuxplace.nl (Lars Veldscholte) writes: [...]
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) [...]
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... KJ -- http://wolnelektury.pl/wesprzyj/teraz/ Give me a sleeping pill and tell me your troubles.
On Sep 9, 2017, at 2:59 PM, Lars Veldscholte <lars@tuxplace.nl> wrote:
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.
On 09/09/2017 21:39, Alan DeKok wrote:
On Sep 9, 2017, at 2:59 PM, Lars Veldscholte <lars@tuxplace.nl> wrote:
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
On 02/09/2017 17:56, Lars Veldscholte wrote:
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
On 01/09/2017 21:12, Sven Hartge wrote:
On 01.09.2017 20:48, Lars Veldscholte wrote:
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
participants (4)
-
Alan DeKok -
kjonca＠o2.pl -
Lars Veldscholte -
Sven Hartge