Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OT: OCSP and CRL #1063

Closed
crssi opened this issue Nov 14, 2020 · 4 comments
Closed

OT: OCSP and CRL #1063

crssi opened this issue Nov 14, 2020 · 4 comments

Comments

@crssi
Copy link

crssi commented Nov 14, 2020

@Thorin-Oakenpants and @earthlng

Hey guys. This is OT, but I value your opinion mountain high.

Could you be so kind and comment this topic here: https://github.com/nextdns/metadata/issues/470

Thank you and cheers

@Thorin-Oakenpants
Copy link
Contributor

Thorin-Oakenpants commented Nov 15, 2020

I'm not sure what you want me to do?

https://scotthelme.co.uk/revocation-checking-is-pointless/ ... "the purposes of this blog post is to demonstrate that revocation checking really is pointless as it currently stands" .. "One of the biggest problems with existing revocation mechanisms is their soft-fail nature" (emphasis in both = mine) ... and then he shows just that, by blocking at a network level via PiHole

We don't soft-fail

user_pref("security.OCSP.require", true);

FYI: Jan 2020 : https://blog.mozilla.org/security/2020/01/21/crlite-part-3-speeding-up-secure-browsing/ - pretty sure FF is using this by default by now

reducing the need to actively query such information one by one. Additionally this new technology eliminates the privacy leak that individual queries can bring


https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol#Comparison_to_CRLs

  • OCSP discloses to the responder that a particular network host used a particular certificate at a particular time. OCSP does not mandate encryption, so other parties may intercept this information

As stated in 1211, "It's a trade-off between security (checking) and privacy (leaking info to the CA)". And it looks as if that thread is suggesting to disable all checking

The question you should be asking is if Firefox uses secure connections with CAs. IDK the answer, but I would assume that browsers use as much encryption as possible. At the end of the day, either turn the thing off and compromise security (the risk might be super low, but it is a risk), or use what is currently available in the best config you have

@crssi
Copy link
Author

crssi commented Nov 15, 2020

Thank you @Thorin-Oakenpants, not only for this commenting but overall.

❤️ U
Cheers 😃

p.s. Close issue it at your will.

@Mikaela
Copy link

Mikaela commented Nov 15, 2020

The question you should be asking is if Firefox uses secure connections with CAs. IDK the answer, but I would assume that browsers use as much encryption as possible.

At least with LetsEncrypt and Google, Firefox uses port 80 with HTTP <= 1.1 even in HTTPS-only mode judging by about:networking#http. I have been looking there trying HTTP/3 and having OCSP checking enabled with hard-failing.

In my opinion a better option than blocking OCSP (and thus decreasing security and risking giving credentials to revoked certificate compromising privacy) would be having a browser extension or similar to tell whether website is using OCSP stapling or not and then asking the administrators if they could enable the OCSP stapling. While it wouldn't resolve the issue entirely, it would decrease connections made to the CA.

I am coming from following nextdns/metadata#470 where my comment may be more relevant, but I think it would be too weird to reply to a question here there.

@earthlng
Copy link
Contributor

fyi: #1065

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants