URLRequestContextBuilder should initialize a default CT state
When using a URLRequestContextBuilder, the URLRequestContext
it built would not be initialized with any Certificate
Transparency logs. This is because CT logs are a policy of the
embedder. Without any CT logs, all certificates naturally fail
any CT policies the embedder has set.
With no way to override this on the URLRequestContextBuilder,
any CA which has CT compliance enforced on it will be rejected.
This is because per-CA policies are enforced at the //net layer
as part of a 'secure by default' policy, and thus fail closed.
The result is that embedders that used URLRequestContextBuilder,
such as Android WebView, rather than building URLRequestContexts
themselves, such as Chrome does, would reject certs from some
CAs. While this could be overridden by manipulating the
TransportSecurityState of the URLRequestContext that was built,
doing so would result in a less-secure solution.
This CL mitigates it two-fold, by allowing the embedder to specify
their own CTVerifier to handle evaluating Certificate Transparency
information, and if they fail to, by initializing with the set
of logs known to //net and trusted by Chrome according to the
Chrome CT policy. This gives embedders a sane default, while still
allowing them to override with their own application policies.
This doesn't fully bootstrap a CT enforcement for embedders, as
things like consistency proof fetching are concepts that extend
beyond the URLRequestContext (and handled by the IOThread in
Chrome), but offers a reasonable baseline. This also helps ensure
things like Expect-CT work consistently for embedders.
BUG=628421
Review-Url: https://codereview.chromium.org/2161983003
Cr-Commit-Position: refs/heads/master@{#406455}
2 files changed
