Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android verifier doesn't consider supplied date for revocation or intermediate roots #59

Open
complexspaces opened this issue Jan 5, 2024 · 1 comment
Labels
bug Something isn't working O-Android Work related to the Android verifier implementation

Comments

@complexspaces
Copy link
Collaborator

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.

@complexspaces complexspaces added bug Something isn't working O-Android Work related to the Android verifier implementation labels Jan 5, 2024
@cpu
Copy link
Member

cpu commented Mar 12, 2024

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.

This would also solve issues like #68.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working O-Android Work related to the Android verifier implementation
Projects
None yet
Development

No branches or pull requests

2 participants