FreeRadius and OpenSSL 1.0.2
I am testing FreeRadius with OpenSSL 1.0.2 and noticed a strange issue. TTLS-MSCHAPv2 fails. PEAP and TTLS-(PAP, CHAP, MSCHAPv1) all work. The error that stands out is 'Invalid ACK received: 0'. I get this on both 2.2.6 and 3.0.7. 2.2.6 Mon Mar 23 08:40:09 2015 : Info: [ttls] Authenticate Mon Mar 23 08:40:09 2015 : Info: [ttls] processing EAP-TLS Mon Mar 23 08:40:09 2015 : Info: [ttls] Received TLS ACK Mon Mar 23 08:40:09 2015 : Info: [ttls] ACK default Mon Mar 23 08:40:09 2015 : Error: [ttls] Invalid ACK received: 0 Mon Mar 23 08:40:09 2015 : Info: [ttls] eaptls_verify returned 4 Mon Mar 23 08:40:09 2015 : Info: [ttls] eaptls_process returned 4 3.0.7 Mon Mar 23 09:14:26 2015 : Debug: (21) eap_ttls: Authenticate Mon Mar 23 09:14:26 2015 : Debug: (21) eap_ttls: processing EAP-TLS Mon Mar 23 09:14:26 2015 : Debug: (21) eap_ttls: Received TLS ACK Mon Mar 23 09:14:26 2015 : Debug: (21) eap_ttls: Received TLS ACK Mon Mar 23 09:14:26 2015 : ERROR: (21) eap_ttls: Invalid ACK received: 0 Mon Mar 23 09:14:26 2015 : Debug: (21) eap_ttls: eaptls_verify returned 0 Mon Mar 23 09:14:26 2015 : Debug: (21) eap_ttls: eaptls_process returned 0 Mon Mar 23 09:14:26 2015 : ERROR: (21) eap: Failed continuing EAP TTLS (21) session. EAP sub-module failed Downgrading openssl to 1.0.1 and the issue goes away. 2.2.6 Mon Mar 23 08:50:40 2015 : Info: [ttls] Authenticate Mon Mar 23 08:50:40 2015 : Info: [ttls] processing EAP-TLS Mon Mar 23 08:50:40 2015 : Info: [ttls] Received TLS ACK Mon Mar 23 08:50:40 2015 : Info: [ttls] ACK handshake is finished Mon Mar 23 08:50:40 2015 : Info: [ttls] eaptls_verify returned 3 Mon Mar 23 08:50:40 2015 : Info: [ttls] eaptls_process returned 3 3.0.7 Mon Mar 23 09:17:54 2015 : Debug: (29) eap_ttls: Authenticate Mon Mar 23 09:17:54 2015 : Debug: (29) eap_ttls: processing EAP-TLS Mon Mar 23 09:17:54 2015 : Debug: (29) eap_ttls: Received TLS ACK Mon Mar 23 09:17:54 2015 : Debug: (29) eap_ttls: Received TLS ACK Mon Mar 23 09:17:54 2015 : Debug: (29) eap_ttls: ACK handshake is finished Mon Mar 23 09:17:54 2015 : Debug: (29) eap_ttls: eaptls_verify returned 3 Mon Mar 23 09:17:54 2015 : Debug: (29) eap_ttls: eaptls_process returned 3 This was tested with the default configuration and adding a user to the users file. The OS was FreeBSD 10.1. I assuming this a problem with the FreeBSD's OpenSSL 1.0.2 port but wanted to ask if anybody else has seen issues with the latest OpenSSL version? -- Dave
On Mar 23, 2015, at 10:20 AM, Dave Duchscher <daved@nostrum.com> wrote:
I am testing FreeRadius with OpenSSL 1.0.2 and noticed a strange issue. TTLS-MSCHAPv2 fails. PEAP and TTLS-(PAP, CHAP, MSCHAPv1) all work. The error that stands out is 'Invalid ACK received: 0'. I get this on both 2.2.6 and 3.0.7.
2.2.6 Mon Mar 23 08:40:09 2015 : Info: [ttls] Authenticate Mon Mar 23 08:40:09 2015 : Info: [ttls] processing EAP-TLS Mon Mar 23 08:40:09 2015 : Info: [ttls] Received TLS ACK Mon Mar 23 08:40:09 2015 : Info: [ttls] ACK default Mon Mar 23 08:40:09 2015 : Error: [ttls] Invalid ACK received: 0
Ug. That’s ContentType 0. See http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-para... It’s unassigned. Why the heck is the client sending that?
I assuming this a problem with the FreeBSD's OpenSSL 1.0.2 port but wanted to ask if anybody else has seen issues with the latest OpenSSL version?
Nope. Alan DeKok.
On Mar 23, 2015, at 12:10 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 23, 2015, at 10:20 AM, Dave Duchscher <daved@nostrum.com> wrote:
I am testing FreeRadius with OpenSSL 1.0.2 and noticed a strange issue. TTLS-MSCHAPv2 fails. PEAP and TTLS-(PAP, CHAP, MSCHAPv1) all work. The error that stands out is 'Invalid ACK received: 0'. I get this on both 2.2.6 and 3.0.7.
2.2.6 Mon Mar 23 08:40:09 2015 : Info: [ttls] Authenticate Mon Mar 23 08:40:09 2015 : Info: [ttls] processing EAP-TLS Mon Mar 23 08:40:09 2015 : Info: [ttls] Received TLS ACK Mon Mar 23 08:40:09 2015 : Info: [ttls] ACK default Mon Mar 23 08:40:09 2015 : Error: [ttls] Invalid ACK received: 0
Ug. That’s ContentType 0. See http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-para...
It’s unassigned. Why the heck is the client sending that?
This was from eapol_test from wpa_supplicant. Not sure of the version. I pulled down wpa_supplicant 2.4 and the issue has disappeared. Weird that it showed up with the newer version of openssl. My apologies for the noise.
I assuming this a problem with the FreeBSD's OpenSSL 1.0.2 port but wanted to ask if anybody else has seen issues with the latest OpenSSL version?
Nope.
-- Dave
participants (2)
-
Alan DeKok -
Dave Duchscher