Network May Be Monitored By A Third Party (a.k.a. Android KitKat scary warning message part 3)

I guess people care about this annoying warning message that Android has thrown on us.   No other blog post here has generated anywhere near the number of hits that this issue has generated.  So, to all of your that have found my blog and read what I have to say, I thank you!

Unfortunately, Google doesn't seem to care about this issue.   (Newsflash!  Google doesn't care about making certificates easy to use on Android.   And, by extension, they don't care to make wireless authentication on Android usable either!   I could write volumes on my experiences trying to get things improved.  But, I fear that it would inspire depression in anyone that read it.)   So, we need to do something to try to GET them to care!

There have been several bugs opened about this problem, and most of those bugs have been closed with various reasons that make no sense.  (Which is what I base my claim that they don't care on.)  Some of the other people on the Internet that agree with me that this is a problem have continued to open new bugs to continue to push the problem and make Google listen.   If you care about this problem, PLEASE go to the Google bug tracker, and at least star the issue.   If you have the time, you might consider posting a comment to the bug that outlines why this issue causes you grief, and what changes you would like to see made in order to improve the situation.   (If you are only going to complain, do us all a favor and just star the issue.   If you want to complain, and offer suggestions on how to improve things, please post a comment!)

I'll even make it easy for you.   The URL (with link!) to the current version of the bug is at : https://code.google.com/p/android/issues/detail?id=82036 .


As you make your feelings known, please consider this.   There is actual value in having a warning like this, if you are the kind of person that values privacy and is against network operators using man-in-the-middle tactics to monitor what you are doing.   And, thanks to stupid legislation here in the US, if you are attending a K-12 school that provides Internet access, you SHOULD care about this very much!   US law requires the schools to snoop on students as a condition to continue to receive funding!    I'm lazy, so I am not going to track down the exact law that requires this, but I know it is true because of my day job.   (Not going to say any more than that because my opinion might get me in trouble.)

Because I would prefer that people being snooped on are given any warning that it could be happening, I am actually in favor of the warning message that was added.   However, I have problems with how it was implemented.   I think there are a few tweaks that could be made to the implementation that would take this from being a pointlessly scary warning message to a valuable warning message, and an opportunity to educate at least a few people on some of the security issues that are associated with installing new root CA certificates on any device or OS.   Also, as I have stated before, I don't like people that complain about a problem without offering solutions!

So, here are my suggestions on how to transform the annoying mess that is the "scary certificate warning message" in to something useful and significantly less annoying :

• Don't show the message (ever) if the certificate is used with 802.1X on a Wi-Fi connection -- Starting with Android 4.3, the "Credential Store" (a.k.a.  Certificate store, or key store) has been split in to two parts.  One part holds the certificates that will be used for authentication on Wi-Fi networks.   The other part holds certificates that are used for VPN connections, web site connections, and everything else.   Since you *HAVE* to install a certificate in order to securely use a Wi-Fi connection, showing this warning message is pointless.  The other alternative is not to use a certificate to validate the Wi-Fi network, which leaves you WIDE open to anyone doing a man-in-the-middle.   So, the scary warning actually has the potential to make users LESS secure by making them remove the certificates necessary to secure their networks!   Google must recognize this on some level, because they don't show the warning if an app uses the Wifi API to install certificates.
• When you tap the warning, give useful information --  Right now, when you tap the warning, you are taken to the security settings screen.   This is COMPLETELY useless.   The user is expecting to be given more information on what this warning is all about.   Take them to a screen that explains what the potential issues are with installing a new CA certificate.   Explain clearly what the problem is, and don't try to scare them in to submission.  Try to give the user enough information to allow them to make a good decision about leaving the certificate installed.   Also, provide links to more detailed information so that those that are really curious can really dig in and understand the problems.
• Allow users to get rid of the warning -- Right now, you can dismiss the warning, but it comes back any time you install another CA cert, or anytime you reboot your device.   This behavior is annoying.   Tell me once, let me decide what to do, and then leave me alone!  Anything else is a bad user experience.   When the user taps the warning to get more information about what it is about, they should also be given two check boxes.   One check box should allow them to dismiss the warning just for the current certificate, the other should allow them to block ever showing it again.   There really are two types of users where this warning is concerned.  There are those that already understand the risks, and those that don't care.   The purpose of the warning to to try to get some of those that don't care to actually start to care.  But, annoying the crap out of them is only going to make them hate the issue so much that they will never care.

If my three suggestions above were implemented, I suspect most people would no longer hate the warning message as much as they do now.   It also gives the power back to the user, which is what I always thought Android was supposed to be about.

I understand that in addition to warning users that they may be causing themselves problems, they are probably also trying to cover their butts should a bunch of users get hacked and complain in the media, or worse, try to sue.   However, I really believe that showing the warning once is more than enough for Google to cover their butts on this.

In the unlikely event that someone from Google reads this, and wants me to put my money where my mouth is, I will offer to submit patches to the AOSP project to implement all of the things above.  HOWEVER, given my previous experiences with submitting patches to AOSP, I will be expecting a promise that the code will eventually be included.   By "eventually", I mean that someone from Google will be assigned to review my code, and comment on it until the code is in the right state to be fully included in AOSP and eventually the main Android builds.   (As an aside, while I have tried not to give out any information on this blog about who I am, I am sure that Google has the ability to look up my e-mail address based on this blog being hosted on Blogger.   There is also someone on the Android dev team that knows me, and someone on the Android security team that knows me.  So, it should be easy enough to verify that I know what I am talking about, and it should be easy to reach out to me.)

Meru configuration, part 1

As promised, I am going to give the QuickPhones phone a shot with the Meru gear. But first, I need to get the gear set up.

A quick rundown of what my configuration will look like :
1 - Meru MC 500 controller running version 3.4-103 software
1 - Meru MN-AP320
1 - Meru MN-AP201RH

I powered up the unit, and plugged in to it via a USB->Serial dongle. As the instructions indicated, I set up the serial port to 115200,8,N,1. I watched as the controller booted some flavor of Linux, and then hung on the "Starting Meru 3.4-103 wireless LAN services ...". After sitting for a while, I figured something was wrong, so I power cycled the box to see if it would come up a little quicker. (It didn't.)

I figured there was something wrong with my unit, so I pulled up a text editor to start writing my blog entry about how much I would have loved to write the entry about the QuickPhones with Meru. While I was getting everything together, the console spit out an error message, and then prompted me for a login.

I went ahead and put the default admin/admin username and password and got the console prompt back. At the console prompt, I ran the "setup" process. After answering the normal questions (ip address, gateway, netmask, etc.) the unit asked if it could reboot. (So I let it. Shocking, huh?)

Fortunately, it rebooted a lot faster than the initial boot. After a minute, I was able to log in and was back at the command prompt.

Normally, I am the kind of person that hates to configure gear with the web interface. But, in this case I decided to make an exception since the goal is not to evaluate the Meru gear, but rather to see if the phone works better on it. I fired up Firefox, and hit the web page. At this point, I was informed that I needed to use Internet Expoliter to access the UI on the box. (As an aside, I am sure that the version of code I am using is older. But, I still have to say, REALLY!? *sigh*)

Since I am already inflicting punishment on myself, I figured I would give IE 8 x64 a shot. When I hit the web site, I was first told that the certificate on the unit was suspicious (which is normal on gear like this), and after telling IE it was okay to continue, I was prompted for the username and password.

The UI that was displayed is reasonably clean, but doesn't show any useful information initially. (Probably because I don't have any APs it can talk to.) So, I pulled out the AP201RH. The first thing I noticed is that the AP appeared to want power over ethernet (PoE). So, I tried plugging it in to port 2 on the controller in hopes that it would power on. But, it seems that either port 2 doesn't do PoE, or there is some configuration setting that I need to enable before it will do it. Again, since I really want to get to the QuickPhones testing, I just took the AP in to another room that had a PoE port that I knew would work.

I managed to get the AP201RH up and running easily enough. So I plugged in the AP-320 so I could get it configured and ready to rock. Unfortunately, the AP-320 is running a different version of code, and try as I might, I am unable to upgrade, or downgrade it. Since the controller sees the AP as an AP-100, I am guessing this is a good thing.

Unfortunately, this is a dead end for this effort. I'll have to see if I can track down my friend at Meru to see if I can get some help. (The gear I have is test gear, so I don't have a maintenance contract to get the latest versions of code.)

I hope to have more in the coming weeks, assuming I can reconnect with an old friend.