Closed Bug 1667179 (CVE-2020-26957) Opened 10 months ago Closed 9 months ago

OneCRL does not appear to be working in Fenix

Categories

(GeckoView :: General, defect, P1)

Unspecified
Android

Tracking

(firefox82 wontfix, firefox83 fixed, firefox84 verified)

RESOLVED FIXED
83 Branch
Tracking Status
firefox82 --- wontfix
firefox83 --- fixed
firefox84 --- verified

People

(Reporter: April, Assigned: agi)

References

(Regression, )

Details

(Keywords: sec-moderate, Whiteboard: [geckoview:m83][adv-main83+])

Attachments

(3 files, 1 obsolete file)

OneCRL (Remote Settings) does not appear to be working in Fenix, meaning that Fenix currently has no way to revoke misissued or malicious certificates. This may be related to bug 1625257, if Remote Settings uses storage.sync.

This was first reported here:
https://github.com/mozilla-mobile/fenix/issues/14597

With the thought that https://revoked.badssl.com/ was not added to OneCRL, and so therefore didn't trigger the revocation error. However, it was added in bug 1664854 and the error persisted, bringing to light the fact that OneCRL-based certificate revocation appears to be completely nonfunctional in Fenix.

:dveditz, should we remove this (currently innocuous) looking bug from Github?

Flags: needinfo?(dveditz)

I've confirmed that the update pref we'd expect Gecko to increment on OneCRL updates remains uninitialized at 0 in Fenix Nightly, which agrees with the idea that OneCRL is not updating / has no data on Fenix.

OneCRL is our mechanism for addressing compromise or malpractice ("misissuance") by Certificate Authorities, including those currently unknown (e.g., https://blog.mozilla.org/security/2019/08/21/protecting-our-users-in-kazakhstan/ ).

For most Firefox users, OneCRL is delivered in their install package (in /defaults/settings/security-state/onecrl.json, packaged here), and then the Kinto Client keeps it in-sync with periodic updates at Remote Settings; the deltas are typically about 100 bytes, consisting of a couple of strings, and occur on administrative action (e.g., rare, only when necessary). They do get broadcast by Megaphone, but normally on the daily kinto/remote settings check, Firefox gets OneCRL diffs, if any.

OneCRL today is larger than it needs to be, because Firefox 68 clients don't cleanly support removal from OneCRL. We intended for shorten OneCRL this week, but held off since Tor hasn't moved from ESR 68 yet. Anyway, typically the compressed OneCRL state is rolled into the installer and pretty small (540kB uncompressed, 72 kB with bz2).

Who owns this Fenix/A-C or GV?

Flags: needinfo?(snorp)

I think we can leave the public github issue alone for now (that is, don't try to hide it). There are other bugs noting that Focus, for example, also doesn't support OneCRL, and other places that mention testing against revoked.badssl.com so we'll probably just get dupes if we take it away. But we should stop poking at the GH version of this bug and continue here while trying to work out why it isn't working.

Flags: needinfo?(dveditz) → needinfo?(s.kaspari)

jc: would you call this sec-moderate or sec-high?

Flags: needinfo?(jjones)
Keywords: sec-moderate

I agree with sec-moderate. Obviously this is a mitigation so that in the event of a sec-critical or sec-high we can avoid spinning builds, but ultimately we can still lean on RelEng to make an immediate point release of Fenix at any hour of the day or night. We just... shouldn't have to.

Flags: needinfo?(jjones)

@Snorp, Agi: This is probably more in your layer or below. I assume GeckoView should deal with that internally?

Flags: needinfo?(s.kaspari) → needinfo?(agi)

ni esawin in case he knows what's going on here.

Interestingly chrome doesn't block revoked.badssl.com either.

I see that we should have the onecrl.json file on mobile, trying to figure out why it's not working.

Flags: needinfo?(agi) → needinfo?(esawin)

Looks like this is a miss from Bug 1526018 which moved the initialization code from somewhere in security/ to browser and did not include the code in mobile too... patch incoming.

Regressions: 1526018
Flags: needinfo?(snorp)
Flags: needinfo?(esawin)
Regressed by: 1526018
No longer regressions: 1526018
Assignee: nobody → agi
Status: NEW → ASSIGNED
Severity: -- → S3
Priority: -- → P1
Whiteboard: [geckoview:m83]
Component: Security: Android → General
OS: Unspecified → Android
Product: Fenix → GeckoView
Version: unspecified → Trunk

(In reply to Agi Sferro | :agi | ⏰ PST | he/him from comment #8)

Interestingly chrome doesn't block revoked.badssl.com either.

Hmm, on which platform? Chrome desktop blocks it for me, as does Chrome on iOS.

(asking because I run badssl.com)

(In reply to April King [:April] from comment #11)

(In reply to Agi Sferro | :agi | ⏰ PST | he/him from comment #8)

Interestingly chrome doesn't block revoked.badssl.com either.

Hmm, on which platform? Chrome desktop blocks it for me, as does Chrome on iOS.

(asking because I run badssl.com)

On Android

Ahh, got'cha. Yeah, I think it's coming at some point, but currently Chrome (Android) doesn't make use of CRLSet/Blacklist as it relies on Android's path discovery and verification.

Group: mobile-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

In Fenix 84 https://revoked.badssl.com/ gets blocked but it loads in 83 but the central revision landed in 83. about:buildconfig says it should be included (tagged as devedition etc), might one of the dependencies have an older central revision hardcoded?

Flags: needinfo?(esawin)
Flags: needinfo?(esawin) → needinfo?(agi)

I think this is caused by the CRL list not being downloaded yet, could you try leaving the browser idle before testing? It works fine on my Fenix Beta (83).

Flags: needinfo?(agi) → needinfo?(aryx.bugmail)

Let Firefox 83.0b10 idle twice >20 minutes, terminated app, launched it again, https://revoked.badssl.com/ still doesn't get blocked.

Flags: needinfo?(aryx.bugmail)
Whiteboard: [geckoview:m83] → [geckoview:m83][adv-main83+]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.