6 ms·

If you've ever tried to use 802.1x / EAP on Android then you've already had a taste of this issue. Android makes importing and trusting a new root certificate

If you've ever tried to use 802.1x / EAP on Android then you've already had a taste of this issue. Android makes importing and trusting a new root certificate authority very difficult. At least in my experience the device constantly pops up warnings about the root ca, despite using the appropriate import options. And if you're paranoid enough to use wifi client authentication, then you probably don't want anyone else to issue certs for your devices. On one hand it's commendable that Google makes it hard on malicious actors, but on the other there are legitimate use cases for importing your own root CAs and using something stronger than WEP is just one of them.

hackmiester 4y ago
This is seriously such a joke because for years Android had a “don’t check certificate” option for 802.1X. It was unique among the most popular client OSes in allowing this extremely unsafe configuration, which is way worse than “trust on first use” (the least secure option in iOS). And now suddenly a total 180, they are extremely anal about certificates to the point that 802.1X is very hard to use. Thanks a lot gang.
- jeroenhd 4y ago
  My university used to recommend explicitly selecting "do not validate" for the longest time, even though validation through the system store (or a certificate of your choice) has existed for years. For what it's worth, if you're using a valid TLS certificate for your 802.1x setup then you don't need to load any certificates anymore (at least not since Android 10 or 11). Users may need to enter a domain to validate, though; I don't know the specifics of these protocols.
  - Avamander 4y ago
    It's unfortunate that the SSID can't be automatically used as the domain on the TLS certificate.
    - hackmiester 4y ago
      Unfortunately this wouldn’t help us because we are an eduroam identity provider. The SSID is always eduroam but the cert presented is different, based on your username, because your login is handled by your home institution (the IdP responsible for your identity).
      - Avamander 4y ago
        Yeah, eduroam is a bit more special in that aspect. I can imagine it working in quite a few other cases though.
      - tialaramex 4y ago
        But I believe Android does care about the domain an Eduroam user said their user is in. So, if your user says I'm example@mit.edu I think it will expect the certificate from the 802.1X server (at MIT) to have a certificate for mit.edu, which is what will happen in Eduroam. The certificates used are PKIX certificates, they say they're for TLS Server Authentication (which they technically are) and the subjects are DNS server names (these are, after all, servers on the Internet) and so realistically the only PKI exercising any oversight over such certificates so that it could Just Work™ which is what your users want, is the Web PKI. So this actually makes sense?
  - hackmiester 4y ago
    Not every modern Android device offers the “use system CA store” option. And chromebooks don’t. We just gave up and kept loading the certificate. You also have to understand that “valid” doesn’t really mean anything. When android supports the system CA store, they’re the first and only OS to do it this way. It doesn’t make a ton of sense to try to do this because there is no domain to validate. Unless it’s preconfigured, in which case you may as well have loaded a root CA. That’s what we’re doing now (preconfiguring the root CA). Then the server sends a valid cert and trust chain, just not within the typical global PKI infrastructure.
    - jeroenhd 4y ago
      From what I'm reading about this online the domain validation thing is part of the WPA3 spec, though it's clearly more visible on Android. Perhaps they removed their WPA2 code path and stuck to WPA3 exclusively but I think this is a way forward rather than a problem; it's too easy to accidentally import a root certificate authority into the trust store when you're trying to get the WiFi going and that's a security risk. The stupid warnings should still disappear when you import the CA as an EAP certificate of course. I'm pretty sure most modern operating systems will (some day soon) connect to enterprise networks configured the way Android likes it without ever needing to install a certificate, which is an obvious benefit to me. The domain itself is either the entered domain or the domain of the identity you entered, I believe this is also based on some part of WPA3. Validating the common name through the system CA store is also an option on Linux, though you have to select the system certificate store manually instead of specifying a PEM file that you can never move again. I don't know about Chromebooks but I think the system CA validation setting is standard in Android since either Android 10 or Android 11. Android 11 added validation of the certificate (presumably through OCSP stapling?) but that's disabled by default. If you're not on Android 10+ I'm not sure if I'd call that a "modern" Android version anymore with how quickly manufacturers drop support for older Android versions. I'm pretty sure Google already dropped security support for Android 9 anyway. It's possible that some manufacturers broke the setting, but if they did they should've added their own replacement. You can't blame Google for broken Android forks imo.
      - 4y ago
