Starting this thread to discuss and coordinate efforts toward the fix for this bug.
Wondering if I should copy the contents of the private message from Walter here, as this is a secret group. These discussions are not meant to be shared openly, as this group is by invite only.
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.
Gotta get Styrix and Tim Jentz into this thread.They work with me and will take a look.
The missing checks don’t appear to be too difficult to figure out, but I do know a former coworker who I believe knows this stuff really well. I am going to try to get in contact with him tomorrow and see what information I can get.
In any case, I think the first step to resolving this is to set up a test suite that will fail with the current code. That will be the best way to know we have actually fixed it.
Anyone got some experience with generating certs that we can use as part of a testbed. We will need certs with chains at different depths, with varying problems such as no basic constraints, failed basic constraints and in/valid certs.
I think it’s time that we go pulibc with this issue, I see no reason why this should be kept secret: Full disclosure.
And maybe this should be reported to CERT.