Just one more point, the same problem occurs with wired Ethernet + 802.1x authentication. The workaround also works.

I can confirm the described behaviour.
The wireless lan in the company I work for uses WPA2/PEAP/MSCHAPv2 without a CA-certificate and due to this bug it is impossible to connect to the network.

The workaround works.

This is the commit that sets the "system-ca-certs":
https://git.gnome.org/browse/network-manager-applet/commit/?id=3021ce121b162fc69ec2fd800776a5dd28d72042

The path (/etc/ssl/certs) is passed via wpa_supplicant to OpenSSL that uses certificates in the directory for verifying server certificate.

It seems the problem is in OpenSSL or ca-certificates package (owning /etc/ssl/certs). OpenSSL requires hash files (symlinks) for actual certificates, but they are not present.

See
http://marc.info/?l=hostap&m=122884180418815&w=2
https://code.google.com/p/chromium/issues/detail?id=213693


Relevant lines from a report:
Jan 24 21:28:18 ubuntu wpa_supplicant[3569]: TLS: Certificate verification failed, error 20 (unable to get local issuer certificate) depth 1 for '/C=SK/L=Bratislava/O=Comenius University/CN=WWW Servers Certification Authority/emailAddress=kca@uniba.sk'
Jan 24 21:28:18 ubuntu wpa_supplicant[3569]: wlan0: CTRL-EVENT-EAP-TLS-CERT-ERROR reason=1 depth=1 subject='/C=SK/L=Bratislava/O=Comenius University/CN=WWW Servers Certification Authority/emailAddress=kca@uniba.sk' err='unable to get local issuer certificate'
Jan 24 21:28:18 ubuntu wpa_supplicant[3569]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA
Jan 24 21:28:18 ubuntu wpa_supplicant[3569]: OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Jan 24 21:28:19 ubuntu wpa_supplicant[3569]: wlan0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

Just want to add to this that I also stumbled upon this bug since about a month. Was kind of expecting something this critical to be fixed ASAP, but since a month has passed without improvement, decided to spend some time to investigate.

For me the situation is as follows:
My company uses a WPA/WPA2 encrypted wifi network using PEAP and MSCHAP2 .
When using the nm-connection-editor, I am being asked to select a root certificate. I select 'ignore'. Yet connection does not work.
Investigation shows that the file /etc/NetworkManager/system-connections/<SSID> contains the line 'system-ca-certs=true' which is apparently wrong.

Just want to point out that this breaks wifi for many business/enterprise users... priority++

Since there seems to be no interest in fixing this, I'll add another "me too" in order to bump the issue. Could not connect to my University's network with NetworkManager 0.9.8.8 (Arch Linux) because of "system-ca-certs=true". Setting it to "false" solved the issue for this connection.

I can confirm this. This is a serious issue, that has haunted me for over a year trying to connect to the network on my campus. I just now found the workaround. This needs to be fixed ASAP.

Created attachment 257612 [details] [review]
Adds an option to let the user choose whether to use system CA certs or not

Comment on attachment 257612 [details] [review]
Adds an option to let the user choose whether to use system CA certs or not

@GNOME devs, I have a patch ready that lets the user choose whether to use system CA certs or not. Feel free to use it.

I've already reported the same thing downstream with Ubuntu.

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1104476/comments/103

Attaching here so other distros can make use of it too.

