About Those X509TrustManager Emails
Many developers have been receiving emails from Google discussing
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
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
for ordinary SSL work. If you are trying to deal with a self-signed
SSL certificate, rather than use a flawed accept-all
use one that handles the self-signed certificate. I have support for
that scenario in my
TrustManagerBuilder in my
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
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.
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
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.