You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today in the Android verifier, we only check the end-entity's validity against the timestamp provided by rustls. The revocation status and intermediate CA's validity uses the system's current timestamp. While this doesn't result in any security issues, it makes consistent testing harder.
To fix this, we need to use a use the setDate method of PKIXParameters. We already construct one of these for checking revocation, but we're using TrustManager.checkServerTrusted for the rest of the chain. Android's trust manager defaults to using the current date, with no way to override it here.
Modifying the logic to do everything with one verifier will be tricky, if not infeasible. This is because the Conscrypt TrustManager checks for Android-specific CA blocklisting and CT/pinning requirements, and we definitely want to keep that functionality so Android matches what Apple and Windows are doing. As is, I'm not sure how to solve the intermediate time period problem. Even if we tried doing two validations with each API set, we most likely wouldn't (unless the system already knew about every intermediate and root) see any blocklist errors because Conscrypt checks validity early. From reading through the implementation, my conclusion is that while including intermediates provided by the server an expired one would fail early before it had a chance to check it against the blocklist :( To fully resolve this, and get the best of what the platform has to offer we really need the ability to pass a timestamp into checkServerTrusted.
With all that said, a partial and feasible fix is to just start setting the datetime for our revocation checks and use the fact intermediates don't expire often to hopefully treat this a non-issue in practice.
The text was updated successfully, but these errors were encountered:
With all that said, a partial and feasible fix is to just start setting the datetime for our revocation checks and use the fact intermediates don't expire often to hopefully treat this a non-issue in practice.
Unfortunately, this won't solve the problem of end entity certificate expiration breaking Android integration tests :'( In practice checkServerTrusted is enforcing the validity of the leaf and intermediates, and leaf certs expire often.
Today in the Android verifier, we only check the end-entity's validity against the timestamp provided by
rustls
. The revocation status and intermediate CA's validity uses the system's current timestamp. While this doesn't result in any security issues, it makes consistent testing harder.To fix this, we need to use a use the
setDate
method ofPKIXParameters
. We already construct one of these for checking revocation, but we're usingTrustManager.checkServerTrusted
for the rest of the chain. Android's trust manager defaults to using the current date, with no way to override it here.Modifying the logic to do everything with one verifier will be tricky, if not infeasible. This is because the Conscrypt TrustManager checks for Android-specific CA blocklisting and CT/pinning requirements, and we definitely want to keep that functionality so Android matches what Apple and Windows are doing. As is, I'm not sure how to solve the intermediate time period problem. Even if we tried doing two validations with each API set, we most likely wouldn't (unless the system already knew about every intermediate and root) see any blocklist errors because Conscrypt checks validity early. From reading through the implementation, my conclusion is that while including intermediates provided by the server an expired one would fail early before it had a chance to check it against the blocklist :( To fully resolve this, and get the best of what the platform has to offer we really need the ability to pass a timestamp into
checkServerTrusted
.With all that said, a partial and feasible fix is to just start setting the datetime for our revocation checks and use the fact intermediates don't expire often to hopefully treat this a non-issue in practice.
The text was updated successfully, but these errors were encountered: