Let's start with an easy, common issue. Self signed certificates. There are many tutorials on the net about how to configure WPA/WPA2-Enterprise using self signed certificates. I would imagine that for any IT person that is trying to wrap their heads around 802.1X/WPA/WPA2-Enterprise, they are one of the first stops. Hopefully, Android isn't running on their primary test device.
If you attempt to use a self signed certificate on Android, it will usually fail. I have run across the occasional device that doesn't have this problem, but 'stock' Android like that found on the Nexus series generally has this problem.
Not being able to use self signed certificates is annoying, and it leads us nicely in to the next Android annoyance. To paraphrase, "If an Android fails to authenticate, and nobody is watching the logs, did the authentication actually fail?" I think the best answer is, "If I didn't get my network access, then yes, it failed." However, because Android didn't tell you that it failed, you may be sitting there for some time before you realize something is wrong.
Let's jump back to the self signed certificate issue I mentioned above. I like to say that in the event of an error case, the program usually has some idea of what went wrong. It just needs to present that information to the user in a useful way. This case is no different.
Under the hood, Android uses wpa_supplicant to handle authentication 802.11 management and authentication. In the self signed certificate case, wpa_supplicant will produce an error such as this :
TLS: Certificate verification failed, error 18 (self signed certificate)
This error is usually surrounded with a bunch of OpenSSL error codes so many people just "check out" when reading the logs, and don't notice it. On Android, it is a little bit worse. This error message is buried in a log that the average user probably doesn't even know exists. So, how does the user know what went wrong?
In this example, the user figures it out after sitting there for a while and they don't get a connection to the network. But, once they have come to the conclusion that they can't get on the network, what are they supposed to do? Worse, what is the helpdesk call going to sound like? I need you to summon your best red-neck, inbred, hillbilly with buck teeth accent and said, "It's broke". ("It don't work" is another wonderfully helpful description.)
Since most users have a really short attention span, at this point they wander off to complain to anyone they can that the network is broken. When a coworker or friend says, "Yeah, but it works for me." that will change to "Wireless is broken on Android."
The reality is that Android's wireless is NOT broken. Well, maybe not very broken. When the wireless hardware is behaving itself, wpa_supplicant does a fine job of getting you connected. You just have to be running something like CatLog, or have a development environment set up that will let you run "adb logcat". Then, you have to know enough about 802.1X authentications, and certificates to be able to recognize the one log line that tells you everything you need to know about the failure. That should be easy enough. (In case you are missing my sarcasm, consider trying to talk your mom through figuring this out over the phone.)
While I use the self-signed certificate issue as an example of the problem, it is just the tip of the iceberg. Other similar issues, that you won't hear about, include :
Here, you will find your next issue. Section F, item 2 basically says that CAs can no longer sign certificates with their root certificate. Or, in other words, all certificates have to be signed by an intermediate CA cert. Now, I understand that Microsoft isn't a standards setting body, so CAs don't have to comply with these rules. However, as Microsoft is still a dominant OS provider, CAs that don't comply won't be allowed in the shipping Microsoft cert store. Based on this, it is pretty reasonable to assume that most CAs will follow these rules.
TLS: Certificate verification failed, error 18 (self signed certificate)
This error is usually surrounded with a bunch of OpenSSL error codes so many people just "check out" when reading the logs, and don't notice it. On Android, it is a little bit worse. This error message is buried in a log that the average user probably doesn't even know exists. So, how does the user know what went wrong?
In this example, the user figures it out after sitting there for a while and they don't get a connection to the network. But, once they have come to the conclusion that they can't get on the network, what are they supposed to do? Worse, what is the helpdesk call going to sound like? I need you to summon your best red-neck, inbred, hillbilly with buck teeth accent and said, "It's broke". ("It don't work" is another wonderfully helpful description.)
Since most users have a really short attention span, at this point they wander off to complain to anyone they can that the network is broken. When a coworker or friend says, "Yeah, but it works for me." that will change to "Wireless is broken on Android."
The reality is that Android's wireless is NOT broken. Well, maybe not very broken. When the wireless hardware is behaving itself, wpa_supplicant does a fine job of getting you connected. You just have to be running something like CatLog, or have a development environment set up that will let you run "adb logcat". Then, you have to know enough about 802.1X authentications, and certificates to be able to recognize the one log line that tells you everything you need to know about the failure. That should be easy enough. (In case you are missing my sarcasm, consider trying to talk your mom through figuring this out over the phone.)
While I use the self-signed certificate issue as an example of the problem, it is just the tip of the iceberg. Other similar issues, that you won't hear about, include :
- The certificate isn't yet valid.
- The certificate is no longer valid.
- Your authentication failed.
- MS-CHAPv2 messages such as 'invalid password', or 'your password has expired'.
- And many, MANY others.
Let's assume that you understand these issues, have the tools to figure them out when they happen, and work in a small enough business that the helpdesk can go through this dance with everyone in the company. Out of nowhere, you get slammed with an issue you CAN'T fix!
The problem this creates for Android shows itself when you try to install a chain of certificates on Android. I was unable to find any sane way that worked. Digging in the Android source code seems to indicate that cert chains can be installed using PKCS#12 certificate bundles. However, Android seems to insist that PKCS#12 certificate bundles contain a user cert. In other words, if you are using anything but EAP-TLS, you probably can't use PKCS#12 bundles to get your certificates in the store.
It may seem reasonable that creating a PEM file that has multiple certificates in it would get around this issue. However, if you try that, you are presented with the following dialog :
Note that the dialog indicates that there is only one CA certificate that will be installed. If you complete the installation, and set up a new wireless authentication using this certificate, you will find the connection doesn't work. If you happen to have CatLog, or a development machine around you will see in the logs that the certificate chain failed to validate.
If you can't use self signed certificates, and can only buy certificates that are chained, it starts to become clear that the 802.1X/WPA-Enterprise/WPA2-Enterprise authentication on Android is darn near unusable. You either need to find a CA that is willing to go against Microsoft. Or, you have to choose not to use certificates in your authentications. (Which, is a *BAD* idea!)
I just want to restate that Google has been made aware of these issues. However, it was recent enough that they probably haven't had time to do anything about it, let alone get anything fixed and released. Also, since I get really annoyed with people that like to complain, but don't offer any real solutions, I will be submitting patches to Google that will hopefully start to fix some of these issues. At a minimum, hopefully Google can use my patches as a jumping off point for a good fix.
No comments:
Post a Comment