EAP-PEAP - difference between 3.0.25 and 3.2
Sorry for being vague, but for now I am not sure where problem is and how to debug. Debian box with debian radius packages. There is old phone (Samsung Wave) which was configured to use PEAP0 to connect to wifi. /etc/freeradius/3.0/mods-config/files/authorize contains [...] theta Cleartext-Password := "...redacted...." [...] This cofiguration works with: 3.0.25+dfsg-1+b2 version of package but after install 3.2.0+dfsg-1 authentication cannot end Tue Jun 28 06:24:23 2022 : Debug: (51) } # Post-Auth-Type REJECT = updated Tue Jun 28 06:24:23 2022 : Auth: (51) Login incorrect (eap1: rlm_eap (eap1): Aborting! More than 50 roundtrips made in session with state 0x41d5024f73881b73): [theta] (from client ni port 4 cli 00-26-37-AF-E2-AC) Any hints what I can check/debug (apart taking look into source code?) Of course I can provide logs, but they are quite huge. KJ -- http://wolnelektury.pl/wesprzyj/teraz/
On 28/06/2022 08:41, Kamil Jońca wrote:
Debian box with debian radius packages.
There is old phone (Samsung Wave) which was configured to use PEAP0 to connect to wifi.
If it's an old phone you might want to check OpenSSL ciphers / TLS versions. That's the most likely.
Of course I can provide logs, but they are quite huge.
Please send logs of both. We don't have time to make random guesses. Just from `freeradius -X` (not -xxx, -Xx, etc) -- Matthew
Matthew Newton <mcn@freeradius.org> writes:
On 28/06/2022 08:41, Kamil Jońca wrote:
Debian box with debian radius packages. There is old phone (Samsung Wave) which was configured to use PEAP0 to connect to wifi.
If it's an old phone you might want to check OpenSSL ciphers / TLS versions. That's the most likely.
I have some older devices and I have to enable some strange ciphers :(
Of course I can provide logs, but they are quite huge.
Please send logs of both. We don't have time to make random guesses.
Just from `freeradius -X` (not -xxx, -Xx, etc)
3.0.25 https://drive.google.com/file/d/1uswz1jQRyAE_J7b9tu8Hrf4HmZqkT0NW/view?usp=s... 3.2 https://drive.google.com/file/d/15ONVo-KrM0Mq6Jrwu0PlKBDFMKTBpDgX/view?usp=s... KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
On Jun 28, 2022, at 9:04 AM, Kamil Jońca <kjonca@op.pl> wrote:
3.0.25 https://drive.google.com/file/d/1uswz1jQRyAE_J7b9tu8Hrf4HmZqkT0NW/view?usp=s... 3.2 https://drive.google.com/file/d/15ONVo-KrM0Mq6Jrwu0PlKBDFMKTBpDgX/view?usp=s...
From a quick look, with 3.0.25, the client sends a bunch of information after the TLS session has been established. This is the initial "inner EAP" data. For 3.2.0, the client sends nothing after the TLS session has been established. For FreeRADIUS sends an ACK "please send more data", and the client sends an ACK "no, you send more data". And then that process repeats. I suspect that whatever is going wrong is likely in the TLS layer. Are you running both 3.0.25 and 3.2.0 on the same machine, with the same OpenSSL libraries, etc? Or are they on different machines? I don't see anything immediately different in the FreeRADIUS behavior. It just relies on OpenSSL to do the TLS negotiation. The client *should* send "inner tunnel" data once the session is established. For 3.0.25, it does. For 3.2.0, the client doesn't send it. Alan DeKok.
Alan DeKok <aland@deployingradius.com> writes:
On Jun 28, 2022, at 9:04 AM, Kamil Jońca <kjonca@op.pl> wrote:
3.0.25 https://drive.google.com/file/d/1uswz1jQRyAE_J7b9tu8Hrf4HmZqkT0NW/view?usp=s... 3.2 https://drive.google.com/file/d/15ONVo-KrM0Mq6Jrwu0PlKBDFMKTBpDgX/view?usp=s...
From a quick look, with 3.0.25, the client sends a bunch of information after the TLS session has been established. This is the initial "inner EAP" data.
For 3.2.0, the client sends nothing after the TLS session has been established. For FreeRADIUS sends an ACK "please send more data", and the client sends an ACK "no, you send more data". And then that process repeats.
I suspect that whatever is going wrong is likely in the TLS layer. Are you running both 3.0.25 and 3.2.0 on the same machine, with the same OpenSSL libraries, etc? Or are they on different machines?
This is the same machine. I just downgraded/upgraded freeradius packages for testing. freeradius_3.0.25+dfsg-1+b2_amd64.deb libfreeradius3_3.0.25+dfsg-1+b2_amd64.deb freeradius-dhcp_3.0.25+dfsg-1+b2_amd64.deb (and their 3.2 counterparts) KJ -- http://wolnelektury.pl/wesprzyj/teraz/
Alan DeKok <aland@deployingradius.com> writes:
On Jun 28, 2022, at 9:04 AM, Kamil Jońca <kjonca@op.pl> wrote:
3.0.25 https://drive.google.com/file/d/1uswz1jQRyAE_J7b9tu8Hrf4HmZqkT0NW/view?usp=s... 3.2 https://drive.google.com/file/d/15ONVo-KrM0Mq6Jrwu0PlKBDFMKTBpDgX/view?usp=s...
From a quick look, with 3.0.25, the client sends a bunch of information after the TLS session has been established. This is the initial "inner EAP" data.
For 3.2.0, the client sends nothing after the TLS session has been established. For FreeRADIUS sends an ACK "please send more data", and the client sends an ACK "no, you send more data". And then that process repeats.
I suspect that whatever is going wrong is likely in the TLS layer. Are you running both 3.0.25 and 3.2.0 on the same machine, with the same OpenSSL libraries, etc? Or are they on different machines?
I do not know if this is important, but you probably see: --8<---------------cut here---------------start------------->8--- cipher_list = "DEFAULT:TLSv1.0:AECDH-AES256-SHA@SECLEVEL=0:AECDH-AES128-SHA@SECLEVEL=0" --8<---------------cut here---------------end--------------->8--- Thesee "SECLEVEL=0" (and SECLEVEL pragma) were needed because of another (not so old) devices which suppport these ciphers. In 3.0.25 they were not needed, it was enough to have --8<---------------cut here---------------start------------->8--- cipher_list = "DEFAULT:TLSv1.0" --8<---------------cut here---------------end--------------->8--- maybe this observation is relevant? KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Alan DeKok <aland@deployingradius.com> writes:
On Jun 28, 2022, at 9:04 AM, Kamil Jońca <kjonca@op.pl> wrote:
3.0.25 https://drive.google.com/file/d/1uswz1jQRyAE_J7b9tu8Hrf4HmZqkT0NW/view?usp=s... 3.2 https://drive.google.com/file/d/15ONVo-KrM0Mq6Jrwu0PlKBDFMKTBpDgX/view?usp=s...
From a quick look, with 3.0.25, the client sends a bunch of information after the TLS session has been established. This is the initial "inner EAP" data.
For 3.2.0, the client sends nothing after the TLS session has been established. For FreeRADIUS sends an ACK "please send more data", and the client sends an ACK "no, you send more data". And then that process repeats.
I suspect that whatever is going wrong is likely in the TLS layer. Are you running both 3.0.25 and 3.2.0 on the same machine, with the same OpenSSL libraries, etc? Or are they on different machines?
You probably right. Although I only changed freeradius binaries, I have installed multiple different versions of openssl and: 3.0.25 sudo ldd /usr/sbin/freeradius [...] libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f63e4e00000) libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f63e51d7000) [...] 3.2 sudo ldd /usr/sbin/freeradius [...] libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f749c200000) libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f749c155000) [...] So probably ssl3 hadles this differently (And probably I have no chance to debug it due to lack of knowledge :( ) KJ -- http://wolnelektury.pl/wesprzyj/teraz/
On Jun 28, 2022, at 2:13 PM, Kamil Jońca <kjonca@op.pl> wrote:
Although I only changed freeradius binaries, I have installed multiple different versions of openssl and:
Don't do that. It's impossible to debug an issue if you change multiple things at the same time. Is the issue OpenSSL? FreeRADIUS? Or a configuration change in FreeRADIUS? We don't know. And because it could be any one of those things, you'll have to track down exactly which change is the one that broke it.
So probably ssl3 hadles this differently (And probably I have no chance to debug it due to lack of knowledge :( )
You can install *one* OpenSSL package, and try that. You can ensure that FreeRADIUS 3.0.25 and 3.2.0 have the *same* configuration files. When you make random changes, it's impossible to figure out what went wrong. The only way to fix is is a methodical approach. Change one thing at a time, test it, and repeat. This *is* debugging. You don't need to poke around in the internals of FreeRADIUS or OpenSSL. All you need to do is to identify which one of the 3-4 things you changed was the source of the problem. Alan DeKok.
Alan DeKok <aland@deployingradius.com> writes:
On Jun 28, 2022, at 2:13 PM, Kamil Jońca <kjonca@op.pl> wrote:
Although I only changed freeradius binaries, I have installed multiple different versions of openssl and:
Don't do that.
I am afraid I have to. There exists packages which wants to use libssl1.x and packages which wants to use libssl3.
It's impossible to debug an issue if you change multiple things at the same time. Is the issue OpenSSL? FreeRADIUS? Or a configuration change in FreeRADIUS?
We don't know. And because it could be any one of those things, you'll have to track down exactly which change is the one that broke it.
So probably ssl3 hadles this differently (And probably I have no chance to debug it due to lack of knowledge :( )
You can install *one* OpenSSL package, and try that. You can ensure that FreeRADIUS 3.0.25 and 3.2.0 have the *same* configuration files.
As I wrote above - not on this machine. Moreover, as debian packages impose some kind of dependency (radius 3.0.25 => libssl1 ; radius 3.2 => libssl3, etc ) I suppose the only way to check if my suspicions are right is to compile radius 3.2 from source with libssl1 and check if it will works.
When you make random changes, it's impossible to figure out what went wrong.
I do not know if "aptitude safe-upgrade" is "random change" - in Debian world is the normal way of upgrading packages. And it mostly ( :) ) works.
The only way to fix is is a methodical approach. Change one thing at a time, test it, and repeat.
Of course. But it is good firstly identify thigh which might be changed during upgrade, I think. And then test them one-by-one. For now I am simply trying to narrow search area. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
On Jun 28, 2022, at 9:10 PM, Kamil Jońca <kjonca@op.pl> wrote:
I am afraid I have to. There exists packages which wants to use libssl1.x and packages which wants to use libssl3.
The FreeRADIUS packages should use only one version of OpenSSL.
As I wrote above - not on this machine. Moreover, as debian packages impose some kind of dependency (radius 3.0.25 => libssl1 ; radius 3.2 => libssl3, etc ) I suppose the only way to check if my suspicions are right is to compile radius 3.2 from source with libssl1 and check if it will works.
Yes.
Of course. But it is good firstly identify thigh which might be changed during upgrade, I think. And then test them one-by-one.
For now I am simply trying to narrow search area.
That is the way. Alan DeKok.
Alan DeKok <aland@deployingradius.com> writes:
On Jun 28, 2022, at 9:10 PM, Kamil Jońca <kjonca@op.pl> wrote:
I am afraid I have to. There exists packages which wants to use libssl1.x and packages which wants to use libssl3.
The FreeRADIUS packages should use only one version of OpenSSL. Why?
Sooner or later they *have* to migrate to ssl3. Newer radius version is (IMO) quite good reason to use newer library version . Of course we can imagine scenario: 1. upgrade radius package 2. wait 3. upgrade linking (ssl1.x -> ssl3) but I believe this needs more efforts from distribution folks. But I am not going to be distribution folks attorney. I simply understand their decision. Now I have find some time to compile radius against ssl1 and return with results (if anyone interested) and possibly issue bug to debian/ssl. For now I think we are done. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
On Jun 29, 2022, at 3:01 PM, Kamil Jońca <kjonca@op.pl> wrote:
The FreeRADIUS packages should use only one version of OpenSSL. Why?
What I mean is that you shouldn't install two versions of FreeRADIUS, each of which depends on different versions of OpenSSL. You should try to avoid installing multiple versions of OpenSSL on the same machine. This makes building from source more difficult, as it's hard to control which version of OpenSSL gets chosen by the compiler / linker, vs run-time linker. i don't mean that FreeRADIUS should only use OpenSSL 3. We support multiple versions of OpenSSL... just only one at a time. Alan DeKok.
Alan DeKok <aland@deployingradius.com> writes:
On Jun 29, 2022, at 3:01 PM, Kamil Jońca <kjonca@op.pl> wrote:
The FreeRADIUS packages should use only one version of OpenSSL. Why?
What I mean is that you shouldn't install two versions of FreeRADIUS, each of which depends on different versions of OpenSSL.
I don't. Dependency system enforces that only one freeradius version is installed in system. So for testing I continously upgraded downgraded.
You should try to avoid installing multiple versions of OpenSSL on the same machine.
I am afraid it is not quite my decision - I simply install distribution packages I need and theey install (via dependncies) ssl (and other libs). Finally i built freeradius debian package against ssl 1.1 and still no luck with my phone. :( Next step is to build radius from github sources to find if debian patches changes anything ... KJ -- http://wolnelektury.pl/wesprzyj/teraz/
W dniu 28.06.2022 o 15:04, Kamil Jońca pisze:
Matthew Newton <mcn@freeradius.org> writes:
On 28/06/2022 08:41, Kamil Jońca wrote:
Debian box with debian radius packages. There is old phone (Samsung Wave) which was configured to use PEAP0 to connect to wifi.
If it's an old phone you might want to check OpenSSL ciphers / TLS versions. That's the most likely.
I have some older devices and I have to enable some strange ciphers :(
Of course I can provide logs, but they are quite huge.
Please send logs of both. We don't have time to make random guesses.
Just from `freeradius -X` (not -xxx, -Xx, etc)
3.0.25 https://drive.google.com/file/d/1uswz1jQRyAE_J7b9tu8Hrf4HmZqkT0NW/view?usp=s... 3.2 https://drive.google.com/file/d/15ONVo-KrM0Mq6Jrwu0PlKBDFMKTBpDgX/view?usp=s...
KJ
From provided logs, it looks like not the client, but the server insists on degrading TLS to v1.0 in the handshake. Maybe trying with the wider range of acceptable TLS versions in eap module could solve the issue: tls_min_version = "1.0" tls_max_version = "1.3" FreeRadius 3.2.0 works perfectly for this range for eap-ttls performing tunnelled authentications and servicing clients capable of TLSv1.0, TLSv1.2 and TLSv1.3 methods. -- Marek Zarychta
participants (4)
-
Alan DeKok -
Kamil Jońca -
Marek Zarychta -
Matthew Newton