No, don't enable revocation checking • Hacker News Board

Re: No, don't enable revocation checking

#91

Post by dvanduzer » Sun, Apr 20, 2014, 4:09 PM UTC

wyager wrote: post #20

dvanduzer wrote: post #12

Earlier quoted context omitted.

There's been plenty of action, but you can't turn the whole world on a dime. Namecoin is fantastic in theory, but has the fatal flaw of using Bitcoin: the fastest number cruncher wins. Some would argue that the strength of Bitcoin's tech is that numerous currencies with different genesis blocks can flourish. That doesn't get us anywhere with naming, though. Dead horse flog: the CA model's problem is that you can't do…

>the fastest number cruncher wins. What's the issue with that? It's reasonable to assume that the good number crunchers will always have more power than the bad number crunchers, and if that assumption ever fails, it's easy to detect and we're simply back to CA levels of security.

Philosophically, "good number crunchers" just means "tyranny of the majority."

Environmentally, that number crunching is a colossal waste of energy. We don't need to base our entire economy on that kind of energy footprint just because we occasionally want to make anonymous global barter convenient.

Re: No, don't enable revocation checking

#92

Post by einhverfr » Sun, Apr 20, 2014, 4:11 PM UTC

lazyjones wrote: post #32

Khaine wrote: post #30

It sounds like the internet is broken Without CRL/OSCP we cannot truly trust that we are securely communicating. Something has to give. We need to abolish SSL/TLS and migrate to something that isn't broken by design

> the internet is broken It's not the Internet, just the CA system. There are better systems for handling trust out there, for example, people have been signing each other's PGP keys at key signing parties for decades.

> It's not the Internet, just the CA system.

Ok, so it is just the portion of the internet that involves purchasing things with credit cards and requiring passwords to access sites. The rest of the internet is just fine.

Great. I thought for a moment that the commercial basis of the internet might be in danger. Now to determine what percentage of the internet is not dependent on the CA system.....

Re: No, don't enable revocation checking

#93

Post by dvanduzer » Sun, Apr 20, 2014, 4:18 PM UTC

einhverfr wrote: post #88

jackalope wrote: post #77

Earlier quoted context omitted.

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…

I think the fundamental problem with DNSSEC is it doesn't go far enough. DNS really is the original directory service of the internet. If we could generalize it a bit, and allow TCP queries secured by Kerberos, with far better row-level security, there's no reason we couldn't replace LDAP with something a lot simpler. If we could replace LDAP with something a lot simpler, we could as replace X.509 with something a lo…

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

Re: No, don't enable revocation checking

#94

Post by tptacek » Sun, Apr 20, 2014, 4:18 PM UTC

einhverfr wrote: post #90

tptacek wrote: post #74

Earlier quoted context omitted.

I don't understand your comment. Google doesn't revoke keys. It revokes whole CAs.

Well, what Google does is it gets a list of revoked certs from CA's, decides which ones are "really important" and sends those to the browser. So yes, in effect, Google decides which certificates are revoked. It's all covered in the article.

No. You're not following me. You think I'm describing agl's point. I'm not. I'm saying that beyond CRLsets, certificate pins also allow Google to detect misbehaving CAs. CAs have power only to the extent that Google allows them to have power by keeping them in Chrome's root CA key store. Google can pick among most of the current CA's and put them out of business on a whim.

Re: No, don't enable revocation checking

#95

Post by tptacek » Sun, Apr 20, 2014, 4:26 PM UTC

einhverfr wrote: post #81

richardwhiuk wrote: post #71

Earlier quoted context omitted.

Revoking certificates is pointless - that's Adam's point here.

Well, if they were pointless Google wouldn't even hand you a subset of revoked certificates. The fact that they hand you a subset of revoked certificates from participating CA's makes their solution worse than the disease, frankly. It might be ok if used in addition to checking revocation lists. However why should a bank get to have their certificate in the crlset but a saas provider not? Or do you really trust Googl…

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?

