Well, it is not caused by the misuse of checkServerTrusted() with a non “HTTPS” authType argument, which is the problem described in the paper. Since we use our own ServerTrustManager with extends X509TrustManager.
The problem seems to be in ServerTrustManager.checkServerTrusted(), as the Google Eng said, we do not check X509Certificat.getBasisConstraints and the name constraints. The problem is described in detail here: http://www.thoughtcrime.org/ie-ssl-chain.txt
The basic constraint fix should be relativly easy. Just check that every cert that acts as (intermediate) CA has basisConstraints set and if the deep is correct.
I am not sure what they main with name constraints. I would first guess config.isNotMatchingDomainEnabled(), but this code looks correct to me. Would be interesting to get feedback from google about this.
As for aSmack: Georg Lukas has written a so called “MemorizingTrustManager”. It comes in handy when working with self-signed SSL certs, which is very common in the XMPP world. Basically it remebers the certificate once and checks the fingerprint before every suceeding connection. A principle we all know from modern browsers. If the Memorizing Trust Manager finds a cert chain a fallback to Androids default TrustManager kicks in. I assume google doesn’t have the same bug in their code which they notifiy library developers about.