- hedora 4y ago
  "Trust on first use" is not always less secure than using a CA. With trust on first use, if you validate that the certificate matches the one you expect, then you're good as long as the server and your device are not compromised. If you go the standard route and use a certificate authority, then a compromise (due to law enforcement or not) of the certificate authority will cause your device to silently trust a third party MITM certificate. A lot of hidden implicit trafeoffs like this become apparent once you realize that your personal threat model is only loosely aligned with Google's.
  - kevincox 4y ago
    It's worse. A compromise of any certificate authority will do this.
  - hackmiester 4y ago
    We control the CA so this method of attack is not possible. That said, TOFU is only less secure in practice, not in theory. The "in practice" is because users do not actually compare the cert with anything. They will always just click "Trust."
- tinus_hn 4y ago
  802.1x certificate checking is a big mess because it is totally unclear what the certificate should certify. The WiFi alliance should have specified a domain name instead of an SSID, then you could just have checked the certificate for that.
jeroenhd 4y ago
The constant popups have been removed almost eight years ago, right now you get a little (i) in the notification shade that says "this network may be monitored". This is the same warning that shows when you enable a VPN. The warning is wrong when it comes to EAP certificates, of course, but far better than the constant unnecessary popups warning you that you did in fact load a CA cert.
- technofiend 4y ago
  Yeah anything that requires acking or creates distrust is a no go. I really want to transparently move all devices that support it to certificate-based authentication without training my wife to ignore or ack warnings. My fantasy is that IOT devices add support for it too, but that's just crazy talk.
  - vetinari 4y ago
    > My fantasy is that IOT devices add support for it too, but that's just crazy talk. Maybe not. Recently I played with some relays that support MQTT-over-TLS (Shelly 2nd-gen ones). What I liked was, that they came with empty CA store, it was up to the user to provide all the certs.
baisq 4y ago
If you need something stronger than WEP you have WPA2 and WPA3.
- technofiend 4y ago
  Yeah, you're right. I should have included those, but I'm really talking about per-client certificate authentication vs a shared secret.
zamadatix 4y ago
Android's networking team has historically been very opinionated and unwilling to support use cases they don't consider to be the right way. It and ChromeOS are still the only things actively refusing DHCPv6 support for example.
- Avamander 4y ago
  Unlike with a lot of what they do, that resistance I appreciate. I don't think it's the right way either. I've seen firsthand how it's a crutch that lulls some network admins into thinking they can just think about v6 as it were v4.
  - zamadatix 4y ago
    I've maintained and deployed dozens of IPv6 networks but I'm still not quite sure I follow what you mean. The Android teams reasoning was they didn't want networks to be able to disallow multiple addresses (particularly carriers, not Wi-Fi) but that doesn't really have anything to do with treating it like v4 being wrong.
    - vetinari 4y ago
      Exactly; DHCPv6 would allow to force the device to use just a single IP address. In IPv6, you need extra IP addresses for tethering; XLAT464 needs entire /96 prefix. Allowing DHCPv6 would allow network admins cripple functionality like this. It's not like IP addresses even in the smallest subnet (/64) are a scarce resource. For carriers, it is not necessary at all. LTE networks use different mechanism for communicating assigned IP addresses.
      - zamadatix 4y ago
        DHCPv6 forces no such thing. 464XLAT can still be done via PD though it's really again a carrier thing, enterprises will know if they need 464XLAT the device doesn't need to force that it would be possible. Same story with tethering. LTE w/ PDN still uses DHCPv6 PD or SLAAC (or both) https://i.imgur.com/2dKAw5W.png https://i.imgur.com/2dKAw5W.png