(In reply to comment #8)

Hi,

Thank you for your effort.

(for the record, attachment 257612 [details] [review] applies to nma-9-8-0 branch)


I think, the use_system_ca_certs property should always be set unconditionally (or why not?):

-    if (use_system_ca_certs) {
-        g_object_set (s_8021x, NM_SETTING_802_1X_SYSTEM_CA_CERTS, TRUE, NULL);
-    }
+    g_object_set (s_8021x, NM_SETTING_802_1X_SYSTEM_CA_CERTS, use_system_ca_certs, NULL);



And I think, that you don't have to connect the "toggled" signal to wireless_security_changed_cb. wireless_security_changed_cb is there to (re-)evaluate whether all mandatory data is provided and if so, to enable/disable the "Save" button. This property has no effect on the validity of the provided options.




Also, some lines are not according to our coding-convention, but I can fix that later.

> I think, the use_system_ca_certs property should always be set unconditionally

Oh, yeah, of course. I can't believe I wrote that! :P

> And I think, that you don't have to connect the "toggled" signal to
> wireless_security_changed_cb. wireless_security_changed_cb is there to
> (re-)evaluate whether all mandatory data is provided and if so, to
> enable/disable the "Save" button. This property has no effect on the validity
> of the provided options.

Ah, that one is actually necessary. Subtle bug. I didn't catch it at first. Here's what happens if we don't wire "toggled" to wireless_security_changed_cb, when always_ask (from eap-method-simple) is on:

1) Open an 802.1x connection, which has always_ask on, for editing,
2) Toggle just the sys_certs button,
3) Save.
4) ???
5) system_ca_certs setting in the corresponding /etc/NetworkManager/system_connections/ file remains unchanged.

I think this is because just toggling sys_certs doesn't fire any event so the new changes aren't really saved. Without "always_ask", validation is forced everytime because the password field is blank. always_ask sidesteps the validity check password, therefore not triggering any change.

> Also, some lines are not according to our coding-convention, but I can fix that
later.

Sorry about that, I realised very late that my vim was set to expand tabs, and then I tried to fix the diff by hand. :)

*** Bug 707921 has been marked as a duplicate of this bug. ***

If you have this problem, do you really not want to verify the identity of the network you are connecting to?  Or does your network just use a generic certificate chain for verification?

