aims team mailing list archive
-
aims team
-
Mailing list archive
-
Message #01720
[Bug 1104476] Re: Network manager cannot connect to WPA2/PEAP/MSCHAPv2 enterprise wifi networks without CA_Certificate, like Eduroam
Launchpad has imported 37 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=1241930.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2015-07-10T12:50:50+00:00 Kevin wrote:
Description of problem: After updating to wpa_supplicant 2.4-3 on July
1, was unable to connect to my corporate wifi access point. Subsequent
downgrade to wpa_supplicant 2.3-3 fixed access problem, so I think this
is a wpa_supplicant bug
Version-Release number of selected component (if applicable): wpa_supplicant 2.4-3
How reproducible: Upgrade to 2.4-3 try to access wpa/wpa2 wifi with TTLS authentication that has been working for well over a year now. Fails. Downgrade to 2.3-3 and it works again.
Steps to Reproduce: See above
1. Select network in NetworkManager
2. Does not connect
3. Keeps asking for password
Actual results:
>From /etc/wpa_supplicant.log after upgrade:
wlp12s0: SME: Trying to authenticate with e0:1c:41:34:19:e9 (SSID='CICS' freq=5220 MHz)
wlp12s0: Trying to associate with e0:1c:41:34:19:e9 (SSID='CICS' freq=5220 MHz)
wlp12s0: Associated with e0:1c:41:34:19:e9
wlp12s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=US
wlp12s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp12s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlp12s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authori
ty' hash=c3846bf24b9e93ca64274c0ec67c1ecc5e024ffcacd2d74019350e81fe546ae4
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authori
ty' hash=c3846bf24b9e93ca64274c0ec67c1ecc5e024ffcacd2d74019350e81fe546ae4
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.g
odaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287' hash=09ed6e991fc3273d8fea317d339c0204
1861973549cfa6e1558f411f11211aa3
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/OU=Domain Control Validated/CN=cicsnc.org' hash=598c9bcc63d9e114262181d14
dfed5372381b7ae0eb762e701b689b0e309f9b7
wlp12s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:cicsnc.org
wlp12s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:www.cicsnc.org
wlp12s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:osx.cicsnc.org
wlp12s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:osx2.cicsnc.org
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
OpenSSL: openssl_handshake - SSL_connect error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
wlp12s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
wlp12s0: Authentication with e0:1c:41:34:19:e9 timed out.
wlp12s0: CTRL-EVENT-DISCONNECTED bssid=e0:1c:41:34:19:e9 reason=3 locally_generated=1
wlp12s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="CICS" auth_failures=1 duration=10 reason=AUTH_FAILED
wlp12s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="CICS" auth_failures=2 duration=35 reason=CONN_FAILED
After downgrade:
wlp12s0: Trying to associate with e0:1c:41:34:19:e9 (SSID='CICS' freq=5220 MHz)
wlp12s0: Associated with e0:1c:41:34:19:e9
wlp12s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp12s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=US
wlp12s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlp12s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authori
ty'
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authori
ty'
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.g
odaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287'
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/OU=Domain Control Validated/CN=cicsnc.org'
EAP-MSCHAPV2: Authentication succeeded
wlp12s0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
wlp12s0: WPA: Key negotiation completed with e0:1c:41:34:19:e9 [PTK=CCMP GTK=CCMP]
wlp12s0: CTRL-EVENT-CONNECTED - Connection to e0:1c:41:34:19:e9 completed [id=0 id_str=]
wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-62 noise=9999 txrate=6000
wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-59 noise=9999 txrate=81000
wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-67 noise=9999 txrate=135000
wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-59 noise=9999 txrate=6000
wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-67 noise=9999 txrate=121500
wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-61 noise=9999 txrate=135000
wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-67 noise=9999 txrate=6000
wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-61 noise=9999 txrate=6000
wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-67 noise=9999 txrate=135000
Expected results: The latter results are expected
Additional info: PEAP, TLS, other authentication protocols produced the same ssl handshake error (dh key too small). "No CA required" was checked in NetworkManager in both cases, but I'm not sure if I snipped out the right part of the wpa_supplicant log in the failure case--I was trying everything. The SSL handshake failure was consistent under all attempts to authenticate no matter what drop downs/boxes were selected in NetworkManager under 2.4-3. Now that I have it working, I am loathe to break it again.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/203
------------------------------------------------------------------------
On 2015-07-16T00:07:26+00:00 Wallace wrote:
I'm using Fedora 22.
After updating the package wpa_supplicant 2.3 to 2.4 can not connect to the wireless network (PEAP-MSCHAPv2, no CA Certificate).
Please see this thead http://community.arubanetworks.com/t5/Unified-
Wired-Wireless-Access/Internal-radius-server-incompatibility-with-the-
new-wpa/td-p/236602
After downgrade to 2.3 it works again.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/204
------------------------------------------------------------------------
On 2015-07-17T13:15:18+00:00 Major wrote:
I ran through a git bisect this morning and found that once this patch
was applied, I couldn't hop on my corporate Aruba wifi network:
https://w1.fi/cgit/hostap/commit/?id=674f6c073f6f7cd9e04e5f117710f03d5e09ad63
_______________________________________________
commit 674f6c073f6f7cd9e04e5f117710f03d5e09ad63
Author: Eliad Peller <eliad@xxxxxxxxxx>
Date: Wed Oct 22 08:03:56 2014 -0400
WMM AC: Add basic ADDTS/DELTS sending functions
Add basic implementation for ADDTS and DELTS sending
functions.
wpas_wmm_ac_addts() will send ADDTS request public action,
containing TSPEC (traffic stream specification) with
the given params.
wpas_wmm_ac_delts() will look for the saved tspec with
the given tid, and send DELTS public action for it.
(Handling of ADDTS response and actually configuring the admission
control params will be added in following patches.)
Signed-off-by: Moshe Benji <moshe.benji@xxxxxxxxx>
Signed-off-by: Eliad Peller <eliad@xxxxxxxxxx>
_______________________________________________
A simple 'git revert' was insufficient as additional patches have piled
into these same files afterwards. :/
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/205
------------------------------------------------------------------------
On 2015-07-17T15:11:22+00:00 Dan wrote:
(In reply to Kevin Havener from comment #0)
> Description of problem: After updating to wpa_supplicant 2.4-3 on July 1,
> was unable to connect to my corporate wifi access point. Subsequent
> downgrade to wpa_supplicant 2.3-3 fixed access problem, so I think this is a
> wpa_supplicant bug
>
>
> Version-Release number of selected component (if applicable): wpa_supplicant
> 2.4-3
>
>
> How reproducible: Upgrade to 2.4-3 try to access wpa/wpa2 wifi with TTLS
> authentication that has been working for well over a year now. Fails.
> Downgrade to 2.3-3 and it works again.
This appears to be an OpenSSL issue, not a wpa_supplicant one:
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
OpenSSL: openssl_handshake - SSL_connect error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
wlp12s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
for exmaple, see:
https://bbs.archlinux.org/viewtopic.php?id=198796
http://alicevixie.blogspot.com/2015/06/dh-key-too-small.html
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/206
------------------------------------------------------------------------
On 2015-07-17T15:19:31+00:00 Dan wrote:
(In reply to Wallace Hermano from comment #1)
> I'm using Fedora 22.
> After updating the package wpa_supplicant 2.3 to 2.4 can not connect to the
> wireless network (PEAP-MSCHAPv2, no CA Certificate).
>
> Please see this thead
> http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Internal-
> radius-server-incompatibility-with-the-new-wpa/td-p/236602
>
> After downgrade to 2.3 it works again.
Your issue is likely due to wpa_supplicant enabling TLSv1.2 support (in
response to recent attacks against SSLv3, TLSv1.0, and TLSv1.1, like the
recent Firefox updates that disabled SSLv3 and TLSv1.0 negotiation).
Unfortunately, not all RADIUS servers are prepared for that, and they
accept the TLSv1.2 connection but generate a mismatching key than the
supplicant does. That bug is in the RADIUS server...
There are some patches floating around that will detect this condition
and fall back to the less-secure TLSv1.1 automatically, and we'll
probably have to add those to Fedora until the RADIUS server vendors
like Cisco, Aruba, etc catch up and fix their products.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/207
------------------------------------------------------------------------
On 2015-07-17T16:41:56+00:00 Dan wrote:
(In reply to Dan Williams from comment #3)
> (In reply to Kevin Havener from comment #0)
> > Description of problem: After updating to wpa_supplicant 2.4-3 on July 1,
> > was unable to connect to my corporate wifi access point. Subsequent
> > downgrade to wpa_supplicant 2.3-3 fixed access problem, so I think this is a
> > wpa_supplicant bug
> >
> >
> > Version-Release number of selected component (if applicable): wpa_supplicant
> > 2.4-3
> >
> >
> > How reproducible: Upgrade to 2.4-3 try to access wpa/wpa2 wifi with TTLS
> > authentication that has been working for well over a year now. Fails.
> > Downgrade to 2.3-3 and it works again.
>
> This appears to be an OpenSSL issue, not a wpa_supplicant one:
>
> SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
> OpenSSL: openssl_handshake - SSL_connect error:14082174:SSL
> routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
> wlp12s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
>
> for exmaple, see:
>
> https://bbs.archlinux.org/viewtopic.php?id=198796
> http://alicevixie.blogspot.com/2015/06/dh-key-too-small.html
More info: wpa_supplicant 2.4 may trigger this where 2.3 would not,
becuase 2.4 enables some new ciphers for use with TLSv1.2, and the
server may have enabled DH only for those ciphers that are now enabled.
The options are to either get your network admins to fix the DH key
issue by using something > 768 bits, or to disable TLSv1.2 for now until
they fix it.
But as a test, here's a wpa_supplicant with TLSv1.2 disabled by default.
If you could test it on your network where you get the "dh key too
small" error to see if that fixes the issue, then great, we can proceed
with a more general solution. But if it doesn't fix the issue, then
we'll need to dig a bit deeper and there may not be a general fix.
http://koji.fedoraproject.org/koji/taskinfo?taskID=10392924
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/208
------------------------------------------------------------------------
On 2015-07-17T17:57:18+00:00 Major wrote:
I tried the koji build from the last comment and I'm unable to connect.
With debug wpa_supplicant logs, I get:
SSL: SSL_connect:error in SSLv2/v3 read server hello A
SSL: SSL_connect:error in SSLv3 read finished A
SSL: SSL_connect:error in SSLv3 read finished A
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/209
------------------------------------------------------------------------
On 2015-07-20T14:45:30+00:00 Kevin wrote:
I also tried the Koji build. Got the same error as I originally
submitted:
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
OpenSSL: openssl_handshake - SSL_connect error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
wlp12s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
I
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/210
------------------------------------------------------------------------
On 2015-08-18T15:01:42+00:00 Virgilio wrote:
I can also confirm that a downgrade of the wpa_supplicant package to
version 2.3.3 on Fedora 22 x86_64 makes it possible again to connect to
a WPA2 Enterprise/PEAP/MSCHAPV2 network, like eduroam.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/213
------------------------------------------------------------------------
On 2015-08-21T16:44:13+00:00 Hannes wrote:
I can further confirm that downgrading wpa_supplicant to 2.3.3 allowed
me to immediately connect to eduroam.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/214
------------------------------------------------------------------------
On 2015-08-24T12:43:04+00:00 Gregor wrote:
I can confirm the same behavior. Immediately after downgrading the
wpa_supplicant to 2.3.3 allowed me to connect to our company WIFI.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/215
------------------------------------------------------------------------
On 2015-09-03T13:45:43+00:00 Luiz wrote:
I can confirm the same behavior.
I downgraded to 2.3.3 and I was able to connect successfully to connect
to the wifi, but then I upgraded the kernel to 4.1.6 and it installed an
wpa_supplicant-gui and some other wpa packages, and it stopped working
again.
Can I get some help identifying if the issue is from the same root
cause?
Because the wpa_supplicant-gui has the same 2.4.4 version of the
wpa_supplicant and I tried to downgrade the *-gui one and it failed, due
to not having package available.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/216
------------------------------------------------------------------------
On 2015-09-03T13:56:27+00:00 Kent wrote:
FYI: I have seen the same (or at least very similar problems). Upgrading
to 2.4-3 or 2.4-4 broke my eduroam connection. Downgrading to 2.3-3
again made it work.
I talked to the people running the authentication server (Radiator) used
when I log in to eduroam. They upgraded OpenSSL and a related Perl
module on the server. After that, eduroam survived an upgrade to 2.4-4
on my laptop.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/217
------------------------------------------------------------------------
On 2015-09-08T12:46:42+00:00 Luiz wrote:
Solved the issue removing the wpa_supplicant, and it removed anaconda
and anaconda-gui. Then I re-installed the wpa_supplicant,
NetworkManager-wifi, and downgraded the wpa_supplicant.
If someday has a fix I would be very happy to un-block wpa_supplicant
packages from my dnf exceptions.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/218
------------------------------------------------------------------------
On 2015-09-11T09:55:33+00:00 Germano wrote:
*** Bug 1244188 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/219
------------------------------------------------------------------------
On 2015-09-11T10:44:17+00:00 Germano wrote:
Lastest wpa supplicant working with WPA Enterprise connections:
wpa_supplicant-2.3-3.fc22.x86_64
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/220
------------------------------------------------------------------------
On 2015-09-11T13:15:10+00:00 David wrote:
(In reply to Germano Massullo from comment #15)
> Lastest wpa supplicant working with WPA Enterprise connections:
> wpa_supplicant-2.3-3.fc22.x86_64
Just to avoid confusion:
The lastest wpa supplicant that works with WPA Enterprise connections is
wpa_supplicant-2.3-3.fc22.x86_64
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/221
------------------------------------------------------------------------
On 2015-10-02T16:50:33+00:00 Ville wrote:
eduroam broke for me with 2.4 as well. I tried upgrading to 2.5 locally
but it remained similarly broken. Works with 2.3-3.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/222
------------------------------------------------------------------------
On 2015-10-02T16:51:16+00:00 Ville wrote:
*** Bug 1245766 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/223
------------------------------------------------------------------------
On 2015-10-14T00:54:02+00:00 Michael wrote:
(In reply to Gregor Fuis from comment #10)
> I can confirm the same behavior. Immediately after downgrading the
> wpa_supplicant to 2.3.3 allowed me to connect to our company WIFI.
I had the same issue. The workaround with version 2.3.3 did the trick
for me as well.
(In reply to Dan Williams from comment #4)
> Your issue is likely due to wpa_supplicant enabling TLSv1.2 support (in
> response to recent attacks against SSLv3, TLSv1.0, and TLSv1.1, like the
> recent Firefox updates that disabled SSLv3 and TLSv1.0 negotiation).
> Unfortunately, not all RADIUS servers are prepared for that, and they accept
> the TLSv1.2 connection but generate a mismatching key than the supplicant
> does. That bug is in the RADIUS server...
I can confirm that updating FreeRADIUS (server/network infrastructure)
to version freeradius-2.2.6-6.el6_7.x86_64 fixed the issue with
wpa_supplicant as well as a (probably similar) issue with android 6.0 as
described here
https://code.google.com/p/android/issues/detail?id=188867#c29
I am now running wpa_supplicant-2.4-4.fc22.x86_64 on fedora and can
connect successful to a WiFi using PEAP-MSCHAPv2 (with and without a
server certificate check against a CA Certificate)
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/224
------------------------------------------------------------------------
On 2015-10-14T14:50:20+00:00 Fedora wrote:
This package has changed ownership in the Fedora Package Database.
Reassigning to the new owner of this component.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/225
------------------------------------------------------------------------
On 2015-10-15T10:40:30+00:00 Wallace wrote:
I'm testing Fedora 23 beta but i can't downgrade the wpa_supplicant.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/226
------------------------------------------------------------------------
On 2015-10-15T11:45:55+00:00 Nick wrote:
I wouldn't bother degrading client security by forcing TLS 1.1
The fact that Google have shipped with TLS 1.2 in Android 6.0
(Marshmallow) is quickly identifying and mopping up broken
authentication servers.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/227
------------------------------------------------------------------------
On 2015-10-15T11:46:40+00:00 Nick wrote:
I posted in the Google issue tracker:
" suspect that you all are hitting this issue because the new version of
Android is now negotiating, correctly, with TLS 1.2 and you have a
broken backend.
If so, this issue should be marked as being invalid.
This applies to anybody with WPA2-Enterprise/802.1X SSIDs backed by
either FreeRADIUS 2.2.6 with all TLS-based EAP types, 2.2.6 through
2.2.8 with EAP-TTLS, 3.0.7 with all TLS-based EAP types, and 3.0.7
through 3.0.9 with EAP-TTLS, or Radiator 4.14 or later when used in
conjunction with Net::SSLeay 1.52 or earlier.
These unfortunately experience a critical bug where they miscalculate
session keying material, the MPPE keys, when the TLS 1.2 protocol is
negotiated by EAP clients (supplicant).
Clients that negotiate with the TLS 1.2 protocol version in the TLS
Client Hello will not be able to get a usable association to affected
wireless networks.
Two MPPE keys, the MS-MPPE-Recv-Key (MasterReceiveKey) and MS-MPPE-Send-
Key (MasterSendKey), are used to derive the Master Session Key (MSK).
This is absolutely essential to get a usable association.
The mismatch occurs because the client derives the correct MSK and the
AP derives a different, incorrect MSK due to the incorrectly calculated
MPPE keys supplied in the RADIUS Access-Accept.
This is more of an acute issue as Red Hat ship with a broken FreeRADIUS
2.2.6 package in RHEL 6.7. There is an update now to address this:
https://rhn.redhat.com/errata/RHBA-2015-1829.html
CentOS 6.7 is similarly affected as it derives from Red Hat's sources.
I should also mention that there is a difference between
implementing/offering TLS 1.2 or not and being intolerant to it. It is
the latter that is a problem with the introduction of TLS 1.2 for EAP.
The issue above, loosely, concerns intolerance because the subsequent
MPPE keys generated are miscalculated.
Deployments that continue to offer just TLS 1.0 will continue to
function correctly as TLS 1.0 will be negotiated by EAP clients
(supplicants) despite it offering TLS 1.2 in the client hello in their
default configuration. (TLS has a version negotiation mechanism, you
just need an intersection of supported versions and cipher suites.)"
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/228
------------------------------------------------------------------------
On 2015-11-07T13:01:14+00:00 Nick wrote:
This bug needs to be closed as NOTABUG.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/229
------------------------------------------------------------------------
On 2015-11-16T16:43:51+00:00 Luiz wrote:
Hey Nick,
I am not using Android, I am using the Fedora 23 as an SO and this error
is really annoying, I tried to check which TLS version I am using and
still dont have any clue.
Can you help checking or to use the TLS that doesnt error out?
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/230
------------------------------------------------------------------------
On 2015-11-16T16:50:38+00:00 Nick wrote:
Anywhere that is using wpa_supplicant 2.4 or later without specific
configuration to disable TLS 1.2 will hit this issue with affected
RADIUS servers. TLS 1.2 is rightly enabled by default.
(Android Marshmallow uses such a version of wpa_supplicant).
You can certainly disable TLS 1.2 in the configuration for
wpa_supplicant if you absolutely must get a usable connection.
Do so with phase1="tls_disable_tlsv1_2=1"
Ideally though you would seek to get the RADIUS server updates to a
version that isn't broken.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/231
------------------------------------------------------------------------
On 2015-11-24T17:15:48+00:00 Luiz wrote:
I am trying to understand better the last choice, I could connect with the command line, but its kind of annoying still. My version of the freeradius is this
[~] $ sudo dnf info freeradius
Last metadata expiration check performed 3:05:10 ago on Tue Nov 24 12:08:27 2015.
Pacotes instalados
Name : freeradius
Arq. : x86_64
Epoch : 0
Versão : 3.0.8
Release : 3.fc23
Tam. : 3.4 M
Repo : @System
>From repo : fedora
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/232
------------------------------------------------------------------------
On 2015-11-25T20:57:19+00:00 Michael wrote:
I'm not sure if I get you right. Are you using Fedora as a server
operating system to provide radius authentication for your network
infrastructure?
TLS1.2 is the currently newest and (hopefully) most secure version of
the TLS protocol and therefore it is a good choice using it. So
disabling TLS1.2 is a bad idea as stated in comment #26. Use a radius
server version that implements TLS1.2 correctly instead.
Version 3.0.8 is affected when using EAP-TTLS as mentioned in comment
#23 so if you have trouble use a different server version or a different
EAP type.
If I've got you totally wrong and you are not the network operator ask
your network operator to fix the problem and remove freeradius from your
notebook/workstation.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/233
------------------------------------------------------------------------
On 2015-11-26T09:42:45+00:00 Luiz wrote:
Yeah, I am a software developer using Fedora as a workstation.
Unfortunately my network administrators like Windows, the solution they
provided me is to use Ubuntu. If I want to use Linux. I prefer Fedora
because I use it since version 13.
I removed the freeradius. The command line is not connecting anymore.
Here is my log. Any thoughts?
Successfully initialized wpa_supplicant
wlp6s0: SME: Trying to authenticate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Trying to associate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Associated with 94:b4:0f:1b:bc:c5
wlp6s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp6s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wlp6s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA' hash=ff856a2d251dcd88d36656f450126798cfabaade40799c722de4d2b5db36a73a
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA' hash=c27fd4b85e96d3777c68ab7df6aa4e626bf3ff8c72b1ce81d1eb78babeb1a074
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/serialNumber=lLUge2fRPkWcJe7boLSVdsKOFK8wv3MF/C=US/O=securelogin.arubanetworks.com/OU=GT28470348/OU=See www.geotrust.com/resources/cps (c)11/OU=Domain Control Validated - QuickSSL(R) Premium/CN=securelogin.arubanetworks.com' hash=47fa89956f2aa349e8814b21a7bbd64c9b597f0f192bfe073559945a7a846534
wlp6s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:securelogin.arubanetworks.com
wlp6s0: CTRL-EVENT-DISCONNECTED bssid=94:b4:0f:1b:bc:c5 reason=3 locally_generated=1
wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=BR
wlp6s0: SME: Trying to authenticate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Trying to associate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Associated with 94:b4:0f:1b:bc:c5
wlp6s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp6s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wlp6s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA' hash=ff856a2d251dcd88d36656f450126798cfabaade40799c722de4d2b5db36a73a
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA' hash=c27fd4b85e96d3777c68ab7df6aa4e626bf3ff8c72b1ce81d1eb78babeb1a074
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/serialNumber=lLUge2fRPkWcJe7boLSVdsKOFK8wv3MF/C=US/O=securelogin.arubanetworks.com/OU=GT28470348/OU=See www.geotrust.com/resources/cps (c)11/OU=Domain Control Validated - QuickSSL(R) Premium/CN=securelogin.arubanetworks.com' hash=47fa89956f2aa349e8814b21a7bbd64c9b597f0f192bfe073559945a7a846534
wlp6s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:securelogin.arubanetworks.com
wlp6s0: CTRL-EVENT-DISCONNECTED bssid=94:b4:0f:1b:bc:c5 reason=3 locally_generated=1
wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=BR
wlp6s0: SME: Trying to authenticate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Trying to associate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Associated with 94:b4:0f:1b:bc:c5
wlp6s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp6s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wlp6s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA' hash=ff856a2d251dcd88d36656f450126798cfabaade40799c722de4d2b5db36a73a
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA' hash=c27fd4b85e96d3777c68ab7df6aa4e626bf3ff8c72b1ce81d1eb78babeb1a074
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/serialNumber=lLUge2fRPkWcJe7boLSVdsKOFK8wv3MF/C=US/O=securelogin.arubanetworks.com/OU=GT28470348/OU=See www.geotrust.com/resources/cps (c)11/OU=Domain Control Validated - QuickSSL(R) Premium/CN=securelogin.arubanetworks.com' hash=47fa89956f2aa349e8814b21a7bbd64c9b597f0f192bfe073559945a7a846534
wlp6s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:securelogin.arubanetworks.com
I am still wondering if the issue is on wpa_supplicant or on the hardware, because I know a guy who has another PC using Fedora 22 with wpa_supplicant 2.4 that connects in the network via NetworkManager.
Also that configuration of the phase1, Can I set somewhere in the
NetworkManager so I don't have to run command lines to connect to the
network?
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/234
------------------------------------------------------------------------
On 2015-11-26T20:52:11+00:00 Vincent wrote:
(In reply to Luiz Pegoraro from comment #29)
> I am still wondering if the issue is on wpa_supplicant or on the hardware,
> because I know a guy who has another PC using Fedora 22 with wpa_supplicant
> 2.4 that connects in the network via NetworkManager.
For F22 with wpa_supplicant 2.4 check this bug too, it seems the openssl
library version matters:
https://bugzilla.redhat.com/show_bug.cgi?id=1276073
> Also that configuration of the phase1, Can I set somewhere in the
> NetworkManager so I don't have to run command lines to connect to the
> network?
I got it working (F23/wpa_supplicant-2.4-7/openssl-1.0.2d-2) with a custom wpa_supplicant config and some manual steps:
network={
ssid="corpwifi"
key_mgmt=WPA-EAP
eap=PEAP
phase1="peaplabel=auto tls_disable_tlsv1_2=1"
phase2="auth=MSCHAPV2"
identity="***"
password="***"
}
Unfortunately, I couldn't get the above working with the Networkmanager (/etc/wpa_supplicant/wpa_supplicant.conf and ifcg-corpwifi). The config set in /etc/wpa_supplicant/wpa_supplicant.conf wasn't used.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/235
------------------------------------------------------------------------
On 2015-11-30T09:01:55+00:00 Eran wrote:
(In reply to Vincent P. from comment #30)
Sorry for the rookie questions, but:
1. Did you change /etc/wpa_supplicant/wpa_supplicant.conf or did you replace it?
2. After the change in /etc/wpa_supplicant/wpa_supplicant.conf, how am I to connect if not by the Networkmanager?
Thanks
> (In reply to Luiz Pegoraro from comment #29)
> > I am still wondering if the issue is on wpa_supplicant or on the hardware,
> > because I know a guy who has another PC using Fedora 22 with wpa_supplicant
> > 2.4 that connects in the network via NetworkManager.
>
> For F22 with wpa_supplicant 2.4 check this bug too, it seems the openssl
> library version matters: https://bugzilla.redhat.com/show_bug.cgi?id=1276073
>
> > Also that configuration of the phase1, Can I set somewhere in the
> > NetworkManager so I don't have to run command lines to connect to the
> > network?
>
> I got it working (F23/wpa_supplicant-2.4-7/openssl-1.0.2d-2) with a custom
> wpa_supplicant config and some manual steps:
> network={
> ssid="corpwifi"
> key_mgmt=WPA-EAP
> eap=PEAP
> phase1="peaplabel=auto tls_disable_tlsv1_2=1"
> phase2="auth=MSCHAPV2"
> identity="***"
> password="***"
> }
> Unfortunately, I couldn't get the above working with the Networkmanager
> (/etc/wpa_supplicant/wpa_supplicant.conf and ifcg-corpwifi). The config set
> in /etc/wpa_supplicant/wpa_supplicant.conf wasn't used.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/236
------------------------------------------------------------------------
On 2015-11-30T21:49:52+00:00 Vincent wrote:
I'm not sure if this is the right place te respond, but hey..wth.
(In reply to Eran B. from comment #31)
> (In reply to Vincent P. from comment #30)
>
> Sorry for the rookie questions, but:
> 1. Did you change /etc/wpa_supplicant/wpa_supplicant.conf or did you replace
> it?
After I did some manual testing (see next answer), I tried to update /etc/wpa_supplicant.conf with my corpwifi config and reconnect via the Networkmanager. Unfortunately, it didn't work.
> 2. After the change in /etc/wpa_supplicant/wpa_supplicant.conf, how am I to
> connect if not by the Networkmanager?
I turned off wifi via the Networkmanager. I created a new wpa_supplicant.conf in /root/ and rand some manual commands:
1. Connect to wifi:
# wpa_supplicant -f /var/log/wpa_supplicant.log -dd -P /var/run/wpa_supplicant.pid -c wpa_supplicant.conf -Dwext -iwlp3s0
2. Get an IP:
# dhclient wlp3s0
After this you should get an IP.
During my tests I fiddled with 'rfkill list all', 'rfkill unblock wifi'
and 'ip l set wlp3s0 up' too, but if you get an IP with the above steps,
you don't need too.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/237
------------------------------------------------------------------------
On 2015-12-16T17:20:10+00:00 Alberto wrote:
Also reported in
<https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588>.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/238
------------------------------------------------------------------------
On 2015-12-18T16:50:36+00:00 Luiz wrote:
SOLVED TODAY!!! BY NETWORKMANAGER!! Just dnf update -y
I am so thrilled! Thanks you guys!
I guess it was a problem in firmwares, I looked into the logs and there
were a lot of new packages for firmwares.
Thanks a lot, I guess saying by using Fedora 23, this can be closed now.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/239
------------------------------------------------------------------------
On 2015-12-18T18:13:43+00:00 Kevin wrote:
As the opener of this bug, I think it can be closed now. While other
folks seem to have wireless problems, I don't think they are related to
my problem which was fixed for me by an upgrade to our corporate
wireless access points. It has continued to work after upgrading from
F22 to F23 and a couple of iterations of wpa_supplicant as well.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/240
------------------------------------------------------------------------
On 2015-12-18T20:41:48+00:00 Dan wrote:
Yeah, for TLSv1.2 issues updating the RADIUS server or corporate network
is obviously the best choice. If that's not possible then the
workaround with the supplicant config must be used, but the problem is
at the RADIUS server.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager-
applet/+bug/1104476/comments/241
** Changed in: fedora
Status: Unknown => Fix Released
** Changed in: fedora
Importance: Unknown => Medium
** Bug watch added: code.google.com/p/android/issues #188867
http://code.google.com/p/android/issues/detail?id=188867
** Bug watch added: Red Hat Bugzilla #1276073
https://bugzilla.redhat.com/show_bug.cgi?id=1276073
--
You received this bug notification because you are a member of AIMS,
which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1104476
Title:
Network manager cannot connect to WPA2/PEAP/MSCHAPv2 enterprise wifi
networks without CA_Certificate, like Eduroam
Status in NetworkManager:
Fix Released
Status in Release Notes for Ubuntu:
Fix Released
Status in network-manager-applet package in Ubuntu:
Triaged
Status in wpasupplicant package in Ubuntu:
Triaged
Status in network-manager-applet source package in Trusty:
Triaged
Status in wpasupplicant source package in Trusty:
Triaged
Status in network-manager package in Debian:
New
Status in Fedora:
Fix Released
Status in Gentoo Linux:
Fix Released
Status in network-manager package in openSUSE:
Confirmed
Bug description:
HOW TO REPRODUCE:
Connect to a MPA2/PEAP/MSCHAPv2 enterprise wifi network that doesn't use a CA Certificate, like Eduroam.
RESULT:
The computer doesn't connect, as the certificate verification fails.
WORKAROUNDS:
(http://askubuntu.com/questions/279762/cant-connect-to-wpa2-enterprise-peap)
RELEASE NOTES TEXT:
When connecting to MPA2/PEAP/MSCHAPv2 enterprise wifi networks that doesn't use a CA Certificate, like Eduroam, the connection fails (http://askubuntu.com/questions/279762/cant-connect-to-wpa2-enterprise-peap)
To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/1104476/+subscriptions
