Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No, don't enable revocation checking

imperialviolet.org

Post reply on HN
Print view View original

111–120 of 157 posts

Re: No, don't enable revocation checking

#111

Post by psykovsky »

sp332 wrote: post #67
psykovsky wrote: post #56

Earlier quoted context omitted.

That is simply not true. Firefox does hard-fail with the default settings.

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)

Re: No, don't enable revocation checking

#112

Post by moe »

einhverfr wrote: post #86
moe wrote: post #68

Earlier quoted context omitted.

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…

Supporting evidence, to be worthwhile, must come from a trusted source, right?

As said it should be pluggable. Yes you will still need seed fingerprints for a few independent plugins (like the CA list of today), and you still need to trust or vet the browser itself (also like today).

The point is that once this seed trust has been established, which ideally would need to happen only once in your lifetime (given proper sync/backup facilities), you gain actual control over who you want to delegate your trust to, if at all. On a site-per-site basis.

If an american, a chinese and an EU database independently agree on a fingerprint for a site then that would be an actual trust indicator. Very much unlike the perpetually compromised zoo of certificate authorities of today.

And obviously once there's a market for plugins you'd quickly see plugins going far beyond what we get to know today (read: essentially nothing). There could be subscription-based plugins providing detailed information about the remote party, down to credit ratings, company history, you name it.

Re: No, don't enable revocation checking

#113

Post by ars »

Splendor wrote: post #110

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.

Re: No, don't enable revocation checking

#114

Post by millerc »

ars wrote: post #113
Splendor wrote: post #110

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.

> That's why I claim that online revocation checking is useless - because it doesn't stop attacks.

Doesn't mean there are "no" cases where it works. It just means any attacker dedicated enough can work around the CRLs.

I don't see any reason why one should throw the baby with the water. In this case, I just see Chrome guilty of FUD and hiding behind an intractable problem to justify their incorrect position.

See http://en.wikipedia.org/wiki/Two_Generals'_Problem if you want to convince yourself the problem is intractable.

Re: No, don't enable revocation checking

#115

Post by takeda »

Splendor wrote: post #110

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…

Well, his argument is also that the attacker can easily circumvent it, which is true, but it is still makes it slightly harder to do, because the attacker needs to remember it.

Re: No, don't enable revocation checking

#116

Post by fragmede »

The article gives two reasons for why 'soft-fail' is required: Captive-portals, and OCSP server failure.

To deal with captive portals: have an SSL signed 'subdomain.google.com/you_are_on_the_internet' site/page that Google Chrome can use to check to see if it's captive or not. If it's captive, enable soft-fail. If internet access is available, set to hard-fail.

Websites these days are complex, with many (digital) moving parts - the database server(s), the static image server(s), dynamic response server(s), gateway server, probably a memcache server or something similar. If any one of those goes down, the site is unusable. Why then, should the OCSP server going down be considered any differently? Is a black-hat rented bot-net running a DDoS going to care if it's the main gateway server or the OCSP server?

But let's say we do consider disabled OCSP servers to be a client-side issue. Google could query and cache the OCSP server status, either with OCSP stapling or via some side-channel they build into Google Chrome.

The combination of both would allow hard-fail to be an option in Google Chrome.

Re: No, don't enable revocation checking

#117

Post by lnanek2 »

dvanduzer wrote: post #9

I'm having a lot of trouble getting past: "Certificates bind a public key and an identity (commonly a DNS name) together." X.509 certificates bind a public key and a human recognizable string (a "common name") together to create a verifiable digital identity. Over-simplified, X.509 is about solving the "I'm Spartacus" problem. CRLs solve the "He was Spartacus" problem. I agree with the broad conclusion that CRLs aren…

For HTTPS to a web site, the common name is the site domain name. We're not talking about anything else here.

Re: No, don't enable revocation checking

#118

Post by mpyne »

takeda wrote: post #115
Splendor wrote: post #110

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…

Well, his argument is also that the attacker can easily circumvent it, which is true, but it is still makes it slightly harder to do, because the attacker needs to remember it.

Well, this is what "security theater" is. If you said that exact thing in the context of a TSA screening program there would be no one here going "yes, that makes perfect sense", and it's even easier for network attackers; they have to fix their attack scripts once and they work for good until the next countermeasure.

Re: No, don't enable revocation checking

#119

Post by mpyne »

einhverfr wrote: post #80
chmars wrote: post #63

Earlier quoted context omitted.

Honestly, I don't see a point in certificate revocations anymore, i.e., your implicit conclusion seems to be correct. And I don't blame Google for our broken revocation system – especially because the even the best revocation system couldn't fix the current certification system that is broken in its core.

Google's problem is they decide which revocations are worth passing on to the browser. That's at least as broken by design..... Believe me I am aware of the limits of soft-fail, but the answer cannot be even in the short-run to let a browser vendor tell us which revocations are worth knowing about.

> but the answer cannot be even in the short-run to let a browser vendor tell us which revocations are worth knowing about.

So you trust the browser vendor to ship you executable native code but you don't trust the browser vendor to apply reasonably decent criteria for the top x% most-needed cert revocations on the Internet?

Re: No, don't enable revocation checking

#120

Post by edwintorok »

dvanduzer wrote: post #14
sarahj wrote: post #13

Earlier quoted context omitted.

Why have a single entity at all? Moxie Marlinspike proposed Convergence ( https://www.youtube.com/watch?v=Z7Wl2FW2TcA ) as a solution - I think that something like that has far more potential wheels to travel than a Namecoin based system. I should be able to choose who I trust, a notary system would allow me to do just that. No central CA systems. The biggest concern I can see is Identity management, but, as mentione…

Want to help us work on this problem at http://telehash.org ?

How does this compare to the following which I've seen mentioned lately:

* sayI [http://www.ethos-os.org/~solworth/sayIgroups-20130614.pdf]

* MinimaLT: http://eprint.iacr.org/2013/310.pdf

* CurveCP: http://curvecp.org/

Post reply on HN