We should figure out how to add this for additional security.  The UI is pretty crowded for TLS, TTLS, and PEAP as it is, but this is something that's good to have.

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

It would be nice if NetworkManager could act like the Network.prefPane in OS X;

* Has the possibility to require a Common Name in the certificate that the RADIUS server present OR
* Have the user to supply supply an certificate and find out CN from it.

wpa_supplicant already supports this so the "only thing needed" is the GUI to configure it. The option is called subject_match and is used like 'subject_match="CN=radius.my.tld"'.

There is also an possible security flaw here when NM doesn't have this feature. 

Imagine that a person could get an certificate from the same CA as we use, then that person could set up an Rouge AP and an Rouge RADIUS-server with an certificate with the same CA as our RADIUS-server uses and our clients that use NM would trust every certificate in that CA so they would happily give their password (or hash depending on that method you use) to the Rouge RADIUS-server.

See this paper for more information: http://airsnarf.shmoo.com/rogue_squadron.pdf

Thanks,
- Simon Lundström
System Administrator
IT Services, Stockholm University, Sweden

(In reply to comment #3)
> Imagine that a person could get an certificate from the same CA as we use, then
> that person could set up an Rouge AP and an Rouge RADIUS-server with an
> certificate with the same CA as our RADIUS-server uses and our clients that use
> NM would trust every certificate in that CA so they would happily give their
> password (or hash depending on that method you use) to the Rouge RADIUS-server.

Yes, you are absolutely right. We, at the hungarian eduroam community, realized, that the lack of this capability in NetworkManager is a VERY SERIOUS threat. In the Eduroam infrastructure it's quite possible that you home radius server's certificate is signed by the same CA as one or some of the numerous radius servers proxying your request, so any of these servers can easily (even accidentally!) open your SSL encrypted TTLS or PEAP tunnel, for example.

The problem gets even worse if you don't specify exactly the CA, which signed you certificate, but you trust every CA cert in /etc/ssl/certs (a very common scenario).

However, since your home radius server's certificate is transmitted as cleartext in the beginning of the PEAP/TTLS communication, it can be easily sniffed wireshark, and a relatively desperate attacker can purchase his own certificate from you CA.

If this attacker deploys his own AP/router/radius server, he can easily read your passwords (in case of TTLS/PAP authentication), or your NTLM password hashes (in case of TTLS/MSCHAPv2 or PEAP/MSCHAPv2). And the sad thing is that this MSCHAPv2 can cracked VERY EASILY by john ( http://www.openwall.com/john/ ). According my experiences it can be cracked five times faster than old Unix crypt password hashes :((( I managed to crack three out of four real-life passords in an hour without advanced dicionaries of specific options. One password (consisting of eight digits) was cracked by simple brute force within an hour! ( http://forums.remote-exploit.org/tutorials-guides/13728-tutorial-cracking-leap-networks-asleap-john.html )


So, to sum it up: NetworkManager MUST support certificate subject/altsubject validation, as Windows does.

Created attachment 149724 [details]
This is the functionaly that MUST be implemented as soon as possible.

I've reported the same bug but in a wider context under:

Bug 621484 - 802.1X Configurability Issues with MITM Consequences
https://bugzilla.gnome.org/show_bug.cgi?id=621484

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

I can't believe this is pending since 2006 already. We are suffering from the lack of this more and more in eduroam. I would really appreciate to get this in.

Regarding the UI question: you could take a look at virtually every other supplicant on various platforms. True: UIs look crowded for 802.1X settings. But these parameters are needed for security; one can't just leave them out.

On the plus side, even if the manual config UI is complex: we are working on site installers that contain all the relevant settings and can be executed on a click by the user (would be via DBUS with 0.9). In that case, the bootstrap UI isn't all that important and could even look slightly cluttered.

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

There's been some discussion on this recently and there may be patches coming.  At least that's my hope.

One way to get over the UI issues is to move to a checkbox list of EAP methods like Apple has done in Mac OS X, allowing each method to be configured independently.  It's actually possible to have multiple EAP methods configured at the same time such that if you roam to a location that only supports say TTLS while your normal location only supports PEAP (stupid network management but hey, whatever) that can work.

Short clarification about roaming: when doing roaming with EAP *right*, a user will *always* be presented with his home EAP type, by his home server.

That is, even when roaming to a very remote place, the EAP method will establish a TLS tunnel with the configured server-side credentials, i.e. the same server that the user configured at home. That server from home will then negotiate the EAP type with the user; there is no interaction with the visited place.

So you don't need to support negotiating multiple EAP types even in a roaming scenario. Supporting multiple EAP types is more a convenience thing - a home server might offer multiple EAP types because some client devices support one type, some other client devices another. And a client which supports several types has the choice which one to take.

All of what I wrote above of course depends that the expected home server is indeed configurable fine-grained enough. This definitely includes the server name (subject_match): Imagine your home server has a VeriSign certificate with the name "auth.example.com". You have configured that at home and are a happy user.
Now you roam to some other place. The other place also has an EAP server, with a certificate from VeriSign, and the server name being "haha.evil.com".
If the user has configured his supplicant to trust only the tuple "VeriSign+auth.example.com", then everything is fine - it will refuse to send its credentials to haha.evil.com.
If the user has only configured VeriSign - then the evil server could try to terminate the user's TLS tunnel, and ask for the user's credentials. No alarm bells will go off, because the subject_match isn't checked against the expectations. The user's supplicant will merrily send the user's credentials to haha.evil.com.

That makes subject_match *IMPORTANT*.

(And BTW: if the supplicant is then configured to do TTLS-PAP, his credentials will end up in clear text at haha.evil.com; if it does PEAP, there is at least an admittedly weak MSCHAPv2 encryption in place still. That makes PEAP arguably a bit more secure, with its second line of defence if you got the server-side verification wrong)

Created attachment 197220 [details] [review]
NM Patch to probe CA certificate

I've made a test patch for NM 0.9.2-beta1 to probe the server certificate. The patch utilizes the wpa_supplicant git commits 00468b4650998144f794762206c695c962c54734 and ade74830b45466abb41b8e8dbc2f595d8bacb793 to probe the server and send out the server certificate through a dbus signal. My goal is to set the subject automatically and replace cert_path with ca_cert="hash://server/sha256/<cert_hash>" if the user didn't provide any CA certificate.

The patch for nm-applet is still under working, and there are 2 plans for the applet.

Plan A:
Add 2 new entries, "subject" and "cert hash", and a "probe" button to the ui files of EAP-TTLS and PEAP.

Plan B:
Probe and set "subject" and "cert hash" silently after clicking "Connect".

As mentioned in the previous comment, Plan A will make the dialog even more crowded and this is bad for the machine with small screen, especially netbooks.

I tried to implement Plan B in applet-device-wifi.c:more_info_wifi_dialog_response_cb(), and it turned out the wifi dialog always blows away the 802.1x settings including my additional settings before starting the connection.

Any suggestion?

Hi,

one clarification first. You write it's a patch to probe the CA certificate. That's conceptually wrong (but maybe just a typo :-) )

The CA certificate is set in the supplicant by out-of-band action. It is not usually sent during the EAP handshake.

The *server* certificate is sent during the handshake. It is supposed to be issued by the configured CA.

So you can't probe the CA certificate, you can probe the server certificate only.

Ideally, a user didn't just set the CA certificate, he should also have set the subject_match - that way, the presented certificate is nailed to exactly the one server the user expects.

-> UI consequence: a string input field for subject_match needs to be present.

If a user did only specify the CA, not the subject_match, then your probing of the subject can help indeed by suggesting that name to the user.
Probing and setting silently is not very good because it doesn't make the user aware that there is something he's supposed to check. Supplicants typically show the presented server certificate to the user on first use, asking "is this what you expect".

-> UI consequence 1: provide a probe button which fills the string input field if solicited (=pushed) by the user
-> UI consequence 2: don't be silent - I'm undecided whether filling the string input field is alerty enough, or whether popup is more appropriate. Mac OS goes for a popup.

As per cert_hash or subject_match... these two are mutually exclusive options to verify the server:

1) issuing CA + subject of server cert = uniquely identifies the *server* perpetually (renewal of cert doesn't change this combination)

2) cert_hash = uniquely identifies *this particular certificate* until expiry
this is regularly annoying: a renewed certificate will create verification problems because its hash is different

