Bugzilla

Not set

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

Access our enterprise WPA/EAP wifi network. It uses a radius server with an internal CA.

Actual results:

The phone asked for my user and password, and accessed the network correctly.

Expected results:

I should have got either an option to specify a valid CA certificate file (as Android does) or a warning about accepting an unknown CA (as iOS does). 

As it stands now, we're not getting any real security from using certificates on the network side, so for all practicals senses we're wide open to MiTM attacks.
Blake, this sounds like your bug.
Note that we're using a valid, trusted certificate for the wifi at Mozilla (not internal, it's signed by GeoTrust)

As B2G/Android use WPA Supplicant, this has to be pinned via the ca_cert="..." option of WPA Supplicant (it does not does it on its own)

The "correct" behavior is to show that to the user (like MacOSX does), and ask the certificate to be pinned for this AP.

The reason for this is that via WPA, even thus the certificate is trusted (signed by a trusted CA) it could be *any* trusted certificate, and the user doesn't know which domain is being trusted.
(In reply to Guillaume Destuynder [:kang] from comment #2)
> The reason for this is that via WPA, even thus the certificate is trusted
> (signed by a trusted CA) it could be *any* trusted certificate, and the user
> doesn't know which domain is being trusted.

Yes, I agree.

Note that wpa_supplicant uses its own TLS implementation and its own certificate database by default. I filed bug 789217 for integrating wpa_supplicant with NSS.

The UI for this must clearly indicate the domain name and whether or not the certificate is considered valid.

Note that many organizations use a self-signed or otherwise not-CA-issued certificate for their WPA Enterprise systems. (Mozilla Corp. did this until last year.)
This might actually be LOE:M, especially since this is going to need frontend work as well.
To be honest, I don't think support for WPA Enterprise with certificates support needs to be a blocker at all, given the intended demographics of the device. WPA enterprise support definitely isn't a higher priority than FOTA updates and many other things.

Why not just disable support for WPA enterprise with certificates, and make the bug to re-enable it a lower-priority bug that we're likely to punt on?
(In reply to Brian Smith (:bsmith) from comment #5)
> Why not just disable support for WPA enterprise with certificates, and make
> the bug to re-enable it a lower-priority bug that we're likely to punt on?

Whether or not we need such support is more of a product decision. If we were to disable it, we'd probably need to leave support in somewhere so that people in the Mozilla offices can continue using the wifi here.
(In reply to Blake Kaplan (:mrbkap) from comment #6)
> (In reply to Brian Smith (:bsmith) from comment #5)
> > Why not just disable support for WPA enterprise with certificates, and make
> > the bug to re-enable it a lower-priority bug that we're likely to punt on?
> 
> Whether or not we need such support is more of a product decision. If we
> were to disable it, we'd probably need to leave support in somewhere so that
> people in the Mozilla offices can continue using the wifi here.

I agree that there's a dogfooding issue. On the other hand, we have the non-WPA-Enterprise, public network in the office that people can use. And, actually, it is more important for us to be dogfooding on *that* network anyway, because it is more similar to the kind of network that the device users will commonly be connecting to.
Lucas/Blake/others - what is the real user risk here by not supporting this properly and exposing our users to MiTM attacks?  Do we have a good sense of how likely this would happen?
(In reply to Chris Lee [:clee] from comment #8)
> Lucas/Blake/others - what is the real user risk here by not supporting this
> properly and exposing our users to MiTM attacks?  Do we have a good sense of
> how likely this would happen?

I have only a vague understanding of the WPA protocol, but here's my understanding nonetheless:

Let's say you have your phone configured to automatically log into the Mozilla wifi network. Assuming the phone's wifi system works like my laptop, if you don't do any certificate checking at all, then anybody could set up a (mobile) wifi network that would then be able to automatically steal your LDAP password, while your phone is sitting in your pocket with wifi on. So, the handling of the certificate is pretty important.
For all practical purposes, it basically negates network encryption.  This is a blocker unfortunately.
(In reply to Lucas Adamski from comment #10)
> For all practical purposes, it basically negates network encryption.  This
> is a blocker unfortunately.

See bug 790054. If we fix bug 790054, by disabling WPA enterprise support, then this will not be a blocker any more. (There's already a bug, bug 790056, to re-enable it after this bug gets fixed, and this bug is blocking 790056.)
> See bug 790054. If we fix bug 790054, by disabling WPA enterprise support,
> then this will not be a blocker any more. (There's already a bug, bug
> 790056, to re-enable it after this bug gets fixed, and this bug is blocking
> 790056.)

Does Mozilla corp use WPA enterprise?  What types of use cases do we lose when connecting to WiFi if we fix bug 790054?
(In reply to Chris Lee [:clee] from comment #12)
> Does Mozilla corp use WPA enterprise?  What types of use cases do we lose
> when connecting to WiFi if we fix bug 790054?

The result would be that the B2G devices can connect to "Mozilla Guest" but none of the other Wifi networks.

WPA enterprise with X.509 certs is an "enterprisy" thing; not many users are exposed to it. (Mozilla's internal wifi network is the only WPA Enterprise network I've ever used in my whole life.) The most likely place a user would want to connect to a WPA enterprise network is (a) a corporate intranet, and/or (b) a university. 

If you Google for "wpa enterprise android" you will see various claims that WPA enterprise works or doesn't work on various android devices, and that it is not officially supported. I don't know what the actual state of "official" support of WPA enterprise on Android is, but the unofficial state is that, at a minimum, it is too confusing for many of their users to figure out, even if it is possible.
I think we have more important things to work on than this.
I agree.  I would fix bug 790054 and will mark that + and this -.
A few notes about this, while I'm not making decisions regarding whether or not this should be a priority, I want to make sure the way this is working on Android is understood (and hopefully whenever this is implemented, we can do something better)

WPA 802.1x EAP works on Android (at least in JB, ICS and GB), but they do NOT check the certificate by default IF the phase 2 authentication is password-only. I've not seen any recent device with support of the above OS version that did not support it (albeit I only used popular phones from Sony/Samsung/HTC, since carriers can mess up the OS, it could be some devices do not work properly with it).

This is called phase 2 authentication, as there is a secure tunnel being created, which can be TLS, TTLS, PWD or PEAP (we use PEAP at mozilla, which means password-extended-authentication-protocol), and user authentication is made on top of that tunnel (PAP, MSCHAP, MSCHAPV2, GTC, we use MSCHAPV2 at mozilla currently - there are more extensions on non-Android platforms). Another "common" setup is EAP-TLS which requires a user certificate.

Again, as long as there's no user certificate, Android (in fact, wpa_supplicant) will not complain about the lack of a pinned server certificate, will not pin the server certificate on first connection, and thus will just work. In some configurations this is potentially insecure as the device may connect to a rogue AP, and attempt to authenticate, as described in previous comments (PWD and MSCHAP/V2 being an issue).

If a user certificate is required, or if one wants to have proper server certificate checking,  it's where the pain begin.

One has to have a specially formatted certificate (that includes finding the certificate and converting it usually- that's where most users give up), copy it on the sdcard, and import it in the trusted credential section (settings/security/credential storage), then go in the wifi settings and select it.
Instead of removing the whole feature, could not we provide a solution similar to what iPhone does, quoting Antonio "displaying a warning about accepting an unknown CA". 

If we remove the feature as suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=790054 the device could not use any the WiFis offered by Telefónica or even those ones used in Spanish Universities. I think this is a very radical approach.
(In reply to Daniel Coloma from comment #17)
> Instead of removing the whole feature, could not we provide a solution
> similar to what iPhone does, quoting Antonio "displaying a warning about
> accepting an unknown CA".

Adding the feature back is WebAPI:P2, which means it is a high priority. Of course we should add the feature back with an acceptable UX if we have time. I suggested removing it first because there is a big risk we will not be able to create an acceptable UX in time.

> If we remove the feature as suggested in
> https://bugzilla.mozilla.org/show_bug.cgi?id=790054 the device could not use
> any the WiFis offered by Telefónica or even those ones used in
> Spanish Universities. I think this is a very radical approach.

Does Telefonica offer WPA2-enterprise-based wifi in *Brazil*? I don't think we have to worry about Spanish Universities because they are not in Brazil.
> Does Telefonica offer WPA2-enterprise-based wifi in *Brazil*? I don't think
> we have to worry about Spanish Universities because they are not in Brazil.

I have just provided you some examples of population segments that could not use their WiFis because of this feature removal in Spain, that is the market I know more. I am pretty sure that this will be also the case in Brazil.

Additionally, there are around 10-12 Gaia developers that need this feature if they want to use WiFi at work. I think we should worry about it. 

Last but not least, Telefónica is the carrier that will launch this device, and it is based in Spain, we would like to foster a community of developers in *Spain*... and for that, we are arraging events at Spanish Universities. Not supporting the WiFi they have there would be definitely a very bad idea.
I don't know if there's a way to link bugs that doesn't exactly block or depend on one another, but it seems that currently the argument about this is split on 4 different bugs: 
* This one
* Bug 789217 that asks for integrating NSS into wpa_supplicant
* Bug 790054 that asks for just disabling WPA Enterprise support on V1 completely
* Bug 790056 that tracks the reenabling task once the problem is solved one way or another

And not everybody cced here is cced on the others. 

I've offered ourselves on one of the other bugs to tackle this so we can ship WPA enterprise on V1. One way to do that would be implementing a partial solution to Bug 789217. We can either:

a) Add support to use the NSS trust certificate store as a certificate store for wpa_supplicant certificate validation, as they do with Microsoft CryptoAPI stores for Windows
b) Add an exporting step to the device booting up process. This way on the device boot up we can just export the NSS trust database to the format wpa_supplicant already uses. This solution has the advantage of not having to add and maintain code to wpa_supplicant.
c) Implement a complete replacement for the TLS implementation to use NSS instead. This is what was proposed at https://bugzilla.redhat.com/show_bug.cgi?id=348471 but that seems to be dead (bug's from 2007, and last update was from 2008).

We (TEF if you wish us to take this) can either implement a or b for V1, plus adding some way to add extra user-provided certificates. Or just the later (that's what Android do, AFAIK). 

What do you think?
I talked with Blake and we're definitely fine with you (or anyone else) taking this bug.

However it's unlikely that anyone at mozilla will have time with helping out with getting a working patch. We'd have to find the resources to review of course, but unfortunately I don't think we'd be able to help more than that.

If that's fine with you, then definitely feel free to assign the bug to yourself and start working on it.
(In reply to Jonas Sicking (:sicking) from comment #21)
> I talked with Blake and we're definitely fine with you (or anyone else)
> taking this bug.
> 
> However it's unlikely that anyone at mozilla will have time with helping out
> with getting a working patch. We'd have to find the resources to review of
> course, but unfortunately I don't think we'd be able to help more than that.

That's cool, I can tackle this myself. What I do need, though, is to reach an agreement regarding my proposed solutions (on comment 20). I need to know they're acceptable before implementing them, and if you prefer us implementing solution a or b (I don't think we have time to implement solution c for V1).

My personal preference, at this moment, is to just implement solution b (boot-time export of the NSS database to WPA format) because it doesn't involve making (and either propagating upstream or keeping it updated manually) changes to wpa_supplicant at this stage. If you prefer me to implement solution a that will be ok too.

So... is either solution a or b acceptable to you? And which one do you prefer?
I don't know what's good/acceptable solutions. All I know is that anything certificate related tends to be very sensitive.

Brian or Blake are better people to ask.
The much bigger task is developing a UI that makes sense. Perhaps it would be enough to do something like:

* Above the username/password fields, display the hostname, using location-bar like highlighting of the TLD+1 (so subdomains are shown de-emphasized) and with location-bar like lock/no-lock indicators to the left.
2. If the certificate doesn't validate successfully, explicit statement that says that the server is untrusted.

By the way, what (extended) key usage would we validate the certificate for? Is there a special policy OID for certs that are to be used for WPA auth?
(In reply to Brian Smith (:bsmith) from comment #24)
> The much bigger task is developing a UI that makes sense. Perhaps it would
> be enough to do something like:
> 
> * Above the username/password fields, display the hostname, using
> location-bar like highlighting of the TLD+1 (so subdomains are shown
> de-emphasized) and with location-bar like lock/no-lock indicators to the
> left.
> 2. If the certificate doesn't validate successfully, explicit statement that
> says that the server is untrusted.
> 
> By the way, what (extended) key usage would we validate the certificate for?
> Is there a special policy OID for certs that are to be used for WPA auth?

For server certs, AFAIK they have to be id-kp-serverAuth (or null, since no extended key usage==all key usages allowed by keyUsage). And for client certs (which I don't think we're going to support in V1), they have to be id-kp-clientAuth.

For servers, any cert that's valid for a TLS server should be valid for a EAP-TTLS connection.

In any case, WPA_supplicant already has the certificate validation logic in place. I'm not going to touch that (since I assume it works :) ) for this bug, I'm just going to allow wpa_supplicant to use B2G's trust database (NSS database) as trust anchors. 

I can do that two ways: 

a) I can just add code to wpa_supplicant to use NSS as a trusted certificate store, just as wpa_supplicant can use Microsoft CSP certificate store now. This would not be that hard to implement, I think, but it would require somehow making the patch part of the standard wpa_supplicant, or the repository we get that from, and I don't know the procedure for that. 
b) Or I can just export the NSS trust database to the wpa_supplicant supported format at phone startup time.  

Additionally, and for any of those two solutions, I intended to have a way for users to manually add a trust anchor (a CA certificate in other words) when they add a new Wifi connection, since otherwise anyone that doesn't use a public CA is out of luck.

That would take care of the verifying part. Now, for the user feedback information, I don't think we can do it as you propose since I believe the authentication is an atomic operation from Gaia point of view. We fetch the parameters, invoke wpa_supplicant, and it either succeeds or fails (because the certificate wasn't trusted or because the username and password was incorrect). What we can do is just to inform the user of any certificate related failure: untrusted or unknown certificate, and also show him the data of the offending certificate. 

Now I repeat my original question: Is either a or b an acceptable solution for allowing wpa_supplicant to use the NSS database to verify server certs? And which one would you prefer me to implement?
I didn't realize that this requires additional UI :( That means involving yet more people in reviewing and designing and translating whatever UI that is added.

Is there any way we can add minimal support here without UI? If not I think we need to punt this to v2.
(In reply to Jonas Sicking (:sicking) from comment #26)
> I didn't realize that this requires additional UI :( That means involving
> yet more people in reviewing and designing and translating whatever UI that
> is added.
> 
> Is there any way we can add minimal support here without UI? If not I think
> we need to punt this to v2.

You have to at least tell the user what website they are sending their username/password to. (This is effectively the same thing as the HTTP auth dialog box.)

[Quoted out of order]

> That would take care of the verifying part. Now, for the user feedback
> information, I don't think we can do it as you propose since I believe the
> authentication is an atomic operation from Gaia point of view. We fetch the
> parameters, invoke wpa_supplicant, and it either succeeds or fails (because
> the certificate wasn't trusted or because the username and password was
> incorrect). What we can do is just to inform the user of any certificate
> related failure: untrusted or unknown certificate, and also show him the
> data of the offending certificate. 

The user must know whether the certificate validation succeeded or failed, and the name of the website, before they type in their username and password, to be consistent with all the other username/password UI we have (I hope we have similar UI for other password prompts in B2G already). We must be careful that we do not train users to type their passwords into any dialog box that pops up asking for it without caring where the password will be sent to.

One simple say of doing this is to connect to the network before prompting for the username/password, then retrieve the auth server hostname and certificate chain, then cancel the connection (e.g. return "not a trusted cert" in the cert verification callback), then return the cert chain and hostname to Gaia. Then, Gaia can validate the certificate chain using our existing Gecko APIs and then show the username/password prompts with the correct security indicator + auth server hostname. Then, if/when the user chooses to continue, Gaia can pass the expected hostname and the hash of the expected EE key down to the wpa_supplicant layer, and then our wpa_supplicant cert auth callback can use that hash of the expected EE certificate to validate the cert chain. (When the server changes certificates, then this will fail, and we'll have to handle this similar to the "first contact" case.) This way, we don't have to integrate NSS with wpa_supplicant at all, because all of the server cert verification would actually happen within Gecko.

(In reply to Antonio Manuel Amaya Calvo from comment #25)
> a) I can just add code to wpa_supplicant to use NSS as a trusted certificate
> store, just as wpa_supplicant can use Microsoft CSP certificate store now.
> This would not be that hard to implement, I think, but it would require
> somehow making the patch part of the standard wpa_supplicant, or the
> repository we get that from, and I don't know the procedure for that.

IMO, this is exactly as much (or more) work as just having WPA supplicant use NSS's APIs for validating certificates, unless wpa_supplicant already has a PKCS#11 client implementation for certificate databases, because NSS's cert database is exposed only through PKCS#11 or the NSS certificate library.

> b) Or I can just export the NSS trust database to the wpa_supplicant
> supported format at phone startup time.  

> Additionally, and for any of those two solutions, I intended to have a way
> for users to manually add a trust anchor (a CA certificate in other words)
> when they add a new Wifi connection, since otherwise anyone that doesn't use
> a public CA is out of luck.

Again, it is very simple to use the existing NSS certificate APIs to say "import this root as a trust anchor," using the same library that provides the certificate validation functions.

> Now I repeat my original question: Is either a or b an acceptable solution
> for allowing wpa_supplicant to use the NSS database to verify server certs?
> And which one would you prefer me to implement?

In order of decreasing preference:
1. The way I suggested above
2. Have the wpa_supplicant cert auth callback use NSS's CERT_VerifyCert directly.
3. a
4. b
I really don't know much about how WPA/EAP Enterprise works, but it really sounds to me like this is going to add too much risk and work for various people.

This bug has been agreed not to be a blocker, and it seems to me at this point that even a minimal solution here will add a bunch of work to a number of people as well as add risk.

So we need to simply punt this to v2.
(In reply to Jonas Sicking (:sicking) from comment #28)
> So we need to simply punt this to v2.

Punt on which part, exactly? It seems like a bad idea to ship the status quo (for the reasons given in comment 0).
Ok, going back to basics, what Brian suggests might give the best user experience, but it isn't something we can board for V1. And, in fact, it isn't something that any WPA implementation I know of actually does. 

FWIW, both iOS and Android ask for the password before trying to connect, and IIRC even Windows does the same thing (I can't verify that now, since I don't have a WPA Enterprise configured at home, but I can check tomorrow at the office). 

What I think we *can* do for V1 is something similar to what both iOS and Android offer:

1 Ask the username and password when the user selects join, as it is now. 
2 Try to connect, as it is now, but configuring wpa_supplicant so it actually do verify the server certificate.
3 In case of error, check if it's a username/password error and treat it like it's being treated currently.
4 If it's a certificate error, show an informative error to the user

To allow self signed and private CA certificates, we can add a certificate field to the current form at step 1 (as Android does, IIRC), or we can just allow the user to choose whether he wants to accept the untrusted certificate on step 4 or not (as both Android and iOS do). 

I think we can implement the described solution for V1, without adding risk (the option to disable WPA Enterprise is always there, after all). What I would like to know here is if this solution is acceptable for V1 or not. As I said, there isn't enough time to implement Brian's proposed solution, nor a complete replacement of openssl by NSS.
(In reply to Antonio Manuel Amaya Calvo from comment #30)
> Ok, going back to basics, what Brian suggests might give the best user
> experience, but it isn't something we can board for V1. And, in fact, it
> isn't something that any WPA implementation I know of actually does. 
> 
> FWIW, both iOS and Android ask for the password before trying to connect,
> and IIRC even Windows does the same thing (I can't verify that now, since I
> don't have a WPA Enterprise configured at home, but I can check tomorrow at
> the office). 
> 
> What I think we *can* do for V1 is something similar to what both iOS and
> Android offer:
> 
> 1 Ask the username and password when the user selects join, as it is now. 
> 2 Try to connect, as it is now, but configuring wpa_supplicant so it
> actually do verify the server certificate.
> 3 In case of error, check if it's a username/password error and treat it
> like it's being treated currently.

This part seems ok given that it's all existing UI.

> 4 If it's a certificate error, show an informative error to the user

This I'm less sure is a requirement. Simply acting like we're unable to connect seems ok to me. Though if it's very simple to do this then it *might* be ok to do.

> To allow self signed and private CA certificates, we can add a certificate
> field to the current form at step 1 (as Android does, IIRC), or we can just
> allow the user to choose whether he wants to accept the untrusted
> certificate on step 4 or not (as both Android and iOS do). 

This part I definitely think is too complicated to add for v1. If we allow the user to add a self-signed cert to the certificate store, then I think we also need UI to allow the user to manage this cert, no? At that point things quickly get complicated.

> I think we can implement the described solution for V1, without adding risk
> (the option to disable WPA Enterprise is always there, after all). What I
> would like to know here is if this solution is acceptable for V1 or not. As
> I said, there isn't enough time to implement Brian's proposed solution, nor
> a complete replacement of openssl by NSS.

I'll defer to Brian here since I don't know the security implications of not implementing what he is suggesting.
Sorry for the late update, I've been building a test environment so I can switch the Radius certificate freely.
I've tested the OS I have (Windows 7, iOS, Android 2.x and 4.0) and in all of them the username and password is asked *before* contacting the AP (and thus before knowing the certificate of the autentication server). Then of course if the certificate doesn't validate correctly the username isn't actually sent. Even if this is not a perfect solution, it seems to be a good enough solution for other current OSes, so I think it's a good starting point. 

What I can implement for V1 is...:

1 Import the NSS database into wpa_supplicant, the same way the CryptoAPI one is imported currently on Windows.
2 Add a field to the log parameters screen so if an internal CA is used the user can provide it. This is what Android currently does 

A certificate will be considered valid if it checks because of 1 or 2. This means that having a CA will be mandatory. On Android, on the other hand, the user can provide the CA or not. If he provides a CA then the certificate is validated, otherwise it validates always. If you prefer this behavior (it's less secure, but it's easy for most users also), I can just skip step 1 and just add a certificate field to the login screen.

Is any of these (barebones Android or NSS database plus user selected certificate) good enough for V1?
What I've finally done so far is to implement just what Android does. That is:
* There's a new field (select) on the settings wifi screen to (optionally) add a CA certificate file.
* The new select field is auto-populated with the files from /sdcard/certs.
* If the new field is left to 'Undefined' then WPA EAP behaves just as it does now (and as Android does) that is it accepts any Radius certificate as valid
* If the new field is assigned a value (that is a file from /sdcard/certs) is selected, then that file has to include at least a CA (works if it has several CAs in PEM format also) and the radius cert will be accepted *only* if it's signed by a CA included in the selected file.
* In any case, the radius name isn't checked on the certificate (but I don't really think it can be checked anyway). 

With the current version there's no error feedback for users. Then again, I'm not getting any feedback when the password is incorrect either.

I know this solution is far from optimal, but it gives us a solution that's equivalent to what Android currently has, and IMO it allows us to ship WPA EAP on V1 (V1 is as good as Android, V2 can be better ;) ).
Gaia part is here:

https://github.com/AntonioMA/gaia/commit/cee8150f9343d01e89feab7e3fc2c6e62a4bafd6

It's also a WIP. Between other things I currently use XHR (system) to read the file list and should probably use the Device Storage API instead. In any case, it gives you an idea of what I'm shooting for.

I'm renoming this since I think we can (and should) do this for V1 instead of dropping support for EAP. Note that while I've marked this as a WIP, it's totally functional as it is already.
Comment on attachment 686094 [details] [diff] [review]
WIP, B2G side

Review of attachment 686094 [details] [diff] [review]:
-----------------------------------------------------------------

Punting to Brian as I don't know enough about this code to have an opinion.
The second version of the implementation for the frontend, based on the DeviceStorage API instead of XHR is on:

https://github.com/mcjimenez/gaia/commit/d365b4b3ace79fae59fb0b7d1d3d6b003286648b
We will not be landing this in B2G v1.0 for the following reasons:

* This is not a v1 requirement
* This is taking reviewer and engineering resources away from v1 requirements
* This increases the scope of v1, and increases the chance for unnecessary regressions
* If internal testing is more difficult without this patch, internal testing procedures should change (not code)

Please follow up in email (b2g-release-drivers@mozilla.org) about this decision if any of the above logic sounds off, to prevent the comments in this bug from having a product focus instead of an engineering focus.
CC'ing Mozilla Netops to read through and comment on the implications, if any of so many devices having to use Mozilla Guest.
Wikimedia's office network is switching to WPA Enterprise as well, so this is affecting my ability to test on my unagi device. I can work around by tethering to another device for now, though.
Comment on attachment 686094 [details] [diff] [review]
WIP, B2G side

Review of attachment 686094 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.
This got feedback, can we get it reviewed and checked in?
+1
We don't have a proper way(Module and API) to manage server certifications, providing functions like import, list, delete, read, etc. Without these functions, we can't form a flow for user to configure WAP-EAP.
Also, wpa_supplicant might need be modified to read the imported certification.

WAP-EAP mode can't get up to work with this patch along.

The key manager part is working on bug 867899, and I am working on wpa_supplicant part on bug 789217
I'm new to Firefox OS, and unfamiliar with its internals. My interest for enterprise wifi is because I'm part of the eduroam community (http://eduroam.org). My apologies in advance if what I'm asking/proposing is nonsense... I'd just like to ask if a different approach is possible. 

How is the list of preferred networks stored? are these normal wpa_supplicant configs? I ask this because the approach by Apple (provisioning profiles contained in an XML file) is more interesting IMHO.

I mean by this: you don't have a (complex) GUI for configuring Enterprise wifi in iOS (that possibility very often confuses the user who can create wrong -and often unsecure- configs... I have seen lots of examples in different OSs), in stead you use an XML profile for doing this, crafted by an administrator who knows the internals of the Enterprise mode in use by the organization. If you want to trust the certificates contained you just sign the XML file. Finally, there's no need to expose an API (other than the provisioning API, which is just the schema for the XML file). 

On the contrary, Android's approach (the one I think is being followed here) is more complex... you have to create an API exposing a subset of all the possibilities wpa_supplicant already supports, and also have to create a GUI that supports these possibilities (not to mention all the certificate handling part). Another problem related with exposing an API for this, is the high number of useless apps in the Android market for configuring enterprise wifi, when the most basic problem hasn't yet been resolved (until recently the API didn't provide a way to check the certificate subject, and the GUI still -as of 4.3- lacks this possibility). do we want this? 

wpa_supplicant already does enterprise wifi very well, and also handles certificates, is it really necessary to duplicate this effort? can this be avoided?
(In reply to José M. Macías from comment #44)
> How is the list of preferred networks stored? are these normal
> wpa_supplicant configs? I ask this because the approach by Apple
> (provisioning profiles contained in an XML file) is more interesting IMHO.

Now these networks are stored as wap_supplicant config, and might move out of it and save in other place some day in the future(bug 786741).

> I mean by this: you don't have a (complex) GUI for configuring Enterprise
> wifi in iOS (that possibility very often confuses the user who can create
> wrong -and often unsecure- configs... I have seen lots of examples in
> different OSs), in stead you use an XML profile for doing this, crafted by
> an administrator who knows the internals of the Enterprise mode in use by
> the organization. If you want to trust the certificates contained you just
> sign the XML file. Finally, there's no need to expose an API (other than the
> provisioning API, which is just the schema for the XML file). 
>
> On the contrary, Android's approach (the one I think is being followed here)
> is more complex... you have to create an API exposing a subset of all the
> possibilities wpa_supplicant already supports, and also have to create a GUI
> that supports these possibilities (not to mention all the certificate
> handling part). Another problem related with exposing an API for this, is
> the high number of useless apps in the Android market for configuring
> enterprise wifi, when the most basic problem hasn't yet been resolved (until
> recently the API didn't provide a way to check the certificate subject, and
> the GUI still -as of 4.3- lacks this possibility). do we want this? 
> 
> wpa_supplicant already does enterprise wifi very well, and also handles
> certificates, is it really necessary to duplicate this effort? can this be
> avoided?

I think you are using UI(UX) to judge API, but they are for different purposes and can't be judge like this.

For API, it is designed to provide app developers full control of the system.
As far as I know, iOS provide no API for wifi, Android and Firefox OS APIs are providing control of wpa_supplicant to developer, not make a duplicate of it.
And I can view detail of my imported CA in Android settings->security->trusted CA, I think there is an API for that in Android.(Which is not supported on Firefox OS)

One the other hand, the "XML-importing method" in iOS and "complex setting GUI"/"Useless apps" in Android/Firefox OS, are about UI(UX) and independent of API.
You can build an easy-to-use settings app based on these "complex" APIs, including a customized "XML-importing method" function.

So if you are proposing a "XML-importing method" for wifi, I think it's can(and should) be implemented by app with wifi APIs, unless there is a standard for that.
(In reply to Chuck Lee [:chucklee] from comment #45)

> Now these networks are stored as wap_supplicant config, and might move out
> of it and save in other place some day in the future(bug 786741).

Ok, and I see the problem... for example protecting sensitive information (passwords, psks,...) inside the config. Anyway the problem of protecting sensitive information is hard to solve, I'm afraid... all you can do for this (without having to ask a password everytime a user wants to join a network) is to obfuscate the configuration...

> I think you are using UI(UX) to judge API, but they are for different
> purposes and can't be judge like this.

Well, not exactly. My exact -personal- opinion is that complex UIs can make harm in hands of unexperienced users, and complex APIs can slow the pace of development... 

> For API, it is designed to provide app developers full control of the system.
> As far as I know, iOS provide no API for wifi, Android and Firefox OS APIs
> are providing control of wpa_supplicant to developer, not make a duplicate
> of it.

iOS does not provide an API for wifi, true, but they provide a 'provisioning API', and that's what I'm in favor of... :)

Probably a duplicate is not what I wanted to say. I'd be happy with a one-to-one mapping of wpa_supplicant --help <-> wifi API. But I think that very often APIs are provided just to "be able to control everything" via the API, and put more power in hands of the developers than in hands of the user itself (and you get developers doing things that probably users woudln't want to do). My main argument is that this is basic system functionality, and should be covered by the system UI(UX)... offering an API to developers should be secondary.

> And I can view detail of my imported CA in Android
> settings->security->trusted CA, I think there is an API for that in
> Android.(Which is not supported on Firefox OS)

Well, sort of... the history of API versions in Android is also a nightmare... :)

> One the other hand, the "XML-importing method" in iOS and "complex setting
> GUI"/"Useless apps" in Android/Firefox OS, are about UI(UX) and independent
> of API.

I'm not completely against a complex UI for wifi set up... wifi can be hard to set up and hence you may need complexity in the UI. But I also think that many users just don't know 'what to put in all those fields', while surely an administrator knows, and could provide not one app (think in an app for every organization wanting to use enterprise wifi!), but a config to be imported to the devices.

> You can build an easy-to-use settings app based on these "complex" APIs,
> including a customized "XML-importing method" function.

That would suffice for me, but I don't think it's as easy as converting an xml config to the wpa_supplicant equivalent. I'm thinking for instance in EAP-TLS, where you have to provide client certificates... which is not exactly the same as trusting CA certificates.

> So if you are proposing a "XML-importing method" for wifi, I think it's
> can(and should) be implemented by app with wifi APIs, unless there is a
> standard for that.

Good for this! 

And... there's no standard for that, but in eduroam we have been talking about a way to do this that we would want to propose as a standard. I'll let the persons behind this know about this bug... :)
(In reply to José M. Macías from comment #46)
> (In reply to Chuck Lee [:chucklee] from comment #45)
> 
> > Now these networks are stored as wap_supplicant config, and might move out
> > of it and save in other place some day in the future(bug 786741).
> 
> Ok, and I see the problem... for example protecting sensitive information
> (passwords, psks,...) inside the config. Anyway the problem of protecting
> sensitive information is hard to solve, I'm afraid... all you can do for
> this (without having to ask a password everytime a user wants to join a
> network) is to obfuscate the configuration...

I agreed with you.
But wpa_supplicant needs these information in plain text, we have to revert these obfuscated data for it. That's the hole for the entire protection.

> > I think you are using UI(UX) to judge API, but they are for different
> > purposes and can't be judge like this.
> 
> Well, not exactly. My exact -personal- opinion is that complex UIs can make
> harm in hands of unexperienced users, and complex APIs can slow the pace of
> development... 
>  
> > For API, it is designed to provide app developers full control of the system.
> > As far as I know, iOS provide no API for wifi, Android and Firefox OS APIs
> > are providing control of wpa_supplicant to developer, not make a duplicate
> > of it.
> 
> iOS does not provide an API for wifi, true, but they provide a 'provisioning
> API', and that's what I'm in favor of... :)
> 
> Probably a duplicate is not what I wanted to say. I'd be happy with a
> one-to-one mapping of wpa_supplicant --help <-> wifi API. But I think that
> very often APIs are provided just to "be able to control everything" via the
> API, and put more power in hands of the developers than in hands of the user
> itself (and you get developers doing things that probably users woudln't
> want to do). My main argument is that this is basic system functionality,
> and should be covered by the system UI(UX)... offering an API to developers
> should be secondary.
> 

I have tried the iPhone Configuration Utility on PC.

The "provisioning API" seems like a settings backup/restore to me.
It's an interesting function not yet been thought of on Firefox OS, as I know.
I think that function can co-exist with existing API.

> > You can build an easy-to-use settings app based on these "complex" APIs,
> > including a customized "XML-importing method" function.
> 
> That would suffice for me, but I don't think it's as easy as converting an
> xml config to the wpa_supplicant equivalent. I'm thinking for instance in
> EAP-TLS, where you have to provide client certificates... which is not
> exactly the same as trusting CA certificates.
> 

The easiest way is using pkcs 12, I think that's how Android/iPhone are using, and it's what we are planing to use.

> > So if you are proposing a "XML-importing method" for wifi, I think it's
> > can(and should) be implemented by app with wifi APIs, unless there is a
> > standard for that.
> 
> Good for this! 
> 
> And... there's no standard for that, but in eduroam we have been talking
> about a way to do this that we would want to propose as a standard. I'll let
> the persons behind this know about this bug... :)

The provisioning function you mentioned involves works of multiple modules.
I suggest you propose it on b2g mail list: https://lists.mozilla.org/listinfo/dev-b2g.
You can get more feedback and discussion there. :)
(In reply to Chuck Lee [:chucklee] from comment #47)

> The "provisioning API" seems like a settings backup/restore to me.

Well, Apple calls this "Over-the-Air Profile Delivery and Configuration", and provides a way to configure other "system" services/apps too (e-mail, VPN, calendar servers,...). Here's the documentation describing it:

https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/Introduction/Introduction.html

> I think that function can co-exist with existing API.

Yes, I agree.

> The provisioning function you mentioned involves works of multiple modules.

I guess for the purpose of wifi configuration, everything related to crypto and wifi only... but it may have sense a general way of provisioning other services too.

> I suggest you propose it on b2g mail list...

Ok, I'll discuss this with the eduroam crowd before. Thanks!
Hi,

José mentioned the eduroam roaming consortium and that we are trying to get WiFi configuration file formats standardised. I'm the lead R&D engineer for eduroam in Europe, and would like to expand on those.

First of all, about the user base concerned by disabling or shipping a crippled WPA-Enterprise configuration UI/API/backend:

The eduroam roaming consortium has several million active users, and more than ten thousand hotspots around the globe. You can find eduroam-enabled universities and research centres in more than 60 countries of the world, including Latin America, Asia which I understand to be FirefoxOS's primary market. Of course our main density of PoPs is in Europe and North America; even if you don't care about these markets primarily, they are a significant deployment.

Most of these users are students, i.e. people with not much money, more likely to economise on their smartphone than others - and thus the target group for FirefoxOS devices.

When I read this bug's history, I can't believe how short-sighted the arguments about deployment sizes of WPA-Enterprise are. Do you really think that deployment of WPA-Enterprise is limited to "your offices", and the only downside of disabling it is that you can't test your beta build any more? The standards to do this are like 10 years old, and are *the* method of choice to secure any enterprise network. Any company with WiFi which cares about its data security has it. That's a "silent" deployment, because it's internal to the company, but it's a deployment nontheless. 

You said you've googled for Android's WPA-Enterprise support and got mixed results. That's correct; Android before 4.3 was /horrible/ in terms of WPA-Enterprise, and the outcries you got from Google are to a large extent from eduroam end users who bought such a device and then found they couldn't connect, or only with insecure settings. The community - finally - made Google change their ways and provide a new API which does things /right/ with 4.3. That makes Android a much better citizen in the WPA-Enterprise world.

Reading this bug, it almost looks like you are keen on repeating Android's history of underperformance. Don't do that.

On the second point, standardisation of a provisioning file format. In eduroam, we've been observing numerous proprietary approaches to over-the-air configuration, some better, some worse. Our conclusion was that unifying this into a *standard* format is needed. I am currently at the 87th IETF meeting, discussing EAP and RADIUS, and also trying to spin up some support for an "EAP Metadata Configuration File Format", which would hopefully become an RFC some time in the future.

A first version of the file format exists, and that's the one we'll bring forward to the IETF later this year (November-ish). If you are interested in looking at this, or even implementing support for this draft spec, please do get back to me, also in private mail.

UI-wise, I can't offer much support right now. We are also going to produce some guidelines "How does a good supplicant look like" in an upcoming EU project, which will list some do's and don'ts. I'll update this bug when the time to present something has come.

I can go into detail on one of your points above though, which might even help clear the needinfo:

The discussion about interfacing with NSS cert store is to a large extent moot. In the EAP context, it is *not* helpful to trust a set of general-purpose CAs. The authentication server's server certificate was signed by /exactly one/ CA, and that is the only CA to trust. If that CA is already in the trust store, fine, the only UI interaction by the user needed is then to set a checkbox "Yes, that's the one". If it is not present (i.e. self-signed or private CA), then the device must have a way of importing that new CA and trust it *only for EAP purposes*.

I.e. the trust stores for "general-purpose web usage" and "EAP Enterprise Authentication" are two different stores. Don't just blindly point wpa_supplicant to a NSS store and assume things are all-good then.

In that sense, interfacing with NSS either with a) or b) in comment 20 is not really necessary. You may want to list NSS's installed certificates to ask the user which is "his", but you can as well let it be and ask for the CA's PEM file directly - you'll have to do this for private/self-signed CAs anyway.

I can really suggest to read this to find out why the use cases are different, and why or why not to use a private CA. All have their reasons and uses:

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

Greetings,

Stefan Winter
Hello , my name is jesus israel and this bug is affecting me I'm a student of the Facultad de Ingenieria Mecanica y Electrica de la UANL (FIME) , the network is wpa enterprise college and I can not seem to connect you took the solution to remove that option and worried more about the development of a user interface , I like firefoxOS , I like GNU / Linux and I like what they're trying to do, but if you say that this bug is already known in android try to implement that solution is that the theory is easier than practice but that option is required if the phone is sold saying it has wi - fi, I do not regret buying it ( just yesterday ) , I can see between the lines that have few resources and that makes me lose hopes more will find the solution to the bug , do not speak English but you should keep in mind that most end users speak Spanish so I used the google translator because I prefer that to write something like " tis an israel jesus AIAM "
PS: I'll be careful, thanks for your attention

Hola , mi nombre es jesus israel y este bug me esta afectando soy estudiante de la Facultad de Ingenieria Mecanica y Electrica de la UANL (FIME), la red de la universidad es wpa enterprise y no puedo conectarme al parecer ustedes tomaron la solucion de quitar esa opcion y se preocuparon mas por el desarrollo de una interfaz de usuario, me gusta firefoxOS ,me gusta GNU/Linux y me gusta lo que estan tratando de hacer , pero si dicen que ese error es ya conocido en android traten de implementar esa solucion se que la teoria es mas facil que la practica pero esa opcion es requerida si el celular se vende diciendo que tiene wi-fi,no me arrepiento de comprarlo( justamente ayer ) ,puedo ver entre lineas que tienen pocos recursos y eso me hace perder mas las esperanzas de encontraran la solucion al bug, no hablo ingles pero ustedes deberian tener en cuenta que la mayoria de sus usuarios finales habla español asi que use el traductor de google pues prefiero eso a escribir algo como "aiam  jesus israel an tis"
PD: Estare atento , gracias por su atencion
Wondering why "sec-high" was removed? The ability to properly verify a certificate is a required prerequisite to prevent MitM attacks in all scenarios where no self-signed CA is used (only then is it optional).

Also, meanwhile Android made leaps in Enterprise WiFi config. Their API level 18 now adds full control over all WiFi security parameters, including subject_match. See here:

https://developer.android.com/reference/android/net/wifi/WifiEnterpriseConfig.html

Does FirefoxOS really want to move itself out of the picture of Enterprise WiFi and eduroam? A real shame.
Critsmash looked at this and decided that this was a low-priority security oriented feature request and not an actual sec-high issue. While we should still do this work, this is an enhancement request.
Update: earlier in the discussion, there was some interest for provisioning of EAP configuration using a standard way.

Such a standard is now coming up: the first draft of the EAP configuration file format is here

http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/

IMHO, you should consider enabling Firefox OS to consume configuration data in that format, and to construct wpa_supplicant configs from the data contained therein.

Note: this is a new work effort in IETF. It will progress faster if enough people voice their opinion saying that it's a good and useful idea to have a standard for that. If you think that way and want to voice your opinion (or just have a comment about the technical content of the draft spec), please consider subscribing and posting to this IETF list:

https://www.ietf.org/mailman/listinfo/opsawg

We are working on an Android app to do this job on Android API level 18 and above; if you don't want to lag behind, you should take a look at this better sooner than later.

Greetings,

Stefan Winter
(In reply to Stefan Winter from comment #53)
> Update: earlier in the discussion, there was some interest for provisioning
> of EAP configuration using a standard way.
> 
> Such a standard is now coming up: the first draft of the EAP configuration
> file format is here
> 
> http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/
> 

  I think the server certificate part of this draft can be supported by app, once we landed certificate management API(bug 917101).
  (In reply to Al Billings [:abillings] from comment #52)
> Critsmash looked at this and decided that this was a low-priority security
> oriented feature request and not an actual sec-high issue. While we should
> still do this work, this is an enhancement request.

AFAICT, this isn't a sec-high bug because WPA enterprise support is disabled in B2G. It would be sec-high if WPA enterprise support were enabled, so I'm making it block bug 790056.
Reopen and change summary per bug 745468 comment 68, this also needs Gaia work to provide a text box for input.
Comment on attachment 686094 [details] [diff] [review]
WIP, B2G side

What this patch tries to do is done in bug 745468, we need new patch to support subject_match.

Comment on attachment 8424632 [details] [diff] [review]
0002. Handle subject match setting.

Review of attachment 8424632 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. Thank you.
Try : https://tbpl.mozilla.org/?tree=Try&rev=84deaf321dbe
Try back to normal, looks good.
https://tbpl.mozilla.org/?tree=Try&rev=f067ff8e7507
https://hg.mozilla.org/integration/b2g-inbound/rev/f75b8fff6eff
https://hg.mozilla.org/integration/b2g-inbound/rev/a131319faac2

I tweaked the commit message of the first patch a bit. Please remember that the commit message should be summarizing what the patch is doing. Thanks :)
https://hg.mozilla.org/mozilla-central/rev/f75b8fff6eff
https://hg.mozilla.org/mozilla-central/rev/a131319faac2
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #64)
> https://hg.mozilla.org/integration/b2g-inbound/rev/f75b8fff6eff
> https://hg.mozilla.org/integration/b2g-inbound/rev/a131319faac2
> 
> I tweaked the commit message of the first patch a bit. Please remember that
> the commit message should be summarizing what the patch is doing. Thanks :)

Got it! Thanks :)

WIP, B2G side 12 years ago Antonio Manuel Amaya Calvo (:amac) 2.52 KB, patch	vchang : feedback+	Details \| Diff \| Splinter Review
0001. WebIDL change. 10 years ago Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests] 1.48 KB, patch	ehsan.akhgari : review+ mrbkap : review+	Details \| Diff \| Splinter Review
0002. Handle subject match setting. 10 years ago Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests] 2.39 KB, patch	vchang : review+	Details \| Diff \| Splinter Review

[Wifi] Support subject_match to WPA-EAP Enterprise networks