(In reply to comment #12)
Software should do EXACTLY what I tell it to do. If I don't want it to verify identities, it should obey.

This bug affects most university networks which usually do not have certs, or use self-signed/generic ones.

(In reply to comment #13)
> (In reply to comment #12)
> Software should do EXACTLY what I tell it to do. If I don't want it to verify
> identities, it should obey.
> 
> This bug affects most university networks which usually do not have certs, or
> use self-signed/generic ones.

For this case, you should be choosing that self-signed certificate, or choosing the generic ones from /etc/pki/tls/certs.pem (or wherever the certificate chain happens to be).

Not choosing a CA certificate is a pretty big security risk, which is what the UI attempts to tell you.  The UI will always require you to manually select that you do not wish to verify the CA certificate of the network you are connecting to because of this risk.

The old "nag dialog" for this was pretty awful, and we're investigating ways to make the process of confirming that you do, in fact, want an insecure connection, easier on the user.  But like I said before, it will still require at least one extra click of explicit confirmation.

Yes, in an ideal world. But enterprise netadmins the world over don't supply us with the root CA even if self-signed. And that includes my own University where I am a part of the process.

On the other hand, not giving the user a choice at all is bad too. You and I know that not choosing a CA cert is bad. So keep this option on by default, but at least let the user turn it off in the sad case their netadmin hasn't provided them with one.

The nag dialog is unhelpful too, since the end-user may not always know what a CA cert is, or why it's necessary. A helpful message would be to also ask them to contact their "Network Administrator".

@thaller: I think I know remember why I put in that conditional check in the patch. I had thought to enable system-ca-certs for new connections by default. Dunno why I didn't see it through.

Here's our managements' response when we ask them for the CA cert and explain to then how EAPOL with CA is like no EAP at all:

"We don't use 1x to guarantee that the users are connecting to the correct network, since we control all the LAN switches anyway. We use 1x so we can prevent external entities from connecting to our LAN. We don't see why we should provide a CA cert and complicate the system further since you'd need to connect to the LAN in order to download the cert anyway. Our Windows and Mac deployments have clear steps to disable CA validation."

PS: KDE has the option too.

Hi,

I'm Stefan Winter of eduroam R&D. I've been notified of this thread, and can't help but reply... there seems to be a bit of a misunderstanding of how the certs are used, why they are important, and why it is a BAD idea to refer to the system CA store by default/unconditionally.

First off, there is no "there is no CA". Almost all EAP types which are suitable for WLAN authentication do involve a server cert in the protocol - there is no way to operate "without". This is true for PEAP, EAP-TTLS, EAP-FAST, EAP-TLS.

What you can of course do is to *ignore* the certificate which your authentication server presents during the login phase. This opens you up MITM attacks and you can't verify which network you are connecting to at all. I.e. it is an incredibly bad idea to do that. If users really want that, they can of course be allowed to turn off validation. This implies that system-ca-certs is not active for those users - there is no information about the CA which signed the cert, and the user doesn't even care. Verifying against the system CA store will make the authentication fail if e.g. a self-signed cert was used.

If you do choose to verify the server cert (good!), there comes the question which CA to trust. Here it is very important to realise that the Enterprise WiFi authentication usage of PKI certificates is *very* different from the browser use case. Please read our detailed page about this:

https://confluence.terena.org/display/H2eduroam/EAP+Server+Certificate+considerations

(the first two paragraphs of Consideration 1).

Summary: for the big world-wide web, you don't know which CA the website operator chose to sign his certificate - so you need to have a set of CAs you trust. This is where the system store is useful.

Contrary to that, for your Enterprise WiFi, there is exactly one server, which was issued one certificate, from exactly one, well-known CA. Any other certificate is a sign that something fishy's going on.

Therefore, for server verification purposes, the most secure option is to pinpoint the exact one CA which issued the server cert, and to pinpoint the expected server name to the one name of your authentication server.

** It does not matter if this is a self-signed CA or a commercial one, and it does not matter if the CA is in the system store or not! **

So, for EAP, there is no security implication by using "just" a self-signed CA/cert. It is actually recommended practice.

Even if your CA is already in the store, this is not very significant; there are many in the store, and only one is "good" for you.

Therefore, the value of system-ca-certs is next to zero anyway. It is only an option to take for those who believe that you need to spend money to get security and don't care to understand the protocols involved, and don't want to be bothered with certificates. I know that such people exist, so it's not unreasonable to keep the *option* of using the system store in there. It should however not be the default (by default ask for the exact CA). And under no circumstance should it be mandatory!

I'm happy to get involved with people actually coding this. We are already talking to the KNetworkManager UI to revamp their Interface to get rid/de-prioritise system-ca-store.

Hint: Even the evil Windows supplicant does it right: it presents all the CA certs it knows about, but has *all* of them *unchecked* and you are forced to pick the one CA that is important for you.

Greetings,

Stefan Winter

If system-ca-certs is really not that useful, we could simply not make it editable by nm-applet.

If then nm-applet creates a new connection, it must make sure, that it sets system-ca-certs to FALSE (1).

If nm-applet edits an existing connection with system-ca-certs, it should *not* unset the flag. The reason is, that you might really want to set the flag by other means, and nm-applet should not unset that parameter (2).

This might be a nice solution, because implementing (1) and (2) will be very easy, and it be what most of the users actually want. And having less uncommon options in the UI can also be appealing.

Hi,

that sounds like a good way forward!

I still don't understand why system-ca-certs and "Save Password" seem to be entangled? They are totally orthogonal issues. That part of it looks like a bug in its own right to me.

Greetings,

Stefan

(In reply to comment #19)
> I still don't understand why system-ca-certs and "Save Password" seem to be
> entangled? They are totally orthogonal issues. That part of it looks like a bug
> in its own right to me.

I could not reproduce this relation between "Save Password" and setting system-ca-certs in your patch. Seems strange to me too.

(In reply to comment #20)
> (In reply to comment #19)
> > I still don't understand why system-ca-certs and "Save Password" seem to be
> > entangled? They are totally orthogonal issues. That part of it looks like a bug
> > in its own right to me.
> 
> I could not reproduce this relation between "Save Password" and setting
> system-ca-certs in your patch. Seems strange to me too.

You might not have commented the "toggled" signal code. Or used the wrong checkbox; it's "Always ask" when ticked on that causes problems, not "Save Password". (Wait, does such a checkbox even exist?)

Steps to reproduce:
1) Have a perfectly fine 802.1x setting.
2) Enable "Always ask".
3) Save.
4) Check the status of system-ca-certs in the /etc/N.... file
5) Re-open connection for editing
6) Toggle the "Use System CA certs" option, while "Always ask" is still on
7) Save.
8) Re-check the status of system-ca-certs in /etc/N.... file