Both paths can be implemented, but it doesn't make sense to have both in the same UI form. It's either a UI pane with two questions: 1) CA 2) subject
- or - it's just the question: is this particular certificate okay

So my ultimate suggestion is: *before* connecting, give user the opportunity to set CA and subject, or to probe the subject if he's lazy
*if* user connects without having set both, present him the certificate that came in the handshake, and ask if this particular certificate is okay.

That should enable both modes of operation, in the most unintrusive way I can come up with right now.

Greetings,

Stefan Winter

(In reply to comment #13)
> Hi,
> 
> one clarification first. You write it's a patch to probe the CA certificate.
> That's conceptually wrong (but maybe just a typo :-) )
> 
> The CA certificate is set in the supplicant by out-of-band action. It is not
> usually sent during the EAP handshake.
> 
> The *server* certificate is sent during the handshake. It is supposed to be
> issued by the configured CA.
> 
> So you can't probe the CA certificate, you can probe the server certificate
> only.
> 
> Ideally, a user didn't just set the CA certificate, he should also have set the
> subject_match - that way, the presented certificate is nailed to exactly the
> one server the user expects.
> 
The patch description might be misleading. The goal of the patch is to probe the *server* certificate. More precisely, it's for the subject and the hash of the server.

> -> UI consequence: a string input field for subject_match needs to be present.
> 
> If a user did only specify the CA, not the subject_match, then your probing of
> the subject can help indeed by suggesting that name to the user.
> Probing and setting silently is not very good because it doesn't make the user
> aware that there is something he's supposed to check. Supplicants typically
> show the presented server certificate to the user on first use, asking "is this
> what you expect".
> 
> -> UI consequence 1: provide a probe button which fills the string input field
> if solicited (=pushed) by the user
> -> UI consequence 2: don't be silent - I'm undecided whether filling the string
> input field is alerty enough, or whether popup is more appropriate. Mac OS goes
> for a popup.
> 
> As per cert_hash or subject_match... these two are mutually exclusive options
> to verify the server:
> 
> 1) issuing CA + subject of server cert = uniquely identifies the *server*
> perpetually (renewal of cert doesn't change this combination)
> 
> 2) cert_hash = uniquely identifies *this particular certificate* until expiry
> this is regularly annoying: a renewed certificate will create verification
> problems because its hash is different
> 
The first case is the ideal case. The cert_hash is actually a fallback option in my plan. If the user cannot set the CA properly, e.g. the RADIUS server is self-signed or the CA certificate is not available in the client system, the cert_hash will be used to identify the server. It's not perfect but better than nothing.

