Android and SSL. What Doesn't Work.

Not so long ago I wrote a blog entry about SSL on Android in regards to some certificates, and mentioned that I would be following up as the work progressed. I have worked through the options and implemented a working solution that I’ll eventually blog about, but this entry is to discuss what doesn’t work, or is a sub-standard solution, what I settled on, and why. It’s light on implementation details, but does offer enough information that interested developers can research a similar solution.

The options I discovered or considered are:

Forcing the user to import the requisite certs
Ignoring all SSL errors
Allowing over-ride of errors globally to the app
Using the browser to implement exceptions to SSL security
Forcing the user to accept problems every time they use the app
Creating a system to securely store exception information and use it every time the app loads

Many developers adopt the first solution because they have static sites the app is accessing, and can simply say “do this once and you don’t have to worry about it again” (until the cert expires). In the case of the app I’m developing, it is designed for use with scenarios where the certs are often self-signed, and in a testing environment, often transient. So this option was not one I wished to pursue.

In the previous blog I mentioned ignoring all SSL errors, and that is a dangerous route I would not ask users to bear. Ignoring errors without asking the user opens users up to Man in the Middle (MitM) attacks. So this one was ruled out from day one – though it appears many developers are going this route.

I did briefly consider in the application options giving the user a check-box to silently over-ride SSL errors. Since this is within the control of the user, it was a better solution, but as most of us know, options like this are set once and not looked at again unless there is a problem. And in the case of SSL MitM attacks, it’s too late when you notice a problem. So I ruled this option out also.

In that previous blog, I had alluded to what I hoped might be a simple solution to the problem. It was my hope at the time that one could simply call the browser using the Android Dev system of “intents” and ask it to open the page, thus using the browsers’ good certificate error handling to create the exception. Except the default browser on most Android devices does not store exceptions – so there was no way to utilize that information from a remote application. Thus, I dropped this line of enquiry also.

It is a relatively easy endeavor to make two dialogs and write a little bit of code to ask the user each time you go out to the web application if they accept the issues with the certificate. One dialog would handle “host name mismatch” exceptions, the other would handle “Certificate Not Trusted” errors – both of which can easily occur in the environment the app will target. I did consider going this route, but the application makes many SOAP calls to the same server over the course of its lifetime, so this would become annoying for users. The only thing worse than having no application is having one that no one wants to use because it’s too painful. So this option was dropped also.

This leaves the last option. It is the most involved, requiring both of the dialogs mentioned above, and more code to handle the exceptions. It also requires the exception information be saved… Which then requires that this saved information be encrypted, since it will reside long-term on the device.

The solution has the following elements, just for those who are looking into this type of thing:

Application level username and password.
Java salted encryption of application password.
Dialogs to ask user to approve exceptions.
An SQLite database of exception information.
Java encryption of all information stored in the database.

This leaves only one issue – how to “untrust” a site. Since this is not a common problem, I will likely put out version 1.0 with only the option to delete the application user, which in turn will delete all exception information. This may sound extreme, but it is a rare scenario, and I have to leave something for version 2.0. Out now, improved later, in the vein of all current development methodologies. In version 2.0 I’ll allow deletion of individual exception information. But you never know, I may decide to side-track and implement this functionality in version 1.0, depending upon the other portions of the development effort.

The information stored in the database is in the form FQDN, username, password. From which the app can then rebuild the SOAP URI. While it wasn’t strictly necessary to encrypt the FQDN, as long as the encryption code was there, why leak information about the network?

It added weeks to my development effort to get this up, running, and thoroughly tested, but it was worth it. When a company throws up a test environment and uses a self-signed cert simply because it is easier, the application needs to support that test environment with a minimum of pain. This is a relatively common occurrence in the space the app is in, so it was worth the effort. Your mileage may vary.

Now, back to actually communicating with the server and giving users the information/control they want .