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.
> 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.
> 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.
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...
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.
"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.
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."
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.
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.
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.
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).
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.
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.
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.
All this achieves is that for people who want to subnet /64 it is not possible on Android without manual setting of the address. (and only on android) Yeah and android doesn't support manual setting of the IPv6 address in the UI, lol.
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.
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.
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.
> I wrote "would allow to force", not that it forces.
Ah sorry, must have misread my bad. All the same I'm not seeing how this plays into why it should be forced, the phone is just half the story (the CLAT) and if the enterprise wanted to implement 464XLAT they can PD and run a NAT64 gateway. If they don't then it's not going to work just because the device has enough addresses to be a CLAT as there is no NAT64 gateway. Or if they just want their devices to dual stack or single stack v6 instead why does Android get to decide they need to support something they aren't using?
> Unless you are turning Android device into router, you won't need PD support there. What else you need prefix delegation for?
The prefix for 464XLAT or to allow tethering. DHCPv6-PD is how you do this when you're not using SLAAC.
> All the same I'm not seeing how this plays into why it should be forced, the phone is just half the story (the CLAT) and if the enterprise wanted to implement NAT64 and 464XLAT they can PD. If they don't then it's not going to work just because the device has enough addresses to be a CLAT.
You are right. I've used that as an example of why a device would want more IP addresses than one. One of aspects of treating IPv6-as-IPv4 is the assumption, that one IP is enough. I get it, it simplifies logging/reverse resolution for example, but one IP might be not enough and the example, while not be the best, illustrates the point.
> The prefix for 464XLAT or to allow tethering. DHCPv6-PD is how you do this when you're not using SLAAC.
There is a difference in scope between PD and SLAAC:
With PD you usually hand out /64 (or bigger) carved out of whatever larger subnet you have. So if your upstream gets you /48 or /56, this is the mechanism to hand out smaller subnets to routers downstream.
SLAAC support allows any device in the subnet to claim any address inside the announced prefix it wants, unless it is already taken and other device objects. There is no limit on how many addresses it can claim, but claiming /64 or more would take a while :). Claiming a few is enough for tethering to work.
SLAAC is what you get wit RA by default; only those that want to force DHCPv6 on their network disable it (yes, I tried that once when playing with it. That playing was great way to understand why it was a bad idea).
With DHCPv6, even if it is supported in the network, doesn't mean you also get PD. It remains completely optional. This is a problem with many CPEs (i.e. with a class of devices it was designed for!), that are supposed to support PD, but the support is either buggy or non-existent, thus their users never have more than /64.
If enterprises have use cases then unless there is a good solid alternative example that shows it's universally the case one should always have many:1 it just doesn't seem like there is anything beyond "I think this is the better way therefore I won't let you do the other" backing the choice. If an enterprise wants 1:1 mapping of their devices using DHCPv6 for centralized logging, tracking, monitoring, avoiding device specific RA bugs/implementations/limitations, to consolidate the function while dual stacked, certain DHCP options to be available, or any other reason they have then someone else's non-applicable use case for many:1 isn't reasoning for nullification of those cases. In general I'm against any approach from a product/service that takes the stance "we just know better" and doesn't allow the operator to say otherwise even when I agree it is actually the superior way in most cases.
Yeah PD will give you a much an overkill block but there isn't really much of a block shortage. More importantly the alternative is NAT44 on the CLAT so only a single V6 address is required, this is actually what the standard says implementations "SHOULD" do in the single IP scenario as after all 464XLAT doesn't support peer to peer or inbound anyways. And of course people and orgs are free to simply want DHCPv6 on their devices even if it isn't perfect for every scenario.
A "Android doesn't want to support NAT44 for 464XLAT, assign a prefix the the device for the 464xLAT use case" stance I could totally understand. Or even "Carriers are not asking Android to support DHCPv6 deployment methods on LTE, DHCPv6 will only be supported on wireless" is very understandable. The current stance isn't like these though, it's simply "we don't like that type of deployment so we don't allow it". Or maybe I've just missed something big and there is a reason I should have forced a couple customers away from their use cases.
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.
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.
> 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.
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.
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.