ollien 4y ago
> If you've ever tried to use 802.1x / EAP on Android then you've already had a taste of this issue. Android makes importing and trusting a new root certificate authority very difficult. Good lord don't get me started. In worked at a NOC in college part-time and a significant part of my job was helping users onboard devices to the network and determining where there were gaps in our onboarding process. After a random security update, all Pixel phones just ... stopped being able to connect to our network and we eventually determined that you needed to go through a new, non-obvious path to import a CA for our EAP-TLS certificates. I'm not remembering the details but unless you connected _exactly_ right on the first try, it would delete the CA certificate and you'd have to start over. There's a lot of other details here but it ended up taking us almost a month to find the exact path to get things up and running. We also paid a vendor (SecureW2) for an app to enroll devices on the network, but Google removed the ability for users to edit configurations generated by apps. Our network required disabling MAC randomization at the time (which Google provides no API for apps to disable). Before the change, users would enroll, and then disable MAC randomization to complete setup. However, because users were no longer allowed to edit these configurations after the app had gotten everything else configured, they were left dead in the water. On the flip-side: Apple makes this very easy and provides a "profile" mechanism that users can download and get everything set up in a few clicks.
- shakna 4y ago
  > Our network required disabling MAC randomization at the time (which Google provides no API for apps to disable). Before the change, users would enroll, and then disable MAC randomization to complete setup. Yeah, that one I kinda agree with. I don't want most apps to be able to disable that. It's one of the first lines of defense in protecting a device's privacy, and I doubt most people would understand the potential impact if any app could even ask to disable it. That one can be left in the main settings.
  - ollien 4y ago
    Yeah, I totally understand why Google did that (though, it's a WiFi provisioning app... it's literally an app that connects you to a previously untrusted WiFi network. I get you gotta draw the line somewhere but that's debatably just as much of a privacy risk). That said, if you decide that it's not allowed to be changed by an app, you gotta let the user be able to make the change...
guerby 4y ago
I've always wondered why OSes don't have a specific CA store just for 802.1x.
- ollien 4y ago
  Android kind of does. You can mark a certificate for "VPN and Apps" or for "Wifi". I can't remember if you can do it with CAs, but you can definitely do it with the dependent certs.

hackmiester 4y ago

This is seriously such a joke because for years Android had a “don’t check certificate” option for 802.1X. It was unique among the most popular client OSes in allowing this extremely unsafe configuration, which is way worse than “trust on first use” (the least secure option in iOS). And now suddenly a total 180, they are extremely anal about certificates to the point that 802.1X is very hard to use. Thanks a lot gang.

jeroenhd 4y ago
My university used to recommend explicitly selecting "do not validate" for the longest time, even though validation through the system store (or a certificate of your choice) has existed for years. For what it's worth, if you're using a valid TLS certificate for your 802.1x setup then you don't need to load any certificates anymore (at least not since Android 10 or 11). Users may need to enter a domain to validate, though; I don't know the specifics of these protocols.
- Avamander 4y ago
  It's unfortunate that the SSID can't be automatically used as the domain on the TLS certificate.
  - hackmiester 4y ago
    Unfortunately this wouldn’t help us because we are an eduroam identity provider. The SSID is always eduroam but the cert presented is different, based on your username, because your login is handled by your home institution (the IdP responsible for your identity).
    - Avamander 4y ago
      Yeah, eduroam is a bit more special in that aspect. I can imagine it working in quite a few other cases though.
    - tialaramex 4y ago
      But I believe Android does care about the domain an Eduroam user said their user is in. So, if your user says I'm example@mit.edu I think it will expect the certificate from the 802.1X server (at MIT) to have a certificate for mit.edu, which is what will happen in Eduroam. The certificates used are PKIX certificates, they say they're for TLS Server Authentication (which they technically are) and the subjects are DNS server names (these are, after all, servers on the Internet) and so realistically the only PKI exercising any oversight over such certificates so that it could Just Work™ which is what your users want, is the Web PKI. So this actually makes sense?
- hackmiester 4y ago
  Not every modern Android device offers the “use system CA store” option. And chromebooks don’t. We just gave up and kept loading the certificate. You also have to understand that “valid” doesn’t really mean anything. When android supports the system CA store, they’re the first and only OS to do it this way. It doesn’t make a ton of sense to try to do this because there is no domain to validate. Unless it’s preconfigured, in which case you may as well have loaded a root CA. That’s what we’re doing now (preconfiguring the root CA). Then the server sends a valid cert and trust chain, just not within the typical global PKI infrastructure.
  - jeroenhd 4y ago
    From what I'm reading about this online the domain validation thing is part of the WPA3 spec, though it's clearly more visible on Android. Perhaps they removed their WPA2 code path and stuck to WPA3 exclusively but I think this is a way forward rather than a problem; it's too easy to accidentally import a root certificate authority into the trust store when you're trying to get the WiFi going and that's a security risk. The stupid warnings should still disappear when you import the CA as an EAP certificate of course. I'm pretty sure most modern operating systems will (some day soon) connect to enterprise networks configured the way Android likes it without ever needing to install a certificate, which is an obvious benefit to me. The domain itself is either the entered domain or the domain of the identity you entered, I believe this is also based on some part of WPA3. Validating the common name through the system CA store is also an option on Linux, though you have to select the system certificate store manually instead of specifying a PEM file that you can never move again. I don't know about Chromebooks but I think the system CA validation setting is standard in Android since either Android 10 or Android 11. Android 11 added validation of the certificate (presumably through OCSP stapling?) but that's disabled by default. If you're not on Android 10+ I'm not sure if I'd call that a "modern" Android version anymore with how quickly manufacturers drop support for older Android versions. I'm pretty sure Google already dropped security support for Android 9 anyway. It's possible that some manufacturers broke the setting, but if they did they should've added their own replacement. You can't blame Google for broken Android forks imo.
    - 4y ago
hedora 4y ago
"Trust on first use" is not always less secure than using a CA. With trust on first use, if you validate that the certificate matches the one you expect, then you're good as long as the server and your device are not compromised. If you go the standard route and use a certificate authority, then a compromise (due to law enforcement or not) of the certificate authority will cause your device to silently trust a third party MITM certificate. A lot of hidden implicit trafeoffs like this become apparent once you realize that your personal threat model is only loosely aligned with Google's.
- kevincox 4y ago
  It's worse. A compromise of any certificate authority will do this.
- hackmiester 4y ago
  We control the CA so this method of attack is not possible. That said, TOFU is only less secure in practice, not in theory. The "in practice" is because users do not actually compare the cert with anything. They will always just click "Trust."
tinus_hn 4y ago
802.1x certificate checking is a big mess because it is totally unclear what the certificate should certify. The WiFi alliance should have specified a domain name instead of an SSID, then you could just have checked the certificate for that.

jeroenhd 4y ago

The constant popups have been removed almost eight years ago, right now you get a little (i) in the notification shade that says "this network may be monitored". This is the same warning that shows when you enable a VPN. The warning is wrong when it comes to EAP certificates, of course, but far better than the constant unnecessary popups warning you that you did in fact load a CA cert.

technofiend 4y ago
Yeah anything that requires acking or creates distrust is a no go. I really want to transparently move all devices that support it to certificate-based authentication without training my wife to ignore or ack warnings. My fantasy is that IOT devices add support for it too, but that's just crazy talk.
- vetinari 4y ago
  > My fantasy is that IOT devices add support for it too, but that's just crazy talk. Maybe not. Recently I played with some relays that support MQTT-over-TLS (Shelly 2nd-gen ones). What I liked was, that they came with empty CA store, it was up to the user to provide all the certs.

baisq 4y ago

If you need something stronger than WEP you have WPA2 and WPA3.

technofiend 4y ago
Yeah, you're right. I should have included those, but I'm really talking about per-client certificate authentication vs a shared secret.

zamadatix 4y ago

Android's networking team has historically been very opinionated and unwilling to support use cases they don't consider to be the right way. It and ChromeOS are still the only things actively refusing DHCPv6 support for example.

Avamander 4y ago
Unlike with a lot of what they do, that resistance I appreciate. I don't think it's the right way either. I've seen firsthand how it's a crutch that lulls some network admins into thinking they can just think about v6 as it were v4.
- zamadatix 4y ago
  I've maintained and deployed dozens of IPv6 networks but I'm still not quite sure I follow what you mean. The Android teams reasoning was they didn't want networks to be able to disallow multiple addresses (particularly carriers, not Wi-Fi) but that doesn't really have anything to do with treating it like v4 being wrong.
  - vetinari 4y ago
    Exactly; DHCPv6 would allow to force the device to use just a single IP address. In IPv6, you need extra IP addresses for tethering; XLAT464 needs entire /96 prefix. Allowing DHCPv6 would allow network admins cripple functionality like this. It's not like IP addresses even in the smallest subnet (/64) are a scarce resource. For carriers, it is not necessary at all. LTE networks use different mechanism for communicating assigned IP addresses.
    - zamadatix 4y ago
      DHCPv6 forces no such thing. 464XLAT can still be done via PD though it's really again a carrier thing, enterprises will know if they need 464XLAT the device doesn't need to force that it would be possible. Same story with tethering. LTE w/ PDN still uses DHCPv6 PD or SLAAC (or both) https://i.imgur.com/2dKAw5W.png https://i.imgur.com/2dKAw5W.png

ollien 4y ago

> If you've ever tried to use 802.1x / EAP on Android then you've already had a taste of this issue. Android makes importing and trusting a new root certificate authority very difficult. Good lord don't get me started. In worked at a NOC in college part-time and a significant part of my job was helping users onboard devices to the network and determining where there were gaps in our onboarding process. After a random security update, all Pixel phones just ... stopped being able to connect to our network and we eventually determined that you needed to go through a new, non-obvious path to import a CA for our EAP-TLS certificates. I'm not remembering the details but unless you connected _exactly_ right on the first try, it would delete the CA certificate and you'd have to start over. There's a lot of other details here but it ended up taking us almost a month to find the exact path to get things up and running. We also paid a vendor (SecureW2) for an app to enroll devices on the network, but Google removed the ability for users to edit configurations generated by apps. Our network required disabling MAC randomization at the time (which Google provides no API for apps to disable). Before the change, users would enroll, and then disable MAC randomization to complete setup. However, because users were no longer allowed to edit these configurations after the app had gotten everything else configured, they were left dead in the water. On the flip-side: Apple makes this very easy and provides a "profile" mechanism that users can download and get everything set up in a few clicks.

shakna 4y ago
> Our network required disabling MAC randomization at the time (which Google provides no API for apps to disable). Before the change, users would enroll, and then disable MAC randomization to complete setup. Yeah, that one I kinda agree with. I don't want most apps to be able to disable that. It's one of the first lines of defense in protecting a device's privacy, and I doubt most people would understand the potential impact if any app could even ask to disable it. That one can be left in the main settings.
- ollien 4y ago
  Yeah, I totally understand why Google did that (though, it's a WiFi provisioning app... it's literally an app that connects you to a previously untrusted WiFi network. I get you gotta draw the line somewhere but that's debatably just as much of a privacy risk). That said, if you decide that it's not allowed to be changed by an app, you gotta let the user be able to make the change...

guerby 4y ago

I've always wondered why OSes don't have a specific CA store just for 802.1x.

ollien 4y ago
Android kind of does. You can mark a certificate for "VPN and Apps" or for "Wifi". I can't remember if you can do it with CAs, but you can definitely do it with the dependent certs.