Live data from Hacker News

No, don't enable revocation checking

imperialviolet.org

121–130 of 157 posts

Re: No, don't enable revocation checking

#121
post #67

Earlier quoted context omitted.

I'm sure it doesn't. I just checked Options -> Advanced -> Certificates -> Revocation, and it's not checked by default.

And I'm sure you are wrong. I only see a Validation option(not Revocation), which has 2 more options on how to check OCSP, and those are both checked using the defaults. The correct path on my OS is Edit -> Preferences -> Advanced -> Certificates -> Validation -> OCSP options(both checked)

I think you've altered your settings at some point. It's not the default.

You would see a huge influx of bugzilla entries of "Firefox is broken" if hard fail was the default.

edit: the checkbox in the validation subdialog (ocsp.xul) is tied to security.OCSP.require, which is set here with a default of false in the Firefox source: http://dxr.mozilla.org/mozilla-central/source/netwerk/base/p...

Re: No, don't enable revocation checking

#122
post #67

Earlier quoted context omitted.

I'm sure it doesn't. I just checked Options -> Advanced -> Certificates -> Revocation, and it's not checked by default.

And I'm sure you are wrong. I only see a Validation option(not Revocation), which has 2 more options on how to check OCSP, and those are both checked using the defaults. The correct path on my OS is Edit -> Preferences -> Advanced -> Certificates -> Validation -> OCSP options(both checked)

I just checked, and the checkbox for enabling hard-fail is unchecked with my default Firefox settings.

Re: No, don't enable revocation checking

#123
post #113

Let me get this straight. Sites across the internet are (hopefully) revoking their CAs and issuing new ones to address Heartbleed but Mr. Langley is suggesting that we shouldn't check for revoked CAs because it might not do anything and it's slow? Sorry, but after the last few weeks I'll happily accept a little slowness for the security revocation checking provides in the cases where it does work, even if it's not 10…

I guess you didn't read the article? He's saying there are no cases where it works. Making it completely pointless.

I did read the article.

> "In order to end on a positive note, I'll mention a case where online revocation checking does work..."

Re: No, don't enable revocation checking

#124
post #68
post #7

Still seeing lots of explanation about why the current system sucks, and not much about how a more robust system might be created and promptly adopted. Langley (the author) mentions short-lived certificates (either rapid expiration or via a 'must staple')... how soon can we enforce that? How short can that make the danger-period where the CA, and Google, and the "connected web" all know that a certificate is invalid,…

how a more robust system might be created and promptly adopted I'm quite fond of how the SSH host key system works. Prompt me the first time I see a new key, provide me with supporting evidence (e.g. show me how many people have previously accepted this fingerprint for this domain) and alert me the same way in the future if the key ever changes. If the 'supporting evidence' was plugin-based then this system could qui…

All interesting ideas... but don't directly address rapid trust revocation, as in the case of recent relevance: a site's private keys are assumed to have been compromised (as if by the heartbleed bug).

Or are you suggesting every browser will contact many of its personal web-of-trust sources on every secure-connection? Without additional innovation, that seems just as prone to the performance bottlenecks or soft-failure (on stale data or blocked connections) as the current system.

Re: No, don't enable revocation checking

#125

Earlier quoted context omitted.

Ok, fair enough. I am just making sure my objection to Google's approach is clear. I would be OK if they guaranteed complete CRLsets from all participating CA's. Since they don't, their solution is more broken than what they are replacing. So I acknowledge that online revocation is problematic. I just think the crlset approach is an order of magnitude worse when the crlset is a subset of revoked entries sent by the c…

Respectfully, I think an accurate summary of your argument is that you would rather pretend to be secure using broken online revocation checks than to have to stomach the Chromium team providing a marginal amount of actual security by deciding which sites are and aren't worthy of protection.

The implied-preference-set shouldn't be restricted to the false binary choice of "the broken standardized system" and "Google's half-fixed proprietary approach".

With the talent & resources that Google has, or the talent & resources that Mozilla has, or the talent & resources that Microsoft has, this should have been better solved, in a way that works for all TLS-reliant applications, years ago.

Using Chrome's built-in auto-updates to make a subset of "high-value revocations" work, at a daily frequency, for Chrome users only, is not a very web-friendly solution.

