Scary App Games. SSL without benefit.

#androidDev When an SSL enabled app isn’t, and how easy that is to implement.

Remember the Maginot line and how powerful and defensive it was going to be… And then the Germans just bypassed it? Remember the West Wall, where the Allies were going to throw themselves against in the waning days of World War II… And then it was not just pierced but effectively eliminated as a protective barrier in five days of fighting?

That’s what happens when you know you need a defense, and you place all of your eggs in one basket. At least in the IT world a little caution can save you a lot. Here’s a cautionary tale. We trust SSL explicitly, but from a “download random app X” perspective, that’s a mistake.

I’ve been spending my evenings on a home project developing an app for the Android. There are a ton of things that the app needs to work, so when I hit the “must communicate with SSL” part, I wanted a quick fix work-around for prototyping because my test site’s SSL cert was both self-signed and had a host name mismatch. I researched and settled on the solution for the final app, but in the interim, I came across some interesting ideas on how app developers can resolve SSL problems…

There are several excellent (if excellent is the correct term) examples out there for how to completely avoid SSL benefits while using SSL. Some of the app developers you’re getting apps from are using them too. I refuse to link to them here, but I’ll just give you the business level overview…

There is a class in Java called a Trust Manager. It’s job is to validate SSL certificates. Two common problems are with self-signed and hostname mismatched certificates. The problem is that the default action of the classes in Java is to reject either one automatically, causing connections to servers those certificates were retrieved from to be blocked. There are several good solutions to this problem, and all only require a few steps. The steps are beyond the scope of this blog, but I have a theory for a really simple solution that I’ll blog about if it works as I think it will (can’t test it at the moment, building new Dev machines for Lori and I is taking night-time precedence over this development project).

You would be amazed at how many forums have the suggested solution of over-riding (subclassing for the devs in the audience) the X509 Trust Manager and approving EVERY connection.  No checking at all, just return “True” from all of the “is this valid” methods. If you also over-ride the HostNameVerifier and always return “true” to say “the host is good” no matter what. It works for every site imaginable. It also allows for MiTM attacks, bogus sites where you think you’re protected, all sorts of things. So in short, it gives you all of the overhead of SSL and none of the protection. Kind of like collecting candybar wrappers. They may look good, but you can’t enjoy them.

In the current environment, your users are downloading all sorts of apps. And they have no clue what is done with SSL within apps that claim to use it. And that might just cause your users, with some amount of corporate data on their devices, to be a source of data leakage. There is not a really solid way of testing if an app is using a bogus trust manager (because the dev was not good enough to implement an actual solution) in an enterprise environment, but there are ways to test for symptoms. Set up an SSL protected server with self-signed cert, and connect to it. If the app doesn’t ask you to confirm the exception, I’d be suspicious. Then change the server name without updating the cert. If the app doesn’t ask you to confirm the exception, I’d be suspicious.

If you’re a developer, those sites telling you to build a trust-everything manager are NOT offering a viable solution. Most caveat their solutions with that commentary, but some do not. While I did use it for testing, there is not a valid use to ship an app with that kind of abomination inside of it.

If you’re an enterprise, consider setting up a simple test server and asking your staff to use it on new apps. It may be paranoid, this is certainly not the worst security threat that downloaded apps create, but it’s simple to set up a test server, and at least then you’ll know for certain if a given app is a risk.

And check any outsourced apps you have had developed. A simple text search to look for HostNameVerifier in the source tree and then look for the verify() method. If it returns true always, you outsourced to the wrong developers. This is only one of the places the code has to be bad to implement “trust all hosts” though, so just get solid developers to look it over if you find this problem.

Better safe than sorry. Just saying.