Closed Bug 1086222 Opened 10 years ago Closed 6 years ago

Import of WiFi certificate fails (PEAP MSCHAPv2)

Categories

(Firefox OS Graveyard :: Wifi, defect)

Product:
Firefox OS Graveyard
Component:
Wifi
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: webmaster, Assigned: vchang)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141016231145

Steps to reproduce:

I'm on a Flame (Aurora Channel, 2.1).
I tried to import root certificates for eduroam (big university WiFi network all over Europe) "Deutsche Telekom Root CA 2" from here: https://www.pki.dfn.de/root/globalroot/#c15065

I've tried to import the .crt, .der and .pem


Actual results:

Import always fails (error message with red OK button, import failed)


Expected results:

Cert should have been imported and displayed in the WiFi UI
"Deutsche Telekom Root CA 2" is a NSS built-in CA and NSS returns error while importing duplicate CA.
I am not sure if NSS support multiple nickname for one certificate, I'll look into it.
Assignee: nobody → chulee
(In reply to Chuck Lee [:chucklee] from comment #1)
> "Deutsche Telekom Root CA 2" is a NSS built-in CA and NSS returns error
> while importing duplicate CA.
> I am not sure if NSS support multiple nickname for one certificate, I'll
> look into it.

All right, then the error message should not be generic. "Certificate already in stock" or something would have pointed me in the right direction :)