It's like a gated community hiring its own rent-a-cops... maybe that's an improvement for the fortunate ones on the inside, and maybe a necessary stopgap. But to people outside that perimeter – like someone whose revocation doesn't make it into the Google CRLSet – it feels like an abdication of duty by the web's stewards.

Re: No, don't enable revocation checking

#126
post #113

Earlier quoted context omitted.

I guess you didn't read the article? He's saying there are no cases where it works. Making it completely pointless.

I did read the article. > "In order to end on a positive note, I'll mention a case where online revocation checking does work..."

That's even more proof you didn't read it. How does enabling it in chrome make any difference to code signing?

Re: No, don't enable revocation checking

#127
post #113

Earlier quoted context omitted.

I guess you didn't read the article? He's saying there are no cases where it works. Making it completely pointless.

I did read the article. > "In order to end on a positive note, I'll mention a case where online revocation checking does work..."

Funny how you didn't quote the actual case mentioned, just the text ahead of it. Ctrl-F'ing a little quick, eh?

Re: No, don't enable revocation checking

#128
post #70

Earlier quoted context omitted.

No, not really. DNSSEC secures DNS, allowing it to be used (among other things) as a secure transport for delivering other certificates. CAs already provide the same trust infrastructure, but due to incentives do not sign delegating certs by default, but typically charge extra for certs that allow the owner of a domain to set up their own internal CA. DNSSEC only works (reasonably) for TLDs where DNSSEC is implemente…

From the article: Certificates bind a public key and an identity (commonly a DNS name) together. ...when issuing certificates a CA validates ownership of a domain by sending an email, or looking for a specially formed page on the site. So, if " DNSSEC secures DNS, " as you say, why do we need certificates at all? Considering that the CA already depends on DNS to issue (many) certificates, why not cut out the middle m…

>> Certificates bind a public key and an identity (commonly a DNS name) together.

>

> So, if "DNSSEC secures DNS," as you say, why do we need certificates at all?

Yes and no. Note that a cert binds an identity, not just a DNS name (but that is what is needed for web servers).

DNSSEC doesn't work without resolvers checking for the DNS keys, and it's not immediately clear (to me at least) if the various higher level clients can transparently detect if a DNS name is secure or not (similar to how a web browser can't tell if it's accessing a resource over a secure IP based VPN and can therefore safely transmit credentials via plain auth).

For trust to work, there needs to be integration of the chain of trust all the way from the user to the server. TLS/SSL already provides this -- and with delegation the infrastructure is in place for owners to manage trust for their own domain (and it is already possible, but typically expensive).

In it's barest form DNSSEC only makes DNS secure, which prevents DNS spoofing. If you also place a cert (could be self-signed) in DNS, then you have a "full" solution to securing communications. You would be able to download the cert without DNSSEC, but unless the chain of trust of the cert could be verified some other way, you wouldn't be able to use that cert for secure communications.

It is true that current CAs bind a cert to a domain name, but it's not really the domain name part that is interesting, it's the entity identifed by that name. So your browser can say, I don't care where this authenticated (and encrypted) data stream is comming from, I just care that it is backed by example.com (that is backed by example-ca.com) -- and if the user thinks that Example corp. owns the example.com domain, one can then infer that the browser is really talking to a web site set up by Example corp -- regardless of which IPs and DNS records are involved.

Keep in mind that the same CA infrastructure allows a user to indenify to a server as user@example.org -- from any ip or doman name -- just as securely, via mutal trust in "Example CA". I think it's somewhat unfortunate that DNS is so tightly integrated into the user interfaces for the web -- asserting things about IP adresses and DNS names isn't really all that interesting -- it's asserting things about entities that is interesting.

While I'm no fan of the current CA system, I'm not convinced DNSSEC is securing the right things at the right protocol level(s).

Re: No, don't enable revocation checking

#129
post #126

Earlier quoted context omitted.

I did read the article. > "In order to end on a positive note, I'll mention a case where online revocation checking does work..."

That's even more proof you didn't read it. How does enabling it in chrome make any difference to code signing?

Does enabling revocation checking make me less safe?

Re: No, don't enable revocation checking

#130
post #126

Earlier quoted context omitted.

That's even more proof you didn't read it. How does enabling it in chrome make any difference to code signing?

Does enabling revocation checking make me less safe?

Yes! It involves you reporting all the sites you visit to a CA!
Post reply on HN