1429800 - (crlite) [meta] Implement a CRLite based revocation mechanism

Status: NEW

(Core :: Security: PSM, task, P3)

Comment 4

[Victor Porof [:vporof][:vp]]

Making this depend on ship-rkv meta instead of multiple individual bugs.

Comment 5

[John Schanck [:jschanck] (out of office Aug 11-18)]

Release Note Request (optional, but appreciated)
[Why is this notable]: CRLite is a state-of-the-art certificate revocation checking mechanism that will have a positive impact on the security, privacy, and performance of Firefox.
[Affects Firefox for Android]: no
[Suggested wording]: We are gradually rolling out the CRLite certificate revocation checking mechanism.
[Links (documentation, blog post, etc)]:
https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/

Comment 6

[Lukas Tribus]

Hello,

as Let's Encrypt no longer provides OCSP for new certificates, revoked LE certificates are accepted in current Firefox stable versions on both Desktop and Android:

https://crltest1.ltri.eu
https://crt.sh/?id=18272771084

I was under the impression that CRLite would be enforced starting FF 137, however it looks like the default in FF 138 stable is still security.pki.crlite_mode = 3, which is unable to detect revoked certificates without OCSP.

Is there a timeline for defaulting crlite_mode to 2 in stable?

Thanks

Comment 7

[John Schanck [:jschanck] (out of office Aug 11-18)]

Is there a timeline for defaulting crlite_mode to 2 in stable?

I don't have an exact timeline, but the answer is "soon".

For what it's worth, CRLite results are already enforced (even with security.pki.crlite_mode = 3) for certificates that have no OCSP information in the AIA extension (https://searchfox.org/mozilla-central/rev/3a5ab81ad35fa4ab14ae75bf7549c8996ca49008/security/certverifier/NSSCertDBTrustDomain.cpp#812-818). CRLite results are also enforced when the OCSP server is not responsive. So CRLite will be enforced for new LE certificates before we change the value of security.pki.crlite_mode.

Comment 8

[Lukas Tribus]

That would be great, but I'm not seeing that at all.

To be clear, LE certificates issued on May 7th and later do NOT have OCSP in AIA.

https://crltest1.ltri.eu does NOT have OCSP in AIA, was revoked on May 7th - 9 days ago - and is not rejected in a fresh Firefox profile on FF 138.0.3 on Windows and Android.

Steps:

1. Install Firefox 138.0.3

2. Start for the first time in a fresh profile

3. wait for 5 minutes for any crl downloads

4. access https://crltest1.ltri.eu should be rejected but is not

5. Close Firefox.

6. Check task mgr for lingering Firefox instances

7. Start Firefox again

8. Wait for 5 minutes again

9. access https://crltest1.ltri.eu should be rejected but is still not

10. Repeating steps 5 - 9 again in case it needs 3 starts to trigger: certificate is still not rejected

Actually while I am sure I was able to get Firefox to reject this domain 9 hours ago when setting crlite_mode = 2, now I'm no longer able to get the certificate rejected at all, not even when setting crlite_mode = 2.

I'm genuinely confused.

Comment 9

[John Schanck [:jschanck] (out of office Aug 11-18)]

CRLite artifacts are downloaded to <profile dir>/security_state. If the artifacts were downloaded successfully, you'll see several *.filter.delta files and one crlite.filter file in that directory. In my tests, access to https://crltest1.ltri.eu is blocked with crlite_mode = 2 and crlite_mode = 3 when CRLite artifacts are present in the profile directory. So my best guess is that artifacts simply were not downloaded in your tests.

Polling for new artifacts currently happens on an idle timer, so 5 minutes may not be sufficient (especially if you are browsing during those 5 minutes). If you install the remote settings devtools extension you can force an update to the security_state/cert-revocations collection to ensure that you have fresh artifacts.

Comment 10

[Lukas Tribus]

Hello,

I can confirm now that when security_state is populated in Firefox 138, the certificate is rejected in the default setting, which is the behavior I wanted to see, thank you.

However on Firefox ESR (v128) this still does not appear to work, despite bug 1773371 being solved in v103 3 years ago? <profile dir>/security_state only contains data.safe.bin so perhaps it's expected that ESR does not have working crlite?

Does this mean that Firefox ESR users will only be covered with the automatic upgrade to v140.3 mid September?

What is the situation with Thunderbird for StartTLS and SSL/TLS connections to IMAP/POP3/SMTP connections? security_state appears to remain empty even on Thunderbird 138 (did not try Thunderbid ESR 128).

Also I cannot get Firefox Mobile (Android) to reject the certificate yet.

Is crlite currently only supposed to work in Firefox stable, excluding ESR versions, Thunderbird and Firefox mobile?

Thank you!