prbprbprb
commented
4 years ago Apologies for reporting this here
Nah, don't worry. Unfortunately AOSP issues sometimes bounce around in triage for a while before they find their way to us.
Android 9's BoringSSL's X509_verify() is rejecting one of your intermediate certificates but for some reason failing to set the error queue before returning. I skimmed the code path and I don't see any obvious ways it can return without doing that but I wasn't exhaustive. @davidben has been fixing issues around the error queue during verification recently so he might remember if there were issues here in the Android P timeframe.
The higher level code is trying to built a trust chain through the intermediate certs to a trust anchor, using either the certificates provided by the peer or in this case a cache of previously seen intermediates. Any cache hits get their verify() method called and that's where the exception is getting thrown.
There are arguments for and against the intermediate cache (we recently discussed removing it), but the idea is to make things go better when not all servers for a site are not sending a full certificate chain.
So the sequence looks something like:
- The trust manager instance in your app sees and caches an intermediate CA cert (let's call it
Intermediate) which (a) fails verification (b) without generating a useful error message. It's possible that both (a) and (b) are fixed in Android 10, I haven't done all the archaeology. Certainly there have been changes in that area ofTrustManagerImpl. - Time passes
- The app connects again (possibly to a different endpoint?) and gets presented your new server certificate (let's call it
Leaf) with issuerIntermediatebut the trust manager isn't able to build a chain of trust using the certificates provided by the server, which may be becauseIntermediatewasn't included or because some other link in the chain isn't trusted. - Trust manager looks in the intermediates cache for
Intermediate, finds it and explodes.
If you're able to reproduce this yourself, the list of certificates passed into RootTrustManager.checkServerTrusted() would be helpful, or failing that just point me at the server and I ought to be able to reproduce it from the certificate chain.
Note that X509Certificate.verify() is just doing structural checks on the certificate itself, so somewhere in here there's an intermediate certificate that either BoringSSL thinks is invalid or that triggers a bug on Android 9 BoringSSL, or that Conscrypt is somehow corrupting. If it's one of the latter two then a timely fix for Android 9 is going to be difficult.
davidben
swankjesse
Apologies for reporting this here instead of the AOSP tracker. In my experience that tracker is a black hole!
We saw this crash across many different app releases and device manufacturers. The only thing in common was it was always Android 9.
Looks like the offending line of code is here in Conscrypt:
The exception is:
The crashes coincide with us updating our TLS certificates. The new certificates share the same root and intermediary as the previous certificate. The leaf certificate has a different expiration date.
Is it possible that Android 9’s Conscrypt crashes as-above when certificates are rotated? Perhaps it was remembering the certificate from a previous HTTPS connection? Is Conscrypt configured differently in any meaningful way in Android 9 vs. 8 or 10?