Btw, I just reproduced this with my patch applied to nma-0.9.8.4 (Arch Linux) and the "toggled" bit of my patch commented out.

Created attachment 258486 [details] [review]
[PATCH] applet: do not set system-ca-certs for new connections

Patch so that the system-ca-certs flag is not set for new connections.

Review of attachment 258486 [details] [review]:

The biggest problem with this is the inability to edit existing connections. Lets take a real world use-case. We have ~200 users, non-tech-savvy, non power-user, sitting on Ubuntu 13.04 being unable to use our campus' WiFi because of this bug. Setting up the WiFi itself was a little cumbersome for them, and that was with graphical tools and a graphical guide.

Basically: asking all the common, ordinary people to edit a system file using sudo in their Terminal is not favorable.

By the way, nmcli doesn't accept "connection modify". Weird. Tested on 9.4.0 (Ubuntu 12.04.3 LTS) and 9.8.8 (Arch Linux)

I don't see this as a big problem.

These existing connections were not working before. So, the affected users already either found another solution or they fixed these connections (by editing system-ca-certs in the config or by providing a valid certificate). Those of your users who were able to work around the issue have working connections now, and their connections will continue to work.

With this fix, the users can create new working connection and their old connection will continue to work (if they did it before).

Oh sorry, editing connections with nmcli was only added to version 0.9.9, current master.

(In reply to comment #24)
> I don't see this as a big problem.
> 
> These existing connections were not working before. So, the affected users
> already either found another solution or they fixed these connections (by
> editing system-ca-certs in the config or by providing a valid certificate).
> Those of your users who were able to work around the issue have working
> connections now, and their connections will continue to work.
> 
> With this fix, the users can create new working connection and their old
> connection will continue to work (if they did it before).

Hmm, I guess it's good enough. Asking users to edit existing connections by navigating a jungle of options and uncheck an obscure (to them) box is also unfavorable.

Not to mention that "create a new connection, guys. There are your instructions" sounds much simpler than "Hey, you need to edit this tiny little thing here, and oh, yeah, of course, we'll get you some Instructions. Dave, can you get this printed?"

Now, it's just a matter of getting this accepted downstream. Any helpful tips, guys? (It's my first time reporting (non-trivial) bugs.)

How about 

"Delete the non-working configuration and create a new one"?

Review of attachment 258486 [details] [review]:

/* Change patch status to reviewed throws error:

Failed to publish review: Undefined subroutine &extensions::splinter::lib::WSSplinter::ThrowCodeError called at /var/www/bugzilla.gnome.org/extensions/splinter/lib/WSSplinter.pm line 88.


Extra details: empty review message.

*/