> Both paths can be implemented, but it doesn't make sense to have both in the
> same UI form. It's either a UI pane with two questions: 1) CA 2) subject
> - or - it's just the question: is this particular certificate okay
> 
Alright, so at least the subject entry must show.

> So my ultimate suggestion is: *before* connecting, give user the opportunity to
> set CA and subject, or to probe the subject if he's lazy
> *if* user connects without having set both, present him the certificate that
> came in the handshake, and ask if this particular certificate is okay.
> 
> That should enable both modes of operation, in the most unintrusive way I can
> come up with right now.
> 

How about this: I add the subject entry to the dialog and do a check after the user clicks "Connect". If the subject or the ca_cert is empty, nm-applet/g-c-c network panel issues a probe and then presents the user what it gets from the probe in a popup. If the user is OK for the server certificate, the related fields will be filled and the connection goes on. Otherwise, back to the settings dialog. The user can still change the subject and ca_cert later.

> How about this: I add the subject entry to the dialog and do a check after the
> user clicks "Connect". If the subject or the ca_cert is empty, nm-applet/g-c-c
> network panel issues a probe and then presents the user what it gets from the
> probe in a popup. If the user is OK for the server certificate, the related
> fields will be filled and the connection goes on. Otherwise, back to the
> settings dialog. The user can still change the subject and ca_cert later.

