About Those X509TrustManager Emails

Many developers have been receiving emails from Google discussing an X509TrustManager problem:

Your app(s) listed at the end of this email use an unsafe implementation of the interface X509TrustManager. Specifically, the implementation ignores all SSL certificate validation errors when establishing an HTTPS connection to a remote host, thereby making your app vulnerable to man-in-the-middle attacks.

To properly handle SSL certificate validation, change your code in the checkServerTrusted method of your custom X509TrustManager interface to raise either CertificateException or IllegalArgumentException whenever the certificate presented by the server does not meet your expectations.

This means that someone, somewhere, screwed up SSL handling in your app, such that you are blindly accepting all SSL certificates, without consideration for whether or not they are valid.

There are two possibilities: you screwed up, or a library author screwed up for some library that you are using.

At least some versions of the email appear to point out specific class names of the offending X509TrustManager implementation (e.g., ti.modules.titanium.network.NonValidatingTrustManager). In that case, finding out whether it is your code or a library’s code should be fairly straightforward, as either this is your class or not. You could also search for implements X509TrustManager in your code base, to see if you have this somewhere and see whether the implementation actually examines the certificates or not.

If you have a flawed implementation, remove or replace it. You do not need a custom X509TrustManager for ordinary SSL work. If you are trying to deal with a self-signed SSL certificate, rather than use a flawed accept-all TrustManager, use one that handles the self-signed certificate. I have support for that scenario in my TrustManagerBuilder in my CWAC-Security library. And if you don’t want to depend on the library, the code is Apache License 2.0, so borrow bits if you want.

If it is coming from a library, see if there is a newer version of the library. Older versions of ACRA, for example, apparently contained such an X509TrustManager, but newer versions do not. If you cannot find a newer version of the library that removes this flaw, contact the library authors and consider switching to a replacement library.

Now, it is entirely possible that Google’s scanner has its own flaws. Perhaps the X509TrustManager exists in the APK but is not being used (in that case, see if you can adjust ProGuard settings to get rid of it). Perhaps it is valid, but Google’s algorithm for determining whether one is or is not valid has a bug. For that, you will have to hope that Google fixes things before their May 17th deadline for getting flawed X509TrustManager implementations out of the Play Store.

Yes, this is a headache. OTOH, this particular flaw has led to FTC lawsuits here in the US (see Fandango and Credit Karma). This flaw leaves your app vulnerable to MITM attacks. For the security of your users, you owe it to them to fix this problem, and fix it correctly.