Connection issues with Android Marshmallow
Android users here who have upgraded to Marshmallow can no longer connect, even after I upgraded from freeradius-2.2.8 to freeradius-2.2.9. My server is RHEL6.4 with "OpenSSL 1.0.1e-fips 11 Feb 2013". We are using PEAP/EAP-MSCHAPv2.
From the radius server the connection seems to work fine. And our network guy says all looks fine from his view. For instance:
Oct 13 13:48:05 net3 radiusd[23302]: Login OK: [hm6] (from client wireless64a port 0 via TLS tunnel) Oct 13 13:48:05 net3 radiusd[23302]: Login OK: [hm6] (from client wireless64a port 13 cli 14-1a-a3-93-54-21) Time :2015-Oct-13, 13:48:05 CDT Severity :INFO Controller ID :10.64.76.100 Message :Client moved to associated state successfully. But as a user described: No error message, it just hangs and times out. I'll get "Authenticating..." and "Scanning..." for a while then it will just say Disconnected. I'm following https://code.google.com/p/android/issues/detail?id=188867 but am posting here in case ... I've attached a radius debug session of the android connection (that is not working for a user) as well as one for a connection with the user's ipad, which is working for the same user. They look quite the same to me. I've also attached a few config files - let me know if more would be useful. Thanks. Tod Sandman Sr. Systems Administrator Middleware Development & Integration Rice University
On Oct 15, 2015, at 1:28 PM, Tod A. Sandman <sandmant@rice.edu> wrote:
Android users here who have upgraded to Marshmallow can no longer connect, even after I upgraded from freeradius-2.2.8 to freeradius-2.2.9. My server is RHEL6.4 with "OpenSSL 1.0.1e-fips 11 Feb 2013". We are using PEAP/EAP-MSCHAPv2.
You should update your eap.conf to disable tls 1.2: eap { ... tls { ... disable_tlsv1_2= yes ... } } That will likely help. This feature was added for situations like this. :( And not documented because we hoped it was never needed.
But as a user described: No error message, it just hangs and times out. I'll get "Authenticating..." and "Scanning..." for a while then it will just say Disconnected.
Most supplicants give useless error messages. Alan DeKok.
Could SSL_export_keying_material be bust in the version of OpenSSL you're using? I'm noticing a pattern of "OpenSSL 1.0.1e-fips 11 Feb 2013". Cheers, Nick
On Oct 15, 2015, at 2:02 PM, Nick Lowe <nick.lowe@gmail.com> wrote:
Could SSL_export_keying_material be bust in the version of OpenSSL you're using?
I'm noticing a pattern of "OpenSSL 1.0.1e-fips 11 Feb 2013".
It works fine on my RHEL 6.7 box. lsb_release -i -r Distributor ID: RedHatEnterpriseServer Release: 6.7 openssl-1.0.1e-42.el6.x86_64 openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 It would be useful to have the output of eapol_test run against one of these servers. sudo yum install libnl3-devel openssl-devel make gcc cd /tmp/ curl https://raw.githubusercontent.com/FreeRADIUS/freeradius-server/v3.1.x/script... > ./eapol_test-build.sh chmod +x ./eapol_test-build.sh mkdir eapol_test wget https://raw.githubusercontent.com/FreeRADIUS/freeradius-server/v3.1.x/script... --output-document=./eapol_test/config_liunx ./eapol_test-build.sh # check it built ok wget https://raw.githubusercontent.com/FreeRADIUS/freeradius-server/v3.1.x/src/te... # Edit credentials in peap-mschapv2.conf $(./eapol_test-build.sh) -c./peap-mschapv2.conf -s<secret> -a<radius server ip> -Arran
Hi,
sudo yum install libnl3-devel openssl-devel make gcc cd /tmp/ curl https://raw.githubusercontent.com/FreeRADIUS/freeradius-server/v3.1.x/script... > ./eapol_test-build.sh chmod +x ./eapol_test-build.sh mkdir eapol_test wget https://raw.githubusercontent.com/FreeRADIUS/freeradius-server/v3.1.x/script... --output-document=./eapol_test/config_liunx
minor typo - should be config_linux :-)
$(./eapol_test-build.sh) -c./peap-mschapv2.conf -s<secret> -a<radius server ip>
works here with the eapol_test from GIT - wish it would print out a version....and have options to force it to use a particular TLS... does it?? ;) alan
and have options to force it to use a particular TLS... does it?? ;)
tls_disable_tlsv1_0=1 - disable use of TLSv1.0 tls_disable_tlsv1_1=1 - disable use of TLSv1.1 (a workaround for AAA servers that have issues interoperating with updated TLS version) tls_disable_tlsv1_2=1 - disable use of TLSv1.2 (a workaround for AAA servers that have issues interoperating with updated TLS version) -Arran
--On 15. Oktober 2015 16:42:47 -0400 Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
and have options to force it to use a particular TLS... does it?? ;)
tls_disable_tlsv1_0=1 - disable use of TLSv1.0 tls_disable_tlsv1_1=1 - disable use of TLSv1.1 (a workaround for AAA servers that have issues interoperating with updated TLS version) tls_disable_tlsv1_2=1 - disable use of TLSv1.2 (a workaround for AAA servers that have issues interoperating with updated TLS version)
I hope this isn't a dumb question ... I (successfully) tried eapol_test on a RHEL 6 system with OpenSSL openssl-1.0.1e-42.el6.x86_64 and FreeRadius 3.0.10 and was surprised that I didn't see TLSv1... at all. Here are all the lines referencing TLS: TLS: Phase2 EAP types - hexdump(len=8): 00 00 00 00 1a 00 00 00 TLS: using phase1 config options SSL: TLS Message Length: 5263 TLS: tls_verify_cb - preverify_ok=1 err=19 (self signed certificate in certificate chain) ca_cert_verify=0 depth=3 buf='/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2' TLS: tls_verify_cb - preverify_ok=1 err=19 (self signed certificate in certificate chain) ca_cert_verify=0 depth=3 buf='/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2' TLS: tls_verify_cb - preverify_ok=1 err=19 (self signed certificate in certificate chain) ca_cert_verify=0 depth=2 buf='/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01' TLS: tls_verify_cb - preverify_ok=1 err=19 (self signed certificate in certificate chain) ca_cert_verify=0 depth=1 buf='/C=DE/L=Koeln/O=Universitaet zu Koeln/CN=UniKoeln CA/emailAddress=camaster@uni-koeln.de' TLS: tls_verify_cb - preverify_ok=1 err=19 (self signed certificate in certificate chain) ca_cert_verify=0 depth=0 buf='/C=DE/ST=Nordrhein-Westfalen/L=Koeln/O=Universitaet zu Koeln/OU=Zentrum fuer Angewandte Informatik/CN=radius1.rrz.uni-koeln.de' EAP-PEAP: TLS done, proceed to Phase 2 Everything else looks like SSLv3: SSL: SSL_connect:SSLv2/v3 write client hello A SSL: SSL_connect:error in SSLv2/v3 read server hello A SSL: SSL_connect:SSLv3 read server hello A SSL: SSL_connect:SSLv3 read server certificate A SSL: SSL_connect:SSLv3 read server key exchange A SSL: SSL_connect:SSLv3 read server done A SSL: SSL_connect:SSLv3 write client key exchange A SSL: SSL_connect:SSLv3 write change cipher spec A SSL: SSL_connect:SSLv3 write finished A SSL: SSL_connect:SSLv3 flush data SSL: SSL_connect:error in SSLv3 read finished A SSL: SSL_connect:error in SSLv3 read finished A SSL: SSL_connect:SSLv3 read finished A What's going on there? -- .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:. .:.Regionales Rechenzentrum (RRZK).:. .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.
On Oct 16, 2015, at 9:29 AM, Sebastian Hagedorn <Hagedorn@uni-koeln.de> wrote:
I hope this isn't a dumb question ... I (successfully) tried eapol_test on a RHEL 6 system with OpenSSL openssl-1.0.1e-42.el6.x86_64 and FreeRadius 3.0.10 and was surprised that I didn't see TLSv1... at all.
OpenSSL is pretty stingy in the information it gives to the application. FreeRADIUS also doesn't print out everything it can. We've fixed this in the v3.1.x branch, so it's clearer and more verbose.
What's going on there?
Debug messages aren't printing the TLS versions. It's OK. Alan DeKok.
On Oct 16, 2015, at 9:34 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 16, 2015, at 9:29 AM, Sebastian Hagedorn <Hagedorn@uni-koeln.de> wrote:
I hope this isn't a dumb question ... I (successfully) tried eapol_test on a RHEL 6 system with OpenSSL openssl-1.0.1e-42.el6.x86_64 and FreeRadius 3.0.10 and was surprised that I didn't see TLSv1... at all.
OpenSSL is pretty stingy in the information it gives to the application. FreeRADIUS also doesn't print out everything it can.
Yeah in this case those strings are coming from OpenSSL *sigh*. Even 'SSL negotiation finished successfully' comes from OpenSSL. I've made it a bit better: Fri Oct 16 12:41:21 2015 : Debug: (124) eap_peap: >>> send handshake [length 16], finished Fri Oct 16 12:41:21 2015 : Debug: (124) eap_peap: TLS Accept: SSLv3 write finished A Fri Oct 16 12:41:21 2015 : Debug: (124) eap_peap: TLS Accept: SSLv3 flush data Fri Oct 16 12:41:21 2015 : Debug: (124) eap_peap: SSL negotiation finished successfully Fri Oct 16 12:41:21 2015 : Debug: (124) eap_peap: TLS established with cipher suite: ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD Fri Oct 16 12:41:21 2015 : Debug: (124) eap_peap: [eaptls process] = handled Fri Oct 16 12:41:21 2015 : Debug: (124) eap: Sending EAP Request (code 1) ID 6 length 57 At least now you can check the protocol version in the cipher to be sure. Again OpenSSL provides the string, which is why there's the random whitespace :( -Arran
Hi,
Fri Oct 16 12:41:21 2015 : Debug: (124) eap_peap: TLS established with cipher suite: ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
Again OpenSSL provides the string, which is why there's the random whitespace :(
yep. same output as you see from the ciphers command...white space there same: openssl ciphers -v "AES+aRSA+SHA256:-DH" AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 scarey thing..do that on latest OSX (El Capitan) and no cipher available. what? ah.... now I see... OpenSSL 0.9.8zg 14 July 2015 really??????? :/ alan
It would be useful to have the output of eapol_test run against one of these servers.
I configured my desktop as a radius client, followed your instructions and built eapol_test on my desktop (RHEL6.7, openssl-1.0.1e-42.el6.x86_64). Attached is the output of eapol_test (which fails) along with my peap-mschapv2.conf. rb3:/var/tmp/radius: $(./eapol_test-build.sh) -c./peap-mschapv2.conf -ssecret -a10.137.93.19 > /tmp/OUT BTW, I doubt this matters, but I built freeradius an a RHEL6.4 box running an older version of openssl (openssl-1.0.0-27.el6_4.2.x86_64) than on the radius server. I -think- it's all dynamically linked and this shouldn't matter.
PMK from EAPOL - hexdump(len=32): 3c b8 d0 48 da 43 4d 75 f4 24 2f 1a 4f 8a 86 68 c6 8c e6 fb a0 e0 79 3d 80 0e 38 70 23 68 51 37 WARNING: PMK mismatch PMK from AS - hexdump(len=32): 46 c2 64 36 05 33 22 a3 3c 28 55 10 79 ba 77 0b de 88 ac bd 7f 1c 47 89 2b 7a 18 a4 da d0 d0 e4
My suggestion would be to get OpenSSL updated therefore and to try again. Are you able to update to RHEL 6.7? Nick
Are you able to update to RHEL 6.7?
Not at the moment. Our radius servers are also our campus DNS and DHCP servers. All the more reason to keep them updated, but round here ....
My suggestion would be to get OpenSSL updated therefore and to try again.
Last night I built freeradius-2.2.9 on a RHEL6.4 box with openssl-1.0.1e-42.el6.x86_64. So my build openssl went from openssl-1.0.0-27.el6_4.2.x86_64 -> openssl-1.0.1e-42.el6.x86_64 I also upgraded openssl on the radius server: openssl-1.0.1e-16.el6_5.7.x86_64 -> openssl-1.0.1e-42.el6.x86_64 This morning I tried to fire up the new radius build on one of the radius servers but ran into the openssl check: Oct 16 06:41:31 net3 radiusd[5251]: Refusing to start with libssl version OpenSSL 1.0.1e-fips 11 Feb 2013 (in range 1.0.1 - 1.0.1f). Security advisory CVE-2014-0160 (Heartbleed) Oct 16 06:41:31 net3 radiusd[5251]: For more information see http://heartbleed.com I recall we updated to openssl months ago due to heartbleed and am surprised an update of that update has re-introduced it. I'm also surprised "openssl version" shows the same string for both openssl-1.0.1e-16.el6_5.7.x86_64 and openssl-1.0.1e-42.el6.x86_64: root@net4:/etc/opt/freeradius> rpm -qf /usr/bin/openssl openssl-1.0.1e-16.el6_5.7.x86_64 root@net4:/etc/opt/freeradius> /usr/bin/openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 root@net3:/opt/opt.CORE> rpm -qf /usr/bin/openssl openssl-1.0.1e-42.el6.x86_64 root@net3:/opt/opt.CORE> /usr/bin/openssl version OpenSSL 1.0.1e-fips 11 Feb 2013
You need to put allow_vulnerable_openssl in radiusd.conf
Thanks so much. It makes sense now: Redhat patches openssl to fix the security bugs, but the openssl "version" is never updated. Even my RHEL7 boxes show the same old veriosn: ds3:/home/sandmant: cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.1 (Maipo) ds3:/home/sandmant: openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 But dang, for now I lost my little window to test ... Tod Sandman Sr. Systems Administrator Middleware Development & Integration Rice University Voice: 713.348.5816
On Oct 16, 2015, at 8:56 AM, Tod A. Sandman <sandmant@rice.edu> wrote:
You need to put allow_vulnerable_openssl in radiusd.conf
Thanks so much. It makes sense now: Redhat patches openssl to fix the security bugs, but the openssl "version" is never updated.
And there's no way to ask OpenSSL if it's vulnerable to the heartbeat attack. Ugh. Alan DeKok.
Hi,
Oct 16 06:41:31 net3 radiusd[5251]: Refusing to start with libssl version OpenSSL 1.0.1e-fips 11 Feb 2013 (in range 1.0.1 - 1.0.1f). Security advisory CVE-2014-0160 (Heartbleed) Oct 16 06:41:31 net3 radiusd[5251]: For more information see http://heartbleed.com
yes - if you run in full debug mode you will see exactly what you need to do to fix this...as long as you know you are patched, go to radiusd.conf, visit the security {} section and put/edit the allow_vulnerable_ssl = 'xxxxxxx' where xxxxx is the CVE code as printed in the debug output
I'm also surprised "openssl version" shows the same string for both openssl-1.0.1e-16.el6_5.7.x86_64 and openssl-1.0.1e-42.el6.x86_64:
exactly. thats the problem...the vendors are backporting things to older versions rather then upgrading the version provided alan
On Oct 16, 2015, at 8:54 AM, A.L.M.Buxey@lboro.ac.uk wrote:
exactly. thats the problem...the vendors are backporting things to older versions rather then upgrading the version provided
Because OpenSSL changes their API in minor minor versions of the software. So binaries build for version X will break with version X+1. It's retarded. For FreeRADIUS, we've put extra work in to make sure this doesn't happen. When we change the API, we also bump the version number. And then server core checks for version incompatibilities, and refuses to start if you're mixing incompatible binaries and libraries. Because we want our users to be happy. Unlike OpenSSL. Alan DeKok.
On Oct 16, 2015, at 9:44 AM, A.L.M.Buxey@lboro.ac.uk wrote:
you know...I get the feeling you dont like OpenSSL much... ;-)
Their API is needlessly complicated. Their code is *horrific*. They break compatibility and don't seem to care. We use them because everything else is worse. :( Alan DeKok.
Hi Am 16.10.2015 um 16:31 schrieb Alan DeKok:
On Oct 16, 2015, at 10:29 AM, A.L.M.Buxey@lboro.ac.uk wrote:
We use them because everything else is worse. :(
LibreSSL ? :-)
It's API compatible with OpenSSL, and it doesn't add new / better APIs.
Concerning a new / better API in LibreSSL: The OpenBSD folks have the same / similar concerns bout the OpenSSL API. True, they have libssl for backwards-compatibility but have added a new libtls library trying to address these concerns. Their goal is to provide more simple API where an application can ask for a secure channel and libtls will do the reset - no need for the application to know and handle the gory details about TLS version etc. - that's their actual motivation. OpenBSD has started using libtls in tools of their base system for what I know and LibreSSL has become portable for quite some time. Information about libtls can be found on the libressl.org project page and there's been a fairly recent talk from Bob Beck in September. The slides can be found on openbsd.org/papers -- Mathieu
On Oct 16, 2015, at 11:15 AM, Mathieu Simon (Lists) <matsimon.lists@simweb.ch> wrote:
Hi
Am 16.10.2015 um 16:31 schrieb Alan DeKok:
On Oct 16, 2015, at 10:29 AM, A.L.M.Buxey@lboro.ac.uk wrote:
We use them because everything else is worse. :(
LibreSSL ? :-)
It's API compatible with OpenSSL, and it doesn't add new / better APIs.
Concerning a new / better API in LibreSSL: The OpenBSD folks have the same / similar concerns bout the OpenSSL API. True, they have libssl for backwards-compatibility but have added a new libtls library trying to address these concerns.
Their goal is to provide more simple API where an application can ask for a secure channel and libtls will do the reset - no need for the application to know and handle the gory details about TLS version etc. - that's their actual motivation. OpenBSD has started using libtls in tools of their base system for what I know and LibreSSL has become portable for quite some time.
We can't use it. All the functions it provides assume I/O over a file descriptor. We don't use file descriptors for EAP, we use record buffers. -Arran
On Oct 16, 2015, at 1:01 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Oct 16, 2015, at 11:15 AM, Mathieu Simon (Lists) <matsimon.lists@simweb.ch> wrote:
Hi
Am 16.10.2015 um 16:31 schrieb Alan DeKok:
On Oct 16, 2015, at 10:29 AM, A.L.M.Buxey@lboro.ac.uk wrote:
We use them because everything else is worse. :(
LibreSSL ? :-)
It's API compatible with OpenSSL, and it doesn't add new / better APIs.
Concerning a new / better API in LibreSSL: The OpenBSD folks have the same / similar concerns bout the OpenSSL API. True, they have libssl for backwards-compatibility but have added a new libtls library trying to address these concerns.
Their goal is to provide more simple API where an application can ask for a secure channel and libtls will do the reset - no need for the application to know and handle the gory details about TLS version etc. - that's their actual motivation. OpenBSD has started using libtls in tools of their base system for what I know and LibreSSL has become portable for quite some time.
We can't use it. All the functions it provides assume I/O over a file descriptor. We don't use file descriptors for EAP, we use record buffers.
It also makes the protocol progression completely opaque, there's no way to see what state the TLS session is in, which I believe is needed for the EAP-TLS code to function (i'm still working through that mess). It would also break all the session caching code we added, because again, no visibility into that, and no session serialization/deserialization functions. I would *LOVE* a better TLS library, but libtls isn't it, it's a lobotomized (though admittedly, slightly more consistent) version of the OpenSSL API. Great if you want to write a web server, useless if you need anything more complicated. -Arran
Fair enough. It's too opaque and doesn't give you the access to state and other low level info you need. alan
Arran Cudbard-Bell wrote:
I would *LOVE* a better TLS library,
I'm not a C programmer but it seems mbed TLS (formerly known as PolarSSL) received some good reputation. https://github.com/ARMmbed/mbedtls/blob/development/LICENSE Ciao, Michael.
I was able try my new radius build (freeradius-2.2.9 with openssl-1.0.1e-42 on both build host and radius server) with "allow_vulnerable_openssl = yes". eapol_test now succeeds (MPPE keys OK: 1 mismatch: 0), one Marshmallow user has responded "it's working!", and I do not see any signs of other issues. Thanks so much. Tod Sandman Sr. Systems Administrator Middleware Development & Integration Rice University Voice: 713.348.5816
Hi Yes. We've had no problems with marshmallow clients with 2.2.9 and openssl 1.0.1e (latest -42 rpm). Also note that they also worked on 2.2.8 in the same environment! alan
On Oct 16, 2015, at 1:46 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi
Yes. We've had no problems with marshmallow clients with 2.2.9 and openssl 1.0.1e (latest -42 rpm). Also note that they also worked on 2.2.8 in the same environment!
Using PEAP or EAP-TLS right? That was fixed in 2.2.7. Only TTLS requires 2.2.9. -Arran
Hi,
Yes. We've had no problems with marshmallow clients with 2.2.9 and openssl 1.0.1e (latest -42 rpm). Also note that they also worked on 2.2.8 in the same environment!
Using PEAP or EAP-TLS right? That was fixed in 2.2.7. Only TTLS requires 2.2.9.
yes, EAP-TLS and PEAP were tested....we support EAP-TTLS/MSCHAPv2 and EAP-TTLS/(EAP-MSCHAPv2/MSCHAPv2) too so all the 2.2.x servers are now 2.2.9 - happened to be reading http://freeradius.org/press/index.html#2.2.9 when your email arrived and noted "Update EAP-TLS methods for TLSv1.2" was 2.2.7 - thought it was 2.2.9 too... 2.2.9 was all about MPPE key stuff for TTLS alan
On Oct 15, 2015, at 4:49 PM, Tod A. Sandman <sandmant@rice.edu> wrote:
It would be useful to have the output of eapol_test run against one of these servers.
I configured my desktop as a radius client, followed your instructions and built eapol_test on my desktop (RHEL6.7, openssl-1.0.1e-42.el6.x86_64). Attached is the output of eapol_test (which fails) along with my peap-mschapv2.conf.
rb3:/var/tmp/radius: $(./eapol_test-build.sh) -c./peap-mschapv2.conf -ssecret -a10.137.93.19 > /tmp/OUT
BTW, I doubt this matters, but I built freeradius an a RHEL6.4 box running an older version of openssl (openssl-1.0.0-27.el6_4.2.x86_64) than on the radius server. I -think- it's all dynamically linked and this shouldn't matter.
Ahhhh! It does! Firstly, never do that, OpenSSL is infamous for ABI compatibility issues. Secondly it really does in this case, as the checks for whether to use SSL_export_keying_material are done at compile time, not run time. OpenSSL < 1.0.1 doesn't support TLS 1.2, and doesn't have the SSL_export_keying_material. #if OPENSSL_VERSION_NUMBER >= 0x10001000L if (SSL_export_keying_material(s, out, sizeof(out), prf_label, prf_size, NULL, 0, 0) != 1) { ERROR("Failed generating keying material"); return; } #else { uint8_t seed[64 + (2 * SSL3_RANDOM_SIZE)]; uint8_t buf[4 * EAPTLS_MPPE_KEY_LEN]; p = seed; memcpy(p, prf_label, prf_size); p += prf_size; memcpy(p, s->s3->client_random, SSL3_RANDOM_SIZE); p += SSL3_RANDOM_SIZE; prf_size += SSL3_RANDOM_SIZE; memcpy(p, s->s3->server_random, SSL3_RANDOM_SIZE); prf_size += SSL3_RANDOM_SIZE; PRF(s->session->master_key, s->session->master_key_length, seed, prf_size, out, buf, sizeof(out)); } #endif This is precisely why it's not working on your system, you need to build and deploy with the same version of OpenSSL. -Arran
Arran, For all our sanity, can you not just mandate OpenSSL 1.0.1 or later for FreeRADIUS builds? Explicitly break the build if it's older. Nick
On Oct 15, 2015, at 5:09 PM, Nick Lowe <nick.lowe@gmail.com> wrote:
Arran,
For all our sanity, can you not just mandate OpenSSL 1.0.1 or later for FreeRADIUS builds?
Explicitly break the build if it's older.
We *HAD* sanity checks to *PREVENT* the server from starting if the build time OpenSSL was a different version to the runtime SSL. But these were removed by commit 767c67fc4f2f673a44f89794a3531158dcb7b1ec. This patch was not developed internally, but was contributed by RedHat. We agreed to disable the vulnerability checks to help RHEL with patching OpenSSL vulnerabilities, we did NOT agree to disable the version sanity checks FOR PRECISELY THIS REASON. -Arran
Ah! That explains it. Thought there was protection against running server on another box that had a different openssl version! alan
On 15 ott 2015, at 19:58, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 15, 2015, at 1:28 PM, Tod A. Sandman <sandmant@rice.edu> wrote:
Android users here who have upgraded to Marshmallow can no longer connect, even after I upgraded from freeradius-2.2.8 to freeradius-2.2.9. My server is RHEL6.4 with "OpenSSL 1.0.1e-fips 11 Feb 2013". We are using PEAP/EAP-MSCHAPv2.
You should update your eap.conf to disable tls 1.2:
eap { ... tls { ... disable_tlsv1_2= yes ... } }
That will likely help.
This feature was added for situations like this. :( And not documented because we hoped it was never needed.
Well done anyway ! They say "Better safe than sorry”. Alan is this undocumented rule available also in FR 3.x ?
But as a user described: No error message, it just hangs and times out. I'll get "Authenticating..." and "Scanning..." for a while then it will just say Disconnected.
Most supplicants give useless error messages.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------------------------------------------------------------------------ Paolo Barbato Consorzio RFX corso Stati Uniti,4 35127 Padova - Italy Network Administrator phone: +39 049 8295097 fax: +39 049 8700718 ------------------------------------------------------------------------------------------------
On Oct 15, 2015, at 2:31 PM, Paolo Barbato <paolo.barbato@igi.cnr.it> wrote:
On 15 ott 2015, at 19:58, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 15, 2015, at 1:28 PM, Tod A. Sandman <sandmant@rice.edu> wrote:
Android users here who have upgraded to Marshmallow can no longer connect, even after I upgraded from freeradius-2.2.8 to freeradius-2.2.9. My server is RHEL6.4 with "OpenSSL 1.0.1e-fips 11 Feb 2013". We are using PEAP/EAP-MSCHAPv2.
You should update your eap.conf to disable tls 1.2:
eap { ... tls { ... disable_tlsv1_2= yes ... } }
That will likely help.
This feature was added for situations like this. :( And not documented because we hoped it was never needed.
Well done anyway ! They say "Better safe than sorry”.
Alan is this undocumented rule available also in FR 3.x ?
Yes, and v3.1.x too. -Arran
Hi,
I've attached a radius debug session of the android connection (that is not working for a user) as well as one for a connection with the user's ipad, which is working for the same user. They look quite the same to me. I've also attached a few config files - let me know if more would be useful.
note: Sending Access-Accept packet to host 10.64.76.100 port 32770, id=236, length=0 the RADIUS server has done its job. the client has talked to the server..no TLS issues, no DH or certificate issues. so the problem appears to be elsewhere.... alan
On Oct 15, 2015, at 3:15 PM, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
I've attached a radius debug session of the android connection (that is not working for a user) as well as one for a connection with the user's ipad, which is working for the same user. They look quite the same to me. I've also attached a few config files - let me know if more would be useful.
note: Sending Access-Accept packet to host 10.64.76.100 port 32770, id=236, length=0
the RADIUS server has done its job. the client has talked to the server..no TLS issues, no DH or certificate issues. so the problem appears to be elsewhere....
In this case it's a bit trickier. Authentication will appear to succeed and the MPPE keys will look valid, but wpa_supplicant/eapol_test will derive different values and report a mismatch. You can't really verify correct behaviour just from the RADIUS server logs, you need to test with eapol_test/wpa_supplicant or get debugging logs which have the output of wpa_supplicant, off of the android device. -Arran
Indeed, we need to get to the bottom of is the MSK derived in the same way by AP and STA. RHEL 6.4 was mentioned which is obsolete and out of all support from Red Hat. Are there patch differences that could cause this between 6.4 and newer RHEL 6 releases that remain in support? Nick
Hi,
RHEL 6.4 was mentioned which is obsolete and out of all support from Red Hat.
Are there patch differences that could cause this between 6.4 and newer RHEL 6 releases that remain in support?
well, I've got a 2.2.9 box here with openssl 1.0.1e-FIP 2013.... this is CentOS 6.7 and the RPM is openssl-1.0.1e-42.el6.x86_64 (the important part there is the -42 package release). the changelog can be obtained by rpm -q --changelog openssl alan
hi, i'm particularly interested in this entry on the google bugs: "Same here, I couldn't connect to our eduroam network (PEAP+MSCHAPv2) with any of the previous Android M previews or the current MRA58K build on my Nexus 5. When trying to connect I can't go beyond the "Authenticating" step. " so were these "with any of the previous Android M previews or the current MRA58K" reported to Google. did Google do anything to follow this up? IOS 9 pre-GM was known to have this issue with TLS1.2 and it was pulled for the GM release.... but only as a rest-bite - a future point release of IOS9 is said to have it back in - give sites/systems a few months to fix things... i expect it will be a nice christmas present for admins who havent upgraded by end of december... alan
participants (10)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan Buxey
-
Alan DeKok -
Arran Cudbard-Bell -
Mathieu Simon (Lists) -
Michael Ströder -
Nick Lowe -
Paolo Barbato -
Sebastian Hagedorn -
Tod A. Sandman