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

101–110 of 157 posts

Re: No, don't enable revocation checking

#101

Post by tptacek »

einhverfr wrote: post #98
tptacek wrote: post #95

Earlier quoted context omitted.

Online revocation is pointless. It sounds like you didn't actually read the article, but are happy to slam the one team on the Internet that has given serious consideration to the obviously-broken SSL revocation system. Can I ask you to take a breath and reread the article?

> Online revocation is pointless. So is getting a subset of revoked certs Google deems "valuable." In fact, that may be even more dangerous since it establishes first class secure sites vs everyone else. Why should Yahoo's cert revocatins get in the CRLsets but not less well known sites? How is that less broken than online revocation? Keep in mind, my big objection is: Google did not distribute our certificate vocati…

This comment isn't responsive to mine.

Re: No, don't enable revocation checking

#102

Post by einhverfr »

tptacek wrote: post #101
einhverfr wrote: post #98

Earlier quoted context omitted.

> Online revocation is pointless. So is getting a subset of revoked certs Google deems "valuable." In fact, that may be even more dangerous since it establishes first class secure sites vs everyone else. Why should Yahoo's cert revocatins get in the CRLsets but not less well known sites? How is that less broken than online revocation? Keep in mind, my big objection is: Google did not distribute our certificate vocati…

This comment isn't responsive to mine.

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 ca.

Re: No, don't enable revocation checking

#103

Post by tptacek »

einhverfr wrote: post #102
tptacek wrote: post #101

Earlier quoted context omitted.

This comment isn't responsive to mine.

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.

Re: No, don't enable revocation checking

#104

Post by y0ghur7_xxx »

tptacek wrote: post #75
y0ghur7_xxx wrote: post #55

Earlier quoted context omitted.

> certificate pinning as implemented in Chrome doesn't depend directly on key continuity. But it's unsuitable for the entirety of the web. You can't hardcode all certificate fingerprints of the whole internet inside the browser. >> The migration away from the CA model is called "certificate pinning". > key continuity destroys the incentive to attack sites by compromising CAs We need to ELIMINATE CAs (CA as in some th…

That's true, you can't hardcode certificate fingerprints for every site. Hence, TACK.

Yes, but TACK, even if it's a big step forward, does not address the main problem: we need to get rid of a central authority we have to trust. And TACK does nothing to address that. And neither does Certificate Transparency as proposed by Google.

I really feel the correct step forward is Convergence or Perspectives. If just browser vendors would jump in, we could use it right away. Mozilla/Google could set up a few notaries and set them as trusted by default in the browser. They choose the CAs they put in our browsers anyway, so we trust them already. That trust could be implemented with notaries instead of the CA model, so if someone wants to setup their own notaries they can.

What's your take on this? I value your opinion on security matters.

Re: No, don't enable revocation checking

#105

Post by tptacek »

y0ghur7_xxx wrote: post #104
tptacek wrote: post #75

Earlier quoted context omitted.

That's true, you can't hardcode certificate fingerprints for every site. Hence, TACK.

Yes, but TACK, even if it's a big step forward, does not address the main problem: we need to get rid of a central authority we have to trust. And TACK does nothing to address that. And neither does Certificate Transparency as proposed by Google. I really feel the correct step forward is Convergence or Perspectives. If just browser vendors would jump in, we could use it right away. Mozilla/Google could set up a few n…

By moving towards decoupling the CAs from the Internet trust model, TACK is a step towards getting something like Convergence bootstrapped. Once we accept that the CAs are a utility player and not the ultimate arbiter of security, it's not hard to get to a place where we can start verifying "pins" with sites run by EFF or ACLU.

The biggest security problem on the Internet isn't protocols and it isn't cryptography. It's that the UX the browsers have for managing/configuring Internet trust hasn't changed since the late 1990s, and it's buried 3-4 levels deep in the "no user serviceable parts" section of the config UI. There are a lot of very productive things you could do for Internet security simply by revamping that UX, without making a single wire-level change to the TLS or HTTP protocols.

Re: No, don't enable revocation checking

#106

Post by enneff »

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.

Soft fail doesn't work at all. CRLset works for the certificates that it covers (some 25k of them, btw).

Which approach is worse?

Re: No, don't enable revocation checking

#107

Post by dvanduzer »

einhverfr wrote: post #96
dvanduzer wrote: post #93

Earlier quoted context omitted.

This sounds very much like the directory system I want to build on top of Telehash. The problem I still see is creating a global directory of Kerberos realms. There still needs to be a sneakernet component for private key distribution. (Maybe that would be a better use of the armored cars I see making regular stops at the banks around town.)

Ok, so suppose registering a domain also required registering a public key for the domain name. This would require a change for the root realm. Suppose we were to extend the DNS protocol so that when you do an NS lookup, you get the keys of the NS's as well (might require SRV records or the like in the root tree). You'd need a mechanism to revoke or rotate keys, but that could be done. From there it should be quite p…

What you're suggesting doesn't sound too far from DNSSEC as it is currently implemented to me (ignoring adoption rate). I'm questioning the need of an authoritative global naming system at all.

From a user's perspective, "my bank" and "your bank" might be the same thing, or they might be different. When I care about verifying the identity of these things, why not just go to the source? I can do key exchange every time I visit an ATM.

I can imagine using DNS with multiple contextual root namespaces, with the trust anchors being managed by more direct human relationships. This wasn't feasible when the systems were originally designed, but now we can put public keys in jewelry. Keychains on our literal keychain.

Re: No, don't enable revocation checking

#108

Post by nomailing »

tptacek wrote: post #103
einhverfr wrote: post #102

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.

hard revocation is not at all broken! The article is bullshit.

Re: No, don't enable revocation checking

#109

Post by tptacek »

nomailing wrote: post #108
tptacek wrote: post #103

Earlier quoted context omitted.

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.

hard revocation is not at all broken! The article is bullshit.

By all means, totally anonymous Hacker News one-line comment writer, tell us why Adam Langley is full of shit about certificate revocation.

Re: No, don't enable revocation checking

#110

Post by Splendor »

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 100% of the cases.

Post reply on HN