(In reply to comment #26)
> How about 
> 
> "Delete the non-working configuration and create a new one"?

Yeah, that's what I said. This is indeed much simpler than asking them to fix by editing.

Attaching relevant part of my previous message for proof:

> Not to mention that "create a new connection, guys. There are your
> instructions" sounds much simpler than ...

Review of attachment 258486 [details] [review]:

See comment #3
Your patch basically reverts https://git.gnome.org/browse/network-manager-applet/commit/?id=3021ce121b162fc69ec2fd800776a5dd28d72042 that made system-ca-certs=true.
So it would solve the connecting issue. But I would ask Dan for his change rationale. And if we really want to go this way I would do 'git revert' to make it clear.

But still there is a problem with OpenSSL requiring certificates hash, and ca-certificate packages doesn't provide it.
Distributions should properly configure the hashes using openssl's c_rehash or manually.
http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html#EXAMPLES
http://conshell.net/wiki/index.php/OpenSSL_usage_tips_and_examples#Generate_the_hash_value_from_a_certificate

Hi Jirka,

(In reply to comment #29)
> Review of attachment 258486 [details] [review]:
> 
> See comment #3
> Your patch basically reverts
> https://git.gnome.org/browse/network-manager-applet/commit/?id=3021ce121b162fc69ec2fd800776a5dd28d72042
> that made system-ca-certs=true.
> So it would solve the connecting issue. But I would ask Dan for his change
> rationale. And if we really want to go this way I would do 'git revert' to make
> it clear.

You are correct, I missed that. Yeah, the commit message should point out that it reverts 3021ce121. I will ask Dan.

> But still there is a problem with OpenSSL requiring certificates hash, and
> ca-certificate packages doesn't provide it.
> Distributions should properly configure the hashes using openssl's c_rehash or
> manually.
> http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html#EXAMPLES
> http://conshell.net/wiki/index.php/OpenSSL_usage_tips_and_examples#Generate_the_hash_value_from_a_certificate

Yes, but missing hashes is not a problem of NetworkManager (which does not manage system wide certificates) and not the problem of this bug report AFAIS (right?).

Hello everyone!

I'm one of the "dreadful" local eduroam-administrators of our school and this is my 2 eurocents ;)

Here goes:

 * If a gui has option to not enable cert checking, then the software should do what it's told.

 * A computer should allow users to do stupid things if they want to period.

 * Tried with fresh Ubuntu 13.10 and the darn thing asks for password over and over again when in fact the problem is not even related to the user's password.

 * It worked just fine before.

By reading the previous posts the developer/maintainer tries to avoid real world problems with "perfect world" -solutions where everyone is a computer expert and in perfect world the obvious bug doesn't affect no-one because you shouldn't even use the software that way.

The reality is that for example in our case all the support requests go to completely wrong people who doesn't have anything to do with this problem or have a working solution for the problem.

In our case our instructions were simple: put your username and password in and don't touch anything else. Even our non-technical field of students got the settings right. Now the situation is much worse. Use old version of operating system or make this complicated ca-thingy which requires you to first buy a usb-stick and download something with another computer and something and something... or ask your boyfriend to do the usb-ca-thingie for you.

You get the idea :)



And as always. Excuse for my poor grammar etc. I'm not a native english speaking person.

We're drifting away from the bug at hand with this, but since you are an eduroam admin, and I'm an eduroam R&D person, I will again have to bite on this one.

"In our case our instructions were simple: put your username and password in and
don't touch anything else."

Which means you invited users to send their usernames and passwords to anyone who's asking. Including every script kiddie who can set up a FreeRADIUS "pwnage edition" [1]. Great job. Really.

In other news, you are violating the European eduroam policy [2], which states very explicitly:

"6.3.2
Specifications and Operational Requirements: Identity Providers
Adherence to the following specifications is REQUIRED
[...]
The server-side EAP credentials MUST be communicated to the user base, and end-user documentation needs to be precise enough to allow users the unique identification of their EAP server"

It's true; if an end-user wants to be so stupid to turn off all security checks then his computer should allow him to be like that.
As a roaming consortium though, we do not want to allow administrators actively promoting that kind of behaviour.

BTW, eduroam can be provisioned with all the right settings, even on Linux, with eduroam CAT [3]. Being secure CAN be easy. CAT uses the D-Bus interface to provision the settings. No boy-friends needed.

Greetings,

Stefan Winter

[1] http://www.willhackforsushi.com/FreeRADIUS_WPE.html
[2] https://www.eduroam.org/downloads/docs/GN3-12-192_eduroam-policy-service-definition_ver28_26072012.pdf
[3] https://cat.eduroam.org

Good to see that the tools and docs are being worked on for eduroam. This was not the case several years ago when we joined the eduroam network.

However for the rather common "i don't read long instructions"-user the NetworkManager doesn't work as before and does not give a meaningful clue what went wrong.

(In reply to comment #25)
> (In reply to comment #24)
> > I don't see this as a big problem.
> > 
> > These existing connections were not working before. So, the affected users
> > already either found another solution or they fixed these connections (by
> > editing system-ca-certs in the config or by providing a valid certificate).
> > Those of your users who were able to work around the issue have working
> > connections now, and their connections will continue to work.
> > 
> > With this fix, the users can create new working connection and their old
> > connection will continue to work (if they did it before).
> 
> Hmm, I guess it's good enough. Asking users to edit existing connections by
> navigating a jungle of options and uncheck an obscure (to them) box is also
> unfavorable.

WPA Enterprise *is* hard, there's no way to get around it.  Even on Windows or Mac OS X you still have a jungle of options.  The way we always envisioned it working was that *administrators* would provide the configuration, either by pre-installing it when provisioning the user's machine, or by providing a downloadable package (RPM, DEB, custom config program, whatever) that would install the correct configuration for the user.  There's really no good way for users to correctly provision WPA Enterprise themselves and do it correctly.

Besides, to get the correct security, the administrator already needs to install the correct CA certificates for the installation, so it's not a stretch to imagine the administrator should install the right connection configuration at the same time.

Obviously users *can* configure it themselves based on web instructions too, but again, that often means they will (a) get it wrong and worse (b) achieve a completely insecure configuration.

The whole "nag dialog" and "double-check" stuff when you don't set a CA certificate is to confirm specifically with the user, through some explicit action, that they really do want to use an insecure configuration.

About 3021ce121; it was probably in error, and it was probably an error originally to allow both system-ca-certs *and* a user-specified CA concurrently.  So I agree with the revert of 3021ce121.

Patch reverted in upstream master:

https://git.gnome.org/browse/network-manager-applet/commit/?id=c798c40c5dce3bc6d9b615621cefe59660b5a504


I close this bug now because, as I see it, we won't extend the UI of nm-a to also support the system-ca-certs flag. The reason is that this is not a common usecase, as pointed out in comment #17.

This is IMO a fine solution. Thanks for all the comments!!

Can we get a tag for this? I'm on arch linux and still affected by this issue because the latest tag is 0.9.8.8, which is before this bugfix.

Bump, can anybody just cut a tag for some commit after this was taken care of, so that this bugfix is actually usable?

(In reply to comment #38)
> Bump, can anybody just cut a tag for some commit after this was taken care of,
> so that this bugfix is actually usable?

For now I cherry-picked the commit to the stable branch "0.9.8" -- so distributions could include this patch.

*but* we also want to make a new stable release 0.9.8.10 of NM and nm-applet soon, so please hold on a little longer!! :)

(In reply to comment #39)
> (In reply to comment #38)
> > Bump, can anybody just cut a tag for some commit after this was taken care of,
> > so that this bugfix is actually usable?
> 
> For now I cherry-picked the commit to the stable branch "0.9.8" -- so
> distributions could include this patch.
> 
> *but* we also want to make a new stable release 0.9.8.10 of NM and nm-applet
> soon, so please hold on a little longer!! :)

Thomas,

Thank you for taking the time to do this. It didn't actually help in the case of Arch Linux, because the version hasn't changed, but I appreciate that someone did something.

I see that 0.9.8.9 was cut earlier this month, so that should take care of things.

Again, appreciate that you did something.

*** Bug 728698 has been marked as a duplicate of this bug. ***

FWIW, this didn't actually fix the saving password part. However, I don't have another 10 months to wait for the actual fix. I'll be switching to some other network tool.

Thanks for trying to fix it though.

(In reply to comment #42)
> FWIW, this didn't actually fix the saving password part. However, I don't have
> another 10 months to wait for the actual fix. I'll be switching to some other
> network tool.
> 
> Thanks for trying to fix it though.

FWIW, this bug is not really related to saving password. Instead nm-applet would create a connection with system-ca-certs=yes ... which means that user without certificate could not connect. In such a case NM was actually reasking for passwords, but this was not the problem.

A workaround for this problem was to set system-ca-certs=no (in the config file).

Your problem was likely something else...

That workaround never actually worked. My setup is just as described above, but it still doesn't save the password. In either case it is irrelevant.

Thanks for your work.