However, isn't the WiFi certificate feature also meant to pin the certificate to the connection? Otherwise anyone with a cert from one of the "trusted" CAs (*ahem* DigiNotar *ahem*) could fake an AP...
(In reply to Carsten from comment #2)
> (In reply to Chuck Lee [:chucklee] from comment #1)
> > "Deutsche Telekom Root CA 2" is a NSS built-in CA and NSS returns error
> > while importing duplicate CA.
> > I am not sure if NSS support multiple nickname for one certificate, I'll
> > look into it.
> 
> All right, then the error message should not be generic. "Certificate
> already in stock" or something would have pointed me in the right direction
> :)

We don't have detailed error message yet, we can also solve that here.
Then we can ask help for Gaia to change UI presentation.

> However, isn't the WiFi certificate feature also meant to pin the
> certificate to the connection? Otherwise anyone with a cert from one of the
> "trusted" CAs (*ahem* DigiNotar *ahem*) could fake an AP...

Soryy, I didn't get your concern here.

The CA certificate is used by device to check the AP and CA server of the network it is connecting to, I think the possible issue of certificate should be user gets fake certificate and connect to a fake AP. A fake cert installed in devices will make it unable to connect to real AP.
Also, WPA-EAP need username/password handshake(no plain text involves) to generate encryption key for wifi connection, so even user connects to a fake AP, the fake network can't really authenticated the user into the fake network for sniffing nor get the username/password of user.

On the other way, WPA wifi network uses different encrypt key for each user on each connection(by handshaking), a authenticated user in WPA network can't decrypt data of other users.
(In reply to Chuck Lee [:chucklee] from comment #3)
> We don't have detailed error message yet, we can also solve that here.
> Then we can ask help for Gaia to change UI presentation.

That would be nice. Thanks!

> > However, isn't the WiFi certificate feature also meant to pin the
> > certificate to the connection? Otherwise anyone with a cert from one of the
> > "trusted" CAs (*ahem* DigiNotar *ahem*) could fake an AP...
> 
> Soryy, I didn't get your concern here.
> 
> The CA certificate is used by device to check the AP and CA server of the
> network it is connecting to, I think the possible issue of certificate
> should be user gets fake certificate and connect to a fake AP. A fake cert
> installed in devices will make it unable to connect to real AP.

No, I don't mean fake certs. Example: DigiNotar issued certificates for google.com
https://blog.mozilla.org/security/2011/08/29/fraudulent-google-com-certificate/
So the cert is valid (because it came from a built-in CA) but still fraudulent. As there are many "state-controlled" root CAs, it is a valid threat for surveillance. 
Specifically:
Verisign could issue a certificate for my university domain and a fraudulent AP could use that - the phone could connect to the WiFi without error, but it is at risk (because the real cert comes from Telekom). The user has no way of telling, because the CA information cannot be seen in the UI.

On normal website connections, I can check the certificate on a TLS connection (click on details, see who issued it). For WiFi I cannot do that. Therefore I would like to pin a certain root certificate to a connection, thus making sure the responding server has to use a certificate issued by that specific CA - this is the way NetworkManager does it for Linux.

If this is to complicated for mobile, there should at least be a way in the UI to check the certificate hierarchy. Additionally, it would be great if the UI warns the user if the certificate hierarchy changes after it has once been connected to the network (active MitM warning).

> Also, WPA-EAP need username/password handshake(no plain text involves) to
> generate encryption key for wifi connection, so even user connects to a fake
> AP, the fake network can't really authenticated the user into the fake
> network for sniffing nor get the username/password of user.
> 
> On the other way, WPA wifi network uses different encrypt key for each user
> on each connection(by handshaking), a authenticated user in WPA network
> can't decrypt data of other users.

In the scenario explained above, a fraudulent AP can collect your MSCHAPv2 handshakes. Those can be cracked quite quickly, see: https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/
This means the user is now completely owned.

A warning though: I am interested in network security and crypto, but I am no expert. I hope I understood all details correctly.
(In reply to Carsten from comment #4)
> > > However, isn't the WiFi certificate feature also meant to pin the
> > > certificate to the connection? Otherwise anyone with a cert from one of the
> > > "trusted" CAs (*ahem* DigiNotar *ahem*) could fake an AP...
> On normal website connections, I can check the certificate on a TLS
> connection (click on details, see who issued it). For WiFi I cannot do that.
> Therefore I would like to pin a certain root certificate to a connection,
> thus making sure the responding server has to use a certificate issued by
> that specific CA - this is the way NetworkManager does it for Linux.

If you imported certificate successfully, the CA certificate can be selected in "Server Certificate" field in wifi connection setting. I suppose this is the "pin" action you are referring to?

Technically we can let built-in CA certificate selectable on that list, but the list becomes too long.
So we don't do that for now.

I still try to see make it possible to import duplicate certificate, it's more intuitive for user I think.
If I can't do that, then we have to consider how to make select built-in certificates ease to use.

> 
> If this is to complicated for mobile, there should at least be a way in the
> UI to check the certificate hierarchy. Additionally, it would be great if
> the UI warns the user if the certificate hierarchy changes after it has once
> been connected to the network (active MitM warning).
> 

Showing hierarchy is harder because the EAP are complete handled by wpa_supplicant, we have support another parameter "subject_match" so wpa_supplicant can apply check on subject of the authentication server certificate[1]
I am not sure if this fits you need, but this field hasn't being supported settings app yet.

[1] http://www.freebsd.org/cgi/man.cgi?wpa_supplicant.conf%285%29

> > 
> > On the other way, WPA wifi network uses different encrypt key for each user
> > on each connection(by handshaking), a authenticated user in WPA network
> > can't decrypt data of other users.
> 
> In the scenario explained above, a fraudulent AP can collect your MSCHAPv2
> handshakes. Those can be cracked quite quickly, see:
> https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/
> This means the user is now completely owned.

I am not familiar with the crypto detail, so thanks for these information. :)
But if that's the case, maybe CA certificate and subject match is the protection we can provide?
(In reply to Chuck Lee [:chucklee] from comment #5)
> If you imported certificate successfully, the CA certificate can be selected
> in "Server Certificate" field in wifi connection setting. I suppose this is
> the "pin" action you are referring to?

If wpa_supplicant would then reject all other certificates for this connection (even if they come from a built-in CA), then yes I would consider it pinned. By the way, how is this currently handled? If I specifiy a custom (not built-in) certificate, but the AP answers with a cert from a built-in CA - will the connection be accepted?

> Technically we can let built-in CA certificate selectable on that list, but
> the list becomes too long.
> So we don't do that for now.
> 
> I still try to see make it possible to import duplicate certificate, it's
> more intuitive for user I think.
> If I can't do that, then we have to consider how to make select built-in
> certificates ease to use.

I don't think a long list is a problem as long as it is searchable. If I can immediately find the Telekom Root CA 2 after entering "Telekom" into a search bar, it would be perfectly OK - and also easy to implement. Also, I consider importing a file on the device more troublesome (remember: I want to connect to a WiFi, so presumably I don't have a working connection at that time) - I need to find and download it first or place it on the device via USB... much more hassle than entering a word into a search bar and selecting an entry?
 
> Showing hierarchy is harder because the EAP are complete handled by
> wpa_supplicant, we have support another parameter "subject_match" so
> wpa_supplicant can apply check on subject of the authentication server
> certificate[1]
> I am not sure if this fits you need, but this field hasn't being supported
> settings app yet.
> 
> [1] http://www.freebsd.org/cgi/man.cgi?wpa_supplicant.conf%285%29

> I am not familiar with the crypto detail, so thanks for these information. :)
> But if that's the case, maybe CA certificate and subject match is the
> protection we can provide?

You're welcome :) I think subject match is not feasible for mobile use. You would need to enter the whole string... I think CA pinning would be the best way to go from a UX perspective.
(In reply to Carsten from comment #6)
> (In reply to Chuck Lee [:chucklee] from comment #5)
> > If you imported certificate successfully, the CA certificate can be selected
> > in "Server Certificate" field in wifi connection setting. I suppose this is
> > the "pin" action you are referring to?
> 
> If wpa_supplicant would then reject all other certificates for this
> connection (even if they come from a built-in CA), then yes I would consider
> it pinned. By the way, how is this currently handled? If I specifiy a custom
> (not built-in) certificate, but the AP answers with a cert from a built-in
> CA - will the connection be accepted?

wpa_supplicant doesn't know anything about built-in CA.
It reads which CA certificate to use from per-network config, and it only accepts authentication from AP with same CA certificate.
Other CA, including built-in CA, won't be accepted.

> > I still try to see make it possible to import duplicate certificate, it's
> > more intuitive for user I think.
> > If I can't do that, then we have to consider how to make select built-in
> > certificates ease to use.
> 
> I don't think a long list is a problem as long as it is searchable. If I can
> immediately find the Telekom Root CA 2 after entering "Telekom" into a
> search bar, it would be perfectly OK - and also easy to implement. Also, I
> consider importing a file on the device more troublesome (remember: I want
> to connect to a WiFi, so presumably I don't have a working connection at
> that time) - I need to find and download it first or place it on the device
> via USB... much more hassle than entering a word into a search bar and
> selecting an entry?

Maybe we can support both, but not in a short time.
I am stock in other bugs now.

> > I am not familiar with the crypto detail, so thanks for these information. :)
> > But if that's the case, maybe CA certificate and subject match is the
> > protection we can provide?
> 
> You're welcome :) I think subject match is not feasible for mobile use. You
> would need to enter the whole string... I think CA pinning would be the best
> way to go from a UX perspective.

Based on my test, wpa_supplicant checks if the subject_match string exists in the subject of CA.
So substring of subject is acceptable to it.
Hi Kai,
  A quick question here, does it possible to assign another nickname(or alias) to a built-in certificate?
Flags: needinfo?(kaie)
I will take over the bug, feel free to take it back if you are still working on it.
Assignee: chuckli0706 → vchang
(In reply to Chuck Lee [:chucklee] from comment #8)
>   A quick question here, does it possible to assign another nickname(or
> alias) to a built-in certificate?

I don't think a second nickname can be added.

I believe we're making progress on your requirements in the NSS bug, so I'm clearing needinfo.
Flags: needinfo?(kaie)
Firefox OS is not being worked on
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.