Re: No, don't enable revocation checking

#96

Post by einhverfr » Sun, Apr 20, 2014, 4:26 PM UTC

dvanduzer wrote: post #93

einhverfr wrote: post #88

Earlier quoted context omitted.

I think the fundamental problem with DNSSEC is it doesn't go far enough. DNS really is the original directory service of the internet. If we could generalize it a bit, and allow TCP queries secured by Kerberos, with far better row-level security, there's no reason we couldn't replace LDAP with something a lot simpler. If we could replace LDAP with something a lot simpler, we could as replace X.509 with something a lo…

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 possible to tie public keys to hosts all the way down since you now have a chain of trust. Should be trivial, but the problem is that I don't see how to get the root zone to publish domain keys.

Yes, that replaces CA's with domain registrars, but that is a healthy trade. Since you would get keys (all allowed keys!) all the way down with your query, you wouldn't need to check revocation because you'd know the keys before making the connection.

Re: No, don't enable revocation checking

#97

Post by tptacek » Sun, Apr 20, 2014, 4:27 PM UTC

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.

Do you know the limits of "soft-fail"? Because I don't see you addressing them.

Re: No, don't enable revocation checking

#98

Post by einhverfr » Sun, Apr 20, 2014, 4:29 PM UTC

tptacek wrote: post #95

einhverfr wrote: post #81

Earlier quoted context omitted.

Well, if they were pointless Google wouldn't even hand you a subset of revoked certificates. The fact that they hand you a subset of revoked certificates from participating CA's makes their solution worse than the disease, frankly. It might be ok if used in addition to checking revocation lists. However why should a bank get to have their certificate in the crlset but a saas provider not? Or do you really trust Googl…

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 vocation in their CRLSet, presumably because we weren't large enough. That is not a fix for anything.

Re: No, don't enable revocation checking

#99

Post by vertex-four » Sun, Apr 20, 2014, 4:29 PM UTC

einhverfr wrote: post #83

vertex-four wrote: post #73

Earlier quoted context omitted.

You can know that you are talking to the same named digital identity that you think you are talking to without trust; that's a significant amount of the value of Namecoin. Validating that a digital identity is tied to a specific real world identity is a separate problem.

> Validating that a digital identity is tied to a specific real world identity is a separate problem. But it isn't for the main areas of SSL usage (e-commerce, ensuring your passwords are sent to the right party, etc). Those require trust. I don't know how you get around that. I.e. I can imagine the concern being that X.509 ties together validating identity with public key infrastructure but since one use of a public…

As a general rule, people care that their connection is secure, because they've been told to worry about people stealing their card numbers on insecure sites. They've generally established trust in other ways - more commonly, they simply trust it because they've heard about it elsewhere or it ranks highly on Google, and they use a trusted payment provider such as Paypal.

Most people honestly don't go to the effort of verifying that a certificate matches the real-world identity they think it does. It's difficult, especially with smaller stores that don't use EV certificates.

For cases where people think third-party attestation is a necessary thing for their purposes, frankly, we have nothing better than the CA model right now; but that can easily be integrated with Namecoin, allowing for only those who need it to use it, and the rest to have access to secure communications and proofs of digital identity without having to pay up.

Re: No, don't enable revocation checking

#100

Post by tptacek » Sun, Apr 20, 2014, 4:30 PM UTC

hereonbusiness wrote: post #65

So this complete infrastructure is crap. OpenSSL, a software half the internet uses but no one cares about because it's crap. CA's not revoking keys even though they know they're compromised. Revocation being worthless because it's too much of a hassle for anyone to bother. Great. Maybe now, when half the internet is already compromised and all our certificates are not worth the bytes they're made of ... maybe we sho…

Yes! Now it's time for us to generate a whole new broken infrastructure! I'm sure if we just rewrite all the Internet's crypto in Rust, everything will be great 10 years from now. No way will a radically different new transport cryptosystem grant researchers 100 new bugs to play with; after all, we'll have option types.