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

81–90 of 157 posts

Re: No, don't enable revocation checking

#81

Post by einhverfr »

richardwhiuk wrote: post #71
einhverfr wrote: post #61

Earlier quoted context omitted.

On the other hand we found that as of Friday, Chrome DID NOT recognize that one of our wildcard certs for Efficito had been revoked. We sent out an email to our customers saying to enable cert revocation checking. Revovation isn't perfect and I would not suggest the current status quo is OK but the intermediary approach Chrome takes cannot be trusted as they have now shown. If Chome will not show our cert as revoked…

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 Google there?

Frankly Adam doesn't really believe revocation is pointless. If he did, he wouldn't even suggest that sending a valuable subset of certificates to the browser in a batch is any sort of solution at all. All that does, though, is create a two-class secure internet: those entities Google deems worth distributing revocation information for and those not. That isn't a solution to anything.

Re: No, don't enable revocation checking

#82

Post by tptacek »

wpietri wrote: post #79
tptacek wrote: post #31

Earlier quoted context omitted.

He's also the author of Golang's native crypto/tls TLS stack, a longtime contributor to the IETF TLS WG, and the author of some of OpenSSL's curve software. He's not messing around.

Let's hope he reads this and discovers the value of an "About me" sidebar on his blog.

I think he's well known enough that he can count on comments from sycophants like me to clear that up.

Re: No, don't enable revocation checking

#83

Post by einhverfr »

vertex-four wrote: post #73
einhverfr wrote: post #62

Earlier quoted context omitted.

Trustless is great for so many things but try answering this question in a trustless environment: "Before I give you my credit card info, how do I know you are who you say you are?" If you can answer that without trust. .

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 key is to validate identity I am not convinced that is a bad thing, and to be honest, I can't see a trustless alternative for most of the current uses.

I can imagine many better alternatives to X.509 (anything that starts with a letter . three digit number is OSI legacy crap), but I don't see how to get rid of the identity vouching aspect of it.

Re: No, don't enable revocation checking

#84

Post by dvanduzer »

sarahj wrote: post #28
dvanduzer wrote: post #24

Earlier quoted context omitted.

Just to be clear, Telehash is a protocol, not an application. The bulk of the documentation is on Github, and so far it's mostly for people implementing the protocol in different languages. There's no blockchain involved in Telehash. It accomodates various cipher sets, including one suitable for ultra low power devices (there's a partially working implementation for Arduino). And you're correct, it isn't really aimed…

I was mixing a number of different criticisms of various technologies in my post...I never meant to confer that Telehash has a blockchain. I guess, I still don't understand the point of Telehash. Even having read through the documentation. "Establishing private communication channels" is definitely a big problem, one with a huge threat model, and the solution is probably multi-faceted - I don't see where a system lik…

Hope to hear from you. :)

Telehash's design may simplify the future design of Tor-like protocols, but anonymity is not an intended core feature.

Partition resistance is probably the highest priority. If any possible insecure network path exists, encrypted communication between endpoints should also be possible (and automatic).

Re: No, don't enable revocation checking

#85

Post by pronoiac »

pjscott wrote: post #42
pronoiac wrote: post #23

Could we use bloom filters on the CRLs, before checking with OCSP? Maybe I should go crunch the numbers on the viability of that.

Adam Langley has some thoughts about how to do this, and some numbers, here: https://www.imperialviolet.org/2011/04/29/filters.html

Wow! That was an informative read. Thanks!

Re: No, don't enable revocation checking

#86

Post by einhverfr »

moe wrote: post #68
gojomo wrote: 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…

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

Re: No, don't enable revocation checking

#87

Post by pronoiac »

MertsA wrote: post #35
pronoiac wrote: post #23

Could we use bloom filters on the CRLs, before checking with OCSP? Maybe I should go crunch the numbers on the viability of that.

I just did and if you were okay with a 0.001 probability of false positive you could list all 500,000 (possibly way off) certificates potentially exposed through heartbleed in only 877.5KB of space. The current Chrome CRL contains 24,161 serial numbers and takes up 305.3KB of space. While it isn't a perfect fix for the revocation problem it would certainly be much better than the status quo. One problem might be that…

You might check pjscott's comment, sibling to the parent comment. There's a lot more to it, but a bloom filter's already been considered for this.

Re: No, don't enable revocation checking

#88

Post by einhverfr »

jackalope wrote: post #77
e12e wrote: 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…

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 lot simpler (LDAP is a mildly simplified version of X.500, of which X.509 is a very closely related OSI legacy standard).

So DNSSEC doesn't go far enough. IMO, we should be working on ensuring that it can be extended to allow for certification of hosts, etc. However, at present it doesn't do this very well.

Re: No, don't enable revocation checking

#89

Post by einhverfr »

sarahj wrote: post #13
wyager wrote: post #4

I'm honestly kind of surprised how little action there has been to assist with a migration away from the CA model. The technology is there, but people just don't seem interested enough to leverage it. Systems like Namecoin could serve this purpose marvelously. Powerful devices have direct access to the entire cryptographically authenticated DNS and certificate database. Weak devices can specify whom they trust to pro…

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…

I think we should rebuild a PKI on top of DNS also. It shouldn't be that hard to do honestly and it would avoid a lot of this sort of problem.

Re: No, don't enable revocation checking

#90

Post by einhverfr »

tptacek wrote: post #74
wyager wrote: post #37

Earlier quoted context omitted.

>First, "TOFU/POP" has a real name; it's "key continuity". I am aware of both names, thank you. >That only has to happen once for Google to put a gun to the rogue CA's temple. Google can't really help in every single case. There are many situations where Google's revocation scheme can't keep up. You also have to put a lot of trust in Google. You think Google is going to issue a revocation if they're under legal press…

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.
Post reply on HN