Welcome!

Wireless Authors: Xenia von Wedel, Pat Romanski, Kevin Benedict, Esmeralda Swartz, Tim Hinds

Related Topics: Virtualization, Java, Wireless, SOA & WOA, .NET, Web 2.0, Cloud Expo

Virtualization: Blog Feed Post

Android and SSL: What Doesn't Work

Of Certs and Self-Signing

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

imageMany 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:

  1. Application level username and password.
  2. Java salted encryption of application password.
  3. Dialogs to ask user to approve exceptions.
  4. An SQLite database of exception information.
  5. 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 Smile.

Read the original blog entry...

More Stories By Don MacVittie

Don MacVittie is a Technical Marketing Manager at F5 Networks. In this role, he supports outbound marketing, education, and evangelism efforts around development, storage, and IT management topics related to F5 solutions. His role includes authoring technical materials, participating in social and community-based forums, and providing guidance for the development of marketing resources. As an industry veteran, MacVittie has extensive programming experience along with project management, IT management, and systems/network administration expertise.

Prior to joining F5, MacVittie was a Senior Technology Editor at Network Computing, where he conducted product research and evaluated storage and server systems, as well as development and outsourcing solutions. He has authored numerous articles on a variety of topics aimed at IT professionals. MacVittie holds a B.S. in Computer Science from Northern Michigan University, and an M.S. in Computer Science from Nova Southeastern University.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.