That sounds very good! I'm not sure where the cert_hash could come into play here though.

My take on it is:

- user has specified CA, but not subject, and clicks connect, probe happens

-> UI asks him "A certificate which matches your CA has been presented, and the subject is $subject - is that okay with you?"
-> if ok, subject_match will be added to config; the server will in the future be identified with the CA/subject combo

- user has not specified CA nor subject, and clicks connect, probe happens

-> UI asks user "Do you like this certificate?"
-> if ok, cert_hash will be added to config; the server will in the future be identified with that hash (CA and subject are then insignificant)

Is that in line with your thinking?

(In reply to comment #15)
> My take on it is:
> 
> - user has specified CA, but not subject, and clicks connect, probe happens
> 
> -> UI asks him "A certificate which matches your CA has been presented, and the
> subject is $subject - is that okay with you?"
> -> if ok, subject_match will be added to config; the server will in the future
> be identified with the CA/subject combo
> 
> - user has not specified CA nor subject, and clicks connect, probe happens
> 
> -> UI asks user "Do you like this certificate?"
> -> if ok, cert_hash will be added to config; the server will in the future be
> identified with that hash (CA and subject are then insignificant)
> 
> Is that in line with your thinking?

Yes, exactly :-)
The UI modification is minimized (just one more entry) and the user is also notified.

Excellent!

I guess when that's implemented, the feature req can be closed. I do have a couple comments on the UI design in general, but they are not so urgent. If you care enough, read on :-)

EAP authentication is always mutual, and most supplicants make the distinction between "server side auth" and "client side auth" in their UI.

This is helpful especially in the case of EAP-TLS. There's two certificates involved, one of them needing a private key, the other not, plus add the CA of the server-side. Putting all this into one simple widget is a bit confusing.

In an HTML form, I would probably do two <fieldset>s in the form: One for server side, which basically contains CA and subject of the server (it may contain more exotic things with other EAP types), and one for the client side. Or two consecutive dialogs, first server, then on a next page client.

The client side widget would ideally be dynamic with respect to which EAP type the user chooses. TTLS and PEAP have an *optional* client-side cert, and a *mandatory* username+password field. EAP-TLS only has the - then mandatory - client cert, but no username+password.

Conveying all that visually in a nice way is certainly not trivial, but IMHO it would do a lot of good for users. When I come across NM (well, KNM more often), I'm sometimes confused myself, and I tend to think I have a good grasp on all the concepts involved. Not sure how an innocent user will perceive that "option bloat".

CVE-2006-7246

I just discovered that wpa_supplicant only uses subject_match to check a _substring_ of the certificate’s name, which is rather useless security-wise.  If I configure subject_match to ‘wireless-radius-2.mit.edu’, wpa_supplicant will accept a valid certificate for ‘wireless-radius-2.mit.edu.evildomain.biz’.

We really need this to check against list of complete names, not just a substring.

http://w1.fi/bugz/show_bug.cgi?id=490

openSUSE is still carrying (updated) patches for this; is anything blocking their acceptance?

