CRLSet component to check revoke status of certificates

[brokoler]

Description

CRLSet component to check revoke status of certificates

Who's implementing?

• [ ] I'm willing to implement this feature myself

The problem

CRLSet is excluded from Ungoogled Chromium, since it contacts Google Servers.

Still this feature is important for security to check the status of website and CA certificates. With the component removed MITM attacks are possible and could happen at all, since the browser never is informed of a certificate revocation.

Possible solutions

Multiple solutions would be possible:

• Add the component per default and add a configutation toggle to browser settings to enable/disable (default setting: disable)
• Don't add it at all and inform the user how it can be installed by the user (Question: Would it be enough to move the CRLSet component of a Chrome installation to the UserData folder, similar to installing Widevine?)

Alternatives

No response

Additional context

No response

[PF4Public]

With the component removed MITM attacks are possible and could happen at all

Is it more harmful than not having EV certificates and a green padlock? "possible" and "can happen" are not the best terms for describing security concerns. What are the real security issues that do exist? CLR issue does happen after a server operator knows that the key is compromised and took action in this regard. MITM attack "is possible and can happen" even without server administrator noticing anything.

[github-actions[bot]]

This issue has been automatically marked as stale as there has been no recent activity in response to our request for more information. Please respond so that we can proceed with this issue.

[github-actions[bot]]

This issue has been automatically closed as sufficient information hasn't been provided on the issue for further actions to be taken. Feel free to add more information.

[rany2]

@PF4Public This actually seems important, Chromium doesn't fallback to CRL and OCSP doesn't work well (or at all) for most CAs.

Firefox already has OneCRL so it's actually a common practice for most browsers these days to centralize all the CRLs. I assume this is done for performance.

Basically right now, the primary way certificates are revoked by CAs just doesn't work.

[PF4Public]

@Ahrotahn @networkException @Eloston @teeminus @Nifury Does this issue deserve to be reopened and reconsidered?

[networkException]

as an optional feature sure, no hard opinion

[teeminus]

as an optional feature sure, no hard opinion

Same

[Nifury]

as an optional feature sure, no hard opinion

Sure, but one could also argue that other security features, such as the built-in virus scan or even auto-update (fixing critical vulnerabilities), are necessary using the very same reason.

I'm leaning toward getting a Chrome extension to check for revocation, but I can't find any :(

[rany2]

as an optional feature sure, no hard opinion

How so? This makes it so that CAs can't revoke bad certificates. There is no OCSP/CRL fallback, it's completely broken.

[Ahrotahn]

I think it's fine to reopen this issue, but I don't know if there is an easy solution. We'd have to carve out an exception in the domain substitution for the component updater and get that working somehow. As an alternative, maybe it's possible to hook into the CRLSet updater to look in a specified location so end users could use something like crlset-tools to manually download updates.

[rany2]

Alternatively we can see if we could have OCSP/CRL working properly, this wouldn't be an issue if that was working properly.