CertVerifier should check SCT signatures before using SCT timestamps for CRLite coverage checks
Categories
(Core :: Security: PSM, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox144 | --- | fixed |
People
(Reporter: jschanck, Assigned: jschanck)
References
Details
Attachments
(1 file)
CertVerifier currently verifies SCTs after path building / verification because we only apply CT policy to certificates that chain to our root store. The presence of an SCT with an invalid signature will not necessarily result in us showing a certificate error page, and CRLite uses timestamps from SCTs during path building. So there is a possibility that a fabricated SCT can influence the CRLite result but otherwise not affect page load.
As the argument below shows, this only really matters in the case where a secondary revocation checking mechanism is used. Nevertheless, we should separate SCT verification from CT policy evaluation, verify SCT signatures before path building, and only pass verified SCTs to CRLite.
Suppose that an attacker presents a fabricated SCT (one with an invalid signature). Assume that without this SCT the client would have either seen a Result::Success or a Result::ERROR_REVOKED_CERTIFICATE. We claim that if the fabricated SCT causes a different outcome then the following are true:
- the certificate has enough valid SCTs to comply with CT policy, and
- none of the valid SCTs assert CRLite coverage.
For (1) note that if the certificate was not presented with enough valid SCTs to comply with our CT policy, then the certificate will be blocked with a Result::ERROR_INSUFFICIENT_CERTIFICATE_TRANSPARENCY error.
For (2) note that if the certificate is covered by the current CRLite filters, then a fabricated SCT will not change the CRLite result.
It follows that the fabricated SCT asserts CRLite coverage.
Suppose that Firefox would not have performed a secondary revocation check (e.g. OCSP) for this certificate. Then (by 2) the client would have seen a Result::Success return for this certificate. We infer that the fabricated SCT causes CRLite to output "revoked". This is harmless: there is no reason for an attacker to elicit a false "revoked" status. The attacker here is either the CA or the TLS server and can legitimately revoke the certificate.
In the case where Firefox would have performed a secondary revocation check, a fabricated SCT can prevent this check from being performed (because CRLite results are authoritative), and can cause CRLite to yield either a "revoked" or a "not revoked" result.
|
Assignee | |
Comment 1•8 months ago
|
||
Backed out for causing multiple failures
|
|
Assignee | |
Updated•8 months ago
|
|
||
Comment 6•8 months ago
|
||
| bugherder | ||
|
||
Updated•7 months ago
|
Description
•