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

31–40 of 157 posts

Re: No, don't enable revocation checking

#31

Post by tptacek »

wpietri wrote: post #2

For those, like me, wondering who the author might be, it appears to be this guy: "Adam Langley works on both Google’s HTTPS serving infrastructure and Google Chrome’s network stack. From the point of view of a browser, Langley has seen many HTTPS sites getting it dreadfully wrong and, from the point of view of a server, he’s part of what is probably the largest HTTPS serving system in the world - See more at: http:/…

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.

Re: No, don't enable revocation checking

#32

Post by lazyjones »

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.

Re: No, don't enable revocation checking

#33

Post by tptacek »

dvanduzer wrote: post #11
e12e wrote: post #8

I think the author is a little disingenuous with the term "security theatre". Basically he argues that OCSP doesn't work because hard fail might cause DOS -- but fails to conclude that without OCSP SSL/TLS is useless . It's a long argument for saying that the CA system is broken (you can only trust the white-list chrome provides) -- and the sensible conclusion is that you cannot trust any other certificate chains (wi…

The "better use of CAs" you describe is essentially DNSSEC.

Sure, if "making the DNS totally unreliable", "baking 1990s crypto into the core of the Internet", and "conceding the CA PKI to world governments" is your idea of "better use of CAs".

Re: No, don't enable revocation checking

#34

Post by tptacek »

wyager wrote: post #18
jrockway wrote: post #16

Earlier quoted context omitted.

The migration away from the CA model is called "certificate pinning". Chrome uses it for high-value sites, and you use it whenever you ssh somewhere and the key's fingerprint is in your .ssh/known_hosts file.

>The migration away from the CA model is called "certificate pinning". TOFU/POP is not an effective model for the web. There are simply too many sites for it to be useful. It's pretty much an everyday occurrence that I go to a site I've never been to before, and certificate pinning won't help at all there.

First, "TOFU/POP" has a real name; it's "key continuity". Second, certificate pinning as implemented in Chrome doesn't depend directly on key continuity. Third, key continuity destroys the incentive to attack sites by compromising CAs, because even if you're hitting a site for the first time, many of the 10,000 other people hitting it from the same browser at around the same time aren't, and they'll detect the bogus cert. That only has to happen once for Google to put a gun to the rogue CA's temple.

Re: No, don't enable revocation checking

#35

Post by MertsA »

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 the 0.1% of sites hit by the false positive effectively couldn't use OCSP stapling but Chrome could just first call back to Google as a CRL proxy to avoid making an OCSP request when the site stapled a valid but potentially revoked OCSP response. Then just store that response from Google for current version of CRL in the cache. End result is that the unlucky false positive sites don't have tons of unnecessary (unnecessary as far as the OCSP spec is concerned) OCSP requests going to the CAs and the only thing they would notice is that a new visitior takes 100ms longer to make the first page load.

And through the magic of bloom filters if you wanted to bump the false positive rate down to 1 in 10,000 it only bloats the list to 1.14MB. Furthermore, there are methods to make the bloom filter scale-able such that a client doesn't have to necessarily download the whole bloom filter again if a bunch of elements are added to it and instead just download a portion of the data required for a full update.

The more I think about it the more I wonder why this isn't already in Chrome in some form or another. The only downside is weird networks where OCSP might be filtered, but not https, and access to Google is filtered.

Edit: One thing I feel stupid for overlooking is that Bloom filters aren't cryptographically secure so an attacker could theoretically find a serial number for some CA that would cause a site to always be a false positive but I don't think any CAs are still giving out serial numbers in a predictable way after the MD5 debacle and even if they were it would seem to be impractical to me. The fix would just be do a SHA256 hash of the serial instead of the serial itself.

Re: No, don't enable revocation checking

#36

Post by vxNsr »

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…

The project seems to have lost support, the last github commit was over 2 years ago.

Do you know if there was a specific reason or were people just not interested/none of the browsers jumped onboard?

Re: No, don't enable revocation checking

#37

Post by wyager »

tptacek wrote: post #34
wyager wrote: post #18

Earlier quoted context omitted.

>The migration away from the CA model is called "certificate pinning". TOFU/POP is not an effective model for the web. There are simply too many sites for it to be useful. It's pretty much an everyday occurrence that I go to a site I've never been to before, and certificate pinning won't help at all there.

First, "TOFU/POP" has a real name; it's "key continuity". Second, certificate pinning as implemented in Chrome doesn't depend directly on key continuity. Third, key continuity destroys the incentive to attack sites by compromising CAs, because even if you're hitting a site for the first time, many of the 10,000 other people hitting it from the same browser at around the same time aren't, and they'll detect the bogus…

>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 pressure not to?

As you are aware, human factors are frequently the weakest parts in a cryptosystem.

Re: No, don't enable revocation checking

#38

Post by sarahj »

vxNsr wrote: post #36
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…

The project seems to have lost support, the last github commit was over 2 years ago. Do you know if there was a specific reason or were people just not interested/none of the browsers jumped onboard?

Most of the energy in this space has gone into http://tack.io/ which has been called "a non-controversial first step" - I believe it is making its way though standards talks at the moment although I have not looked into it for a while.

Personally I think now is good time to revisit assumptions made a few years ago - security and privacy and in particular non-government controlled systems are on many peoples lips.

If I ever clear my current plate, I would be interested in diving into the problem.

Re: No, don't enable revocation checking

#39

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…

Oh, I wasn't thinking about having this be a perfect oracle; just a better and smaller first pass (edit:) for CRL, not for OCSP.

I got the idea from Squid and the network of caches.[1] That body of experience may be helpful.

For shrinking the size, RLE might work (most entries would be 0), and rsync may reduce bandwidth. It looks like the Squid network just used http requests for refreshes. There's probably a sweet spot for bandwidth, and I'd guess that 90-99% would work fine; you're balancing the size of the continually updated bloom filter vs. the requests for certificates that match it. I didn't worry about false positives, because it could just send an OCSP query in that case.

Your numbers for revocations sounded very low, but I just used crlset-tools[2] and checked, and it's about right. Which is weird, because someone else[3] mentioned a size of "4.107Kb" at version 1567, but that's somehow different - compression, perhaps. I thought I'd heard about CRLs megabytes long, but Google Chrome seems heavily curated re: CRLs.

I'd hash over signatures instead of the oft-predictable serial numbers, as you noted.

[1] http://wiki.squid-cache.org/SquidFaq/CacheDigests

[2] https://github.com/agl/crlset-tools

[3] https://scotthelme.co.uk/certificate-revocation-google-chrom...

Post reply on HN