(In reply to comment #19)
> I just discovered that wpa_supplicant only uses subject_match to check a
> _substring_ of the certificate’s name, which is rather useless security-wise. 
> If I configure subject_match to ‘wireless-radius-2.mit.edu’, wpa_supplicant
> will accept a valid certificate for ‘wireless-radius-2.mit.edu.evildomain.biz’.
> 
> We really need this to check against list of complete names, not just a
> substring.
> 
> http://w1.fi/bugz/show_bug.cgi?id=490

Is there a bug in a NetworkManager or is this "just" a wpa_supplicant issue (that should probably be tracked here regardless)?

(In reply to comment #20)
> Is there a bug in a NetworkManager or is this "just" a wpa_supplicant issue
> (that should probably be tracked here regardless)?

NetworkManager is at least going to need changes to expose whatever new API wpa_supplicant comes up with.

Ideally, there would also be a UI for prompting on new certificates or certificate names and remembering approvals, to help the 99% of users who don’t know they should care.  The requirements of such a UI might influence the API we need from wpa_supplicant.

The #20 commenter's note was only about the substring matching for cases where certs get "properly" verified using a CA hierarchy and the server name, right?

There, the regex matching without enforcing end-of-string is IMHO a bug in wpa_supplicant. It might be mitigatable in NetworkManager, worth a try: whatever the user puts into the UI field could be suffixed with a $ to indicate that this is required to be the end of the string.

The #21 commenter's note seems to aim in a different direction; this would be about certificate pinning, where the user is prompted whether he likes the cert or not. This mode of operation really should not operate with the string that is the presented name. Names can be faked arbitrarily. It's the cert's fingerprint which is unique, and it's the only persistent handle. That mode of operation first needs to be supported and exposed by wpa_supoplicant before diving into more details. Suffice to say one thing: In order for cert pinning to work, UI must first ask the user for at least his username; the username is used for request routing purposes and will determine *which* certificate gets shown to the user. So it's a UI first (username) -> wpa_supplicant doing something -> UI comes back (ask password). Most UIs still ask for both beforehand, and release the details to the protocol when needed. I.e. release the username immediately, then wait for cert pinning confirmation by the user, and then release the password.

This issue is exploited in the wild and should be fixed. There is no way to implement secure WPA2 enterprise with these settings, so it is definitely more than enhancement.

wpa_supplicant has altsubject_match functionality which should be implemented for this. This matches the altSubjectName components, so specifying 'DNS:wireless.nikhef.nl' should be enough to check the subject of the certificate you're trying to connect to.

Indeed, subject_match should be deprecated, as a substring match is useless for security, but altsubject_match in wpa_supplicant does an exact altSubjectName component match.

The UI should always accomodate specifying who to connect to, as with any TLS session, one should ALWAYS check:

1. Is this certificate from the person I'm trying to connect to (subject)
2. Is the signature valid
3. Is the certificate not expired.

The absense of this field does not allow a secure configuration.

It is current best practise to implement public certificates on WPA2 enterprise, because this allows pinning of the CA and subject information on new devices. Especially on a large public network such as eduroam, this is extremely important.

At this point I recommend pinning the CA and subject on first connect to the RADIUS server. If there is only one altSubjectName, that should be pinned, if there are more or if the certificate is self-signed the certificate fingerprint could be pinned.

Do not pin the certificate fingerprint for valid signed signatures where the subject can be pinned, as this prohibits replacing the certificate with a new valid one and leads to problems every replacement. (Imagine 10k users having problems with the network at the same time).


-- Wilco Baan Hofman

To clarify Windows >= Vista behaviour:

If the certificate is signed by a public CA, upon first connect, the CA is pinned to the profile along with the CN from the subject.

This makes sure that Windows will not connect to networks it does not trust, nor will it leak it's credentials.

OS X's and IOS strategy depends on pinning the fingerprint, this works mostly, it has the benefit of putting the user in charge of at least clicking OK, but when the certificate is replaced because it is no longer valid. Everybody will need to click OK. In my view this is nice for self-signed certificates, but for public certificates there are better options (like pinning the CA + altSubjectName dNSName)

I also recommend dropping all support for subject_match. This only leads to insecure configurations.

In summary:
1. Add an option in the dialog for Connect only to these servers, using altsubject_match
2. Maybe add a checkbox for use System CAs (it's easier to configure)
3. If no CA and no subject is given, pin these at the first connection attempt. If the certificate is self-signed, pin the fingerprint.

Please fix this widely exploited security bug.

-- Wilco Baan Hofman

Dropping all support for subject_match is NOT a good idea. Some EAP methods lean towards using the Subject/CN rather than sAN:DNS. See for example Microsoft's guidance on issuing PEAP server certificates here:

http://msdn.microsoft.com/en-us/library/cc731363.aspx

Note how the Subject field is mandatory, while the sAN field is optional.

Like it or not, it is protocol-wise acceptable to create a deployment with a certificate which does not have a sAN configured. Blindly making NetworkManager UI bind the server name to altsubject_match will leave users of such deployed servers DoSed.

In eduroam, we do recommend to have the name both in Subject/CN and in sAN:DNS for maximum compatibility, so those of our identity providers (and their users) who follow our guidelines could live with the deprecation of subject_match; but there's more to WPA2 Enterprise than just eduroam.

I don't have a suggestion for NM UI; you are stuck between a rock and a hard place here.

IMHO, the better fix would be to improve wpa_supplicant by making the subject_match check more strict:

- only check inside the CN part of subject
- consider the configured string an /exact/ match of CN

This makes the substring match + evil suffix appended problem go away. It is something to take up with the wpa_supplicant authors though.

I was talking about subject_match as it is implemented now. 

I fully support matching the dNSName from subjectAltName with a CN fallback and only support *exact* matches.

subject_match as it is implemented now is nothing but dangerous.

I am already in contact with Jouni Malinen (wpa_supplicant author), about this issue (subject_match CVE-2015-0210). He tells me subject_match was never intended to be used for this purpose.

altsubject_match is, but he prefers the use of domain_suffix_match, which is already implemented, which unfortunately does not do an exact match, but a suffix match on the dNSName, both in CN and altSubjectName.

I believe we need something that does an exact match on both and have API that allows it to be pinned.

Regarding the UI, it is unacceptable that there is no GUI component which allows the checking of the identity of the other party. Any such configuration will be insecure and it is the main reason eduroam and others are vulnerable to attack.

Hi,

wpa_supplicant just committed a fix.

There is a new parameter called domain_match, which has the following behaviour:
It exact-matches against the DNS parts of subjectAltName and falls back to an exact CN match.

For the pinning behaviour, via dbus is now exposed the variable 'altsubject'. This makes sure that network-manager does not have to parse the certificate itself.

The following logic can thus be applied upon first connect:

1. Use provided CA. If no CA is provided, use the CA bundle.
2. Attempt to connect
3. If a server DNS name is provided, match it. Fail when it does not match.
4. If the CA is trusted, pin that CA. If not, fail. Warn the user if no CA was provided and the system CA store does not trust it.
5. If no server DNS name was provided, pin the one that was returned by the RADIUS server.

To be implemented to fix the security bug:
- a GUI component for server DNS name
- Pinning behaviour in Network Manager

-- Wilco

I forgot step 6: Pin the certificate fingerprint if the user does not provide a CA and it is not trusted.

-- Wilco

OK...

It sounds like we want to deprecate NMSetting8021x:subject-match and :phase2-subject-match, and add :domain-match and :phase2-domain-match.

We don't necessarily want to make everyone depend on the super-newest wpa_supplicant, so rather than actually using the new wpa_supplicant functionality, perhaps it makes more sense to use "ca_cert=probe://" and then have NM check the CA and/or server subject/domain/altsubject/hash/whatever itself. (Having the checking code in NM will also potentially make it easier to support the same verification options with VPN certificates later.)

I'm not totally sure where pinning belongs (in particular, how much of it should be in the UI vs the daemon).

(In reply to comment #31)
> We don't necessarily want to make everyone depend on the super-newest
> wpa_supplicant, so rather than actually using the new wpa_supplicant
> functionality, perhaps it makes more sense to use "ca_cert=probe://" and then
> have NM check the CA and/or server subject/domain/altsubject/hash/whatever
> itself.

Actually, it looks like that won't work because it doesn't wait for a response from the cert callback. So in particular in the TTLS case, it would likely end up sending the tunneled credentials before the cert callback had a chance to say "it's a trap!".

(In reply to Wilco Baan Hofman from comment #28)
> I am already in contact with Jouni Malinen (wpa_supplicant author), about
> this issue (subject_match CVE-2015-0210). He tells me subject_match was
> never intended to be used for this purpose.
> 
> altsubject_match is, but he prefers the use of domain_suffix_match, 

That's perfect because you can use more than 1 radius server, you just have to control the domain and make it specific (e.g. 1.radius.example.com and 2.radius.example.com, radius1.example.com would not work obviously).

> I believe we need something that does an exact match on both and have API
> that allows it to be pinned.
Exact match is fine but don't replace domain_suffix with it, we need both, it's common to have 2 radius servers.

A single domain_suffix_match would not work for the MIT SECURE wireless network, which uses

wireless-radius-1.mit.edu
wireless-radius-2.mit.edu

[1], but also gives out foo.mit.edu names and certificates to arbitrary affiliates including students [2].  I have no idea why they can’t just use two RADIUS servers configured with the same certificate, but in any event, neither of these points is likely to change.  And I don’t think this kind of setup is uncommon.

So we need to support configuring a list of domains.  Windows supports a semicolon-separated list [3].

[1] http://kb.mit.edu/confluence/x/YwBABw
[2] http://web.mit.edu/apache-ssl/www/README.certificate
[3] https://msdn.microsoft.com/en-us/library/dd759219.aspx

(In reply to Anders Kaseorg from comment #34)
> A single domain_suffix_match would not work for the MIT SECURE wireless
> network, which uses
> 
> wireless-radius-1.mit.edu
> wireless-radius-2.mit.edu

They could either change the names to radius{1,2}.wireless.mit.edu or use just one certificate for both (we do the latter), the problem is, that a secure configuration is impossible with boht solutions at the moment. With domain_suffix_match that would be possible if you choose your domains accordingly. domain_suffix_match is already available for wpa_supplicant, why is it hard to make it available for the NetworkManager? At least via a file in /etc/NetworkManager/systemconnections? That would enable scripts like CAT (see cat.eduroam.org) to create secure configuration files. 

The other suggested solutions (list of domains, exact match) are fine too, but why don't implement domain_suffix_match first, since it is available in wpa_supplicant?

I'm astonished, that this bug is going back to 2006, does nobody care about passwords?
Since subject-match is useless against man in the middle attacks, the fix should be almost as simple as search and replace subject-match with domain-suffix-match. 

Millions of students are using TTLS-PAP or PEAP-MSCHAP for WLAN authentication and they need something like domain_suffix_match to prevent man in the middle attacks. Please give that bug a higher priority, linux (together with android) is the last common operating system, that makes a secure configuration really hard (for most users impossible) and that's sad...

(In reply to Daniel Feuchtinger from comment #35)
> They could either change the names to radius{1,2}.wireless.mit.edu or use
> just one certificate for both (we do the latter),

How would you suggest I go about convincing them to make such a change?  Especially if it means all the Windows and Mac users on campus would need to go reconfigure their wireless settings again?  And even if they could do it without that (perhaps by simply dropping the wireless-radius-2 name), they’re probably just going to claim that such a change is too risky and benefits too few users, if they even say anything at all.

Branch bg/8021x-domain-suffix-match-bgo341323 implements two new properties 'domain-suffix-match' and 'phase2-domain-suffix-match' of NMSetting8021x which can be used to match a suffix of dNSName elements of altSubject or the SubjectName CN.

>> libnm-core: add domain-suffix-match properties to NMSetting8021x
    
maybe verify() should reject values of ""? At the very least, because ifcfg cannot distinguish them from NULL. (How does keyfile react on "")?

It seems that also nmcli is unable to read "". E.g. nmc_readline_helper() returns NULL instead of "".




     { "altsubject_match2",  TYPE_BYTES,   0, 0, FALSE,  NULL },
+    { "domain_suffix_match2", TYPE_BYTES,   0, 0, FALSE,  NULL },
                                           ^^
alignment? :) 



>> libnm-core: deprecate NMSetting8021x subject-match properties
    
commit message: "specify a a substring to be"


+NM_DEPRECATED_IN_1_2
 const char *      nm_setting_802_1x_get_subject_match...

This deprecates the API itself. I am not sure that is what we want. We want to discourage the usage of this property, not client applications to stop using the property. Seems a note in the documentation is sufficient.


Rest LGTM

(In reply to Thomas Haller from comment #38)
> >> libnm-core: add domain-suffix-match properties to NMSetting8021x
>     
> maybe verify() should reject values of ""? At the very least, because ifcfg
> cannot distinguish them from NULL. (How does keyfile react on "")?
> 
> It seems that also nmcli is unable to read "". E.g. nmc_readline_helper()
> returns NULL instead of "".
> Rest LGTM

Or just coerce the values?

+    case PROP_DOMAIN_SUFFIX_MATCH:
+         g_free (priv->domain_suffix_match);
+         priv->domain_suffix_match = value && value[0] ? g_value_dup_string (value) : NULL;
+         break;

(In reply to Thomas Haller from comment #38)
>      { "altsubject_match2",  TYPE_BYTES,   0, 0, FALSE,  NULL },
> +    { "domain_suffix_match2", TYPE_BYTES,   0, 0, FALSE,  NULL },
>                                            ^^
> alignment? :) 

Fixed.

> >> libnm-core: deprecate NMSetting8021x subject-match properties
> +NM_DEPRECATED_IN_1_2
>  const char *      nm_setting_802_1x_get_subject_match...
> 
> This deprecates the API itself. I am not sure that is what we want. We want
> to discourage the usage of this property, not client applications to stop
> using the property. Seems a note in the documentation is sufficient.

Ok, maybe deprecating the API is a bit drastic, but the property shouldn't be really used because it provides little security.

Anyway, I've dropped the commit and added a comment.

(In reply to Thomas Haller from comment #39)
> Or just coerce the values?

Fixed and repushed, thanks.

lgtm now

(In reply to Anders Kaseorg from comment #36)
> (In reply to Daniel Feuchtinger from comment #35)
> > They could either change the names to radius{1,2}.wireless.mit.edu or use
> > just one certificate for both (we do the latter),
> 
> How would you suggest I go about convincing them to make such a change? 

There's no need to convince anyone, they can decide for themselves. My point is, that you can not use NetworkManager to create a secure EAP-Connection without using a dedicated CA, even though wpa_supplicant has the required capabilities and the changes to NetworkManager would be small. 

Thanks a lot for the branch, I'll give it a try.

> libnm-core: add domain-suffix-match properties to NMSetting8021x

In the code doc for 'subject-match' and 'phase2-subject-match' I'd use "NMSetting8021x:domain-suffix-match" instead of just 'domain-suffix-match' to get nice gtkdoc links in the generated docs.

Also, for the phase2-subject-match property I think it was just C&P, but you probably want "NMSetting8021x:phase2-domain-suffix-match' when referring to the newer/better property.

The rest LGTM.

(In reply to Dan Williams from comment #43)
> In the code doc for 'subject-match' and 'phase2-subject-match' I'd use
> "NMSetting8021x:domain-suffix-match" instead of just 'domain-suffix-match'
> to get nice gtkdoc links in the generated docs.
> 
> Also, for the phase2-subject-match property I think it was just C&P, but you
> probably want "NMSetting8021x:phase2-domain-suffix-match' when referring to
> the newer/better property.

Fixed and merged to master:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e2040e5ebeae8e50e3f3b5a0e724fc9211866972

To clarify for anyone who finds this bug report, it looks like the new properties "altsubject-matches" and "domain-suffix-match" are supported in the configuration API but not exposed in the connection editor UI.  NetworkManager does not expose wpa_supplicant's "domain_match" parameter, but "altsubject-matches" is good enough as long as all RADIUS servers use modern certificates with a subject alternative name.

The easiest way to set the properties is probably from the command line:

nmcli connection modify CONNECTION_NAME +802-1x.altsubject-matches DNS:radius.example.com
nmcli connection modify CONNECTION_NAME 802-1x.domain-suffix-match example.com

(In fact, it looks like altsubject-matches was implemented back in 2011 (https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=0b8097a26a59ef0b2c0ab78f9ec3656e5681404b) but never announced in this bug thread!)

Correction: As pointed out at https://blog.wirelessmoves.com/2016/02/eduroam-wifi-with-a-certificate-and-cool-roaming-features.html, editing the connection using nm-connection-editor silently loses the new properties, so IMO we haven't provided a reliable solution to the original security problem for an end user who might be inclined to change some other property using the connection editor.  I filed bug 777225.  Regrets for the double post.