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

141–150 of 157 posts

Re: No, don't enable revocation checking

#141

Post by gojomo »

tptacek wrote: post #134
einhverfr wrote: post #133

Earlier quoted context omitted.

If Amazon, Yahoo, and the small SaaS provider are in the same boat security-wise, then you have the incentive to get the root problems fixed. Google's approach takes away that incentive from the large providers. I don't think it is just a question of pretending. It is a question of making sure that everyone is in the same boat security-wise so that the root problems in fact get addressed. What Google does is make Ama…

The Chromium team didn't choose how big to make the lifeboat. They have the one they have. If they've got to choose between putting Amazon in it or you, then, as a user, I'm glad they chose rationally.

It looks to me like the Chromium team did choose the size of the lifeboat: it's a Google-designed feature (CRLSet) based on another Google-designed feature (auto updates).

Re: No, don't enable revocation checking

#142

Post by gojomo »

enneff wrote: post #137
gojomo wrote: post #125

Earlier quoted context omitted.

The implied-preference-set shouldn't be restricted to the false binary choice of "the broken standardized system" and "Google's half-fixed proprietary approach". With the talent & resources that Google has, or the talent & resources that Mozilla has, or the talent & resources that Microsoft has, this should have been better solved, in a way that works for all TLS-reliant applications, years ago. Using Chrome's built-…

Christ, this kind of reactionary armchair criticism really is a cancer of HN these days. Adam has been pushing the state of the art in cryptography in the practical realm for years, and your criticism is "They should have just solved this problem better! They should just pull their finger out and get working on it." Making a real difference in the chaotic realm of standards bodies and browser vendors is a lot harder…

The criticism isn't specifically for Langley, but rather for all of Google-Mozilla-Microsoft. They've all been derelict on this, knowing the certificate-revocation standards are hopelessly broken, but not fixing it from their positions of power and responsibility.

(Might it take a product-liability lawsuit, where somebody suffers financial loss because Chrome is deceptively showing the "secure" indicator even for certificates revoked days/weeks/longer ago?)

Consider the CRLSet approach. Maybe it's the best any browser-maker has done, and a useful learning-exercise for a future industry-wide fix. But it still sucks. It's capped at 250KB, assembled via an opaque editorial process, only refreshed daily, only protective of Chrome users and some chosen subset of "high priority" certificate-revocations, and still vulnerable to an arbitrarily-long attacker embargo against the Chrome update servers. Langley himself mentions it can't scale to the recent need for higher-volume revocations.

Compare it with Google's own "Safe Browsing" blacklist system. That delivers megabytes of compressed privacy-protecting blacklists, constantly refreshed via incremental updates to maintain a freshness of under 45 minutes, in a manner available to all browser makers.

So a potential version 1 of a better approach: leverage Safe Browsing to deliver fresher certificate blacklists to more end-users, and also warn users (not just silent-fail) if they're making 'secure' connections but are too-many-hours behind the best available revocation information.

I sketched a few other possible next-directions in a prior comment, https://news.ycombinator.com/item?id=7584458

However, the implication that I, as a lone individual, must "roll up my sleeves to get the actual work done" for my words to have weight here is both nonsensical and (speaking of rhetorical cancers on HN) unnecessarily personal. Google, with plentiful expertise and cash, is shipping the world's most popular browser – but that browser has multiple inadequate certificate-revocation systems. Yet I should be contributing my expertise to fix this before I may speak? "Christ", that.

Re: No, don't enable revocation checking

#143

Post by tptacek »

gojomo wrote: post #141
tptacek wrote: post #134

Earlier quoted context omitted.

The Chromium team didn't choose how big to make the lifeboat. They have the one they have. If they've got to choose between putting Amazon in it or you, then, as a user, I'm glad they chose rationally.

It looks to me like the Chromium team did choose the size of the lifeboat: it's a Google-designed feature (CRLSet) based on another Google-designed feature (auto updates).

Then you simply don't understand what the CRLset revocation system is, or why it works the way it does.

Re: No, don't enable revocation checking

#144

Post by tptacek »

gojomo wrote: post #142
enneff wrote: post #137

Earlier quoted context omitted.

Christ, this kind of reactionary armchair criticism really is a cancer of HN these days. Adam has been pushing the state of the art in cryptography in the practical realm for years, and your criticism is "They should have just solved this problem better! They should just pull their finger out and get working on it." Making a real difference in the chaotic realm of standards bodies and browser vendors is a lot harder…

The criticism isn't specifically for Langley, but rather for all of Google-Mozilla-Microsoft. They've all been derelict on this, knowing the certificate-revocation standards are hopelessly broken, but not fixing it from their positions of power and responsibility. (Might it take a product-liability lawsuit, where somebody suffers financial loss because Chrome is deceptively showing the "secure" indicator even for cer…

Google, with its plentiful expertise and cash, counts as its two fiercest competitors two of the three organizations that would need to agree with any new solution to revocation.

Meanwhile, you've offered a "sketch of a solution" that involves CAs (a) cooperating with Google and (b) employing computer science in the pursuit of writing actual code. Why not talk to Comodo and see how likely that is to happen?

You know who thinks CRLsets suck? Adam Langley. Certificate revocation is broken. They did what they could. Google didn't design SSL revocation.

All Google has done is orchestrate the adoption of TLS forward secrecy, fixed security vulnerabilities (for many years running) in OpenSSL (along with virtually every other component to modern web browsers, along with ffmpeg and the open source video stack), invented and deployed browser certificate pinning, spearheaded the deployment of Certificate Transparency, oh, and found/fixed Heartbleed.

But, I'm sure your comments are great. Why not take them to the IETF TLS WG? I'm sure you'll find an eager audience. I am not kidding.

Re: No, don't enable revocation checking

#145

Post by gojomo »

tptacek wrote: post #143
gojomo wrote: post #141

Earlier quoted context omitted.

It looks to me like the Chromium team did choose the size of the lifeboat: it's a Google-designed feature (CRLSet) based on another Google-designed feature (auto updates).

Then you simply don't understand what the CRLset revocation system is, or why it works the way it does.

Then correct me, don't insult me.

Isn't CRLSet a Google invention? Doesn't it depend on Chrome software updates?

All I know about it, I read from Langley's writings. Is there a better reference?

Who set the implemntation limits, if not Google?

Maybe those limits are justifiable, but that doesn't leave someone who's left unprotected, by what seem like arbitrary policy cutoffs, feeling any better.

Re: No, don't enable revocation checking

#146

Post by tptacek »

gojomo wrote: post #145
tptacek wrote: post #143

Earlier quoted context omitted.

Then you simply don't understand what the CRLset revocation system is, or why it works the way it does.

Then correct me, don't insult me. Isn't CRLSet a Google invention? Doesn't it depend on Chrome software updates? All I know about it, I read from Langley's writings. Is there a better reference? Who set the implemntation limits, if not Google? Maybe those limits are justifiable, but that doesn't leave someone who's left unprotected, by what seem like arbitrary policy cutoffs, feeling any better.

Your feelings aren't material to the issue at hand. You're not supposed to feel good about CRLsets.

Google didn't invent this idea. It was suggested by the CABForum.

CRLsets are static, practically hardcoded revocations that every installation of Chrome receives. The idea that https://yourblog.com should expect specific consideration in Chrome updates is about as reasonable as suggesting that we revert back from the DNS to host files.

Re: No, don't enable revocation checking

#147

Post by gojomo »

tptacek wrote: post #146
gojomo wrote: post #145

Earlier quoted context omitted.

Then correct me, don't insult me. Isn't CRLSet a Google invention? Doesn't it depend on Chrome software updates? All I know about it, I read from Langley's writings. Is there a better reference? Who set the implemntation limits, if not Google? Maybe those limits are justifiable, but that doesn't leave someone who's left unprotected, by what seem like arbitrary policy cutoffs, feeling any better.

Your feelings aren't material to the issue at hand. You're not supposed to feel good about CRLsets. Google didn't invent this idea. It was suggested by the CABForum. CRLsets are static, practically hardcoded revocations that every installation of Chrome receives. The idea that https://yourblog.com should expect specific consideration in Chrome updates is about as reasonable as suggesting that we revert back from the…

Yes, feelings are immaterial, but you shouldn't be trying to convince with bluster when you've erred on the facts.

The more I read, the more it seems CRLSet implementation choices were entirely Google's. For example, when CABForum members want information about how CRLSets work, Langley suggests the best (and only!) reference is the Chrome source code:

https://cabforum.org/pipermail/public/2013-August/002149.htm...

I am of course open to better information. But for now it still looks like Google did indeed "choose how big to make the lifeboat", unlike your assertion to the contrary.

Also, it looks like the 250KB cap is in Google's unpublished server-side source that constructs the CRLSets. So Google could conceivably "expand the lifeboat" unilaterally with a tiny edit!

For reference, it appears the current 'Safe Browsing' blacklists, never more stale than 45 minutes, are about 2.3MB in size. So the CRLSet cap (250KB) and freshness (1 day) aren't very generous to users.

Re: No, don't enable revocation checking

#148

Post by gojomo »

tptacek wrote: post #144
gojomo wrote: post #142

Earlier quoted context omitted.

The criticism isn't specifically for Langley, but rather for all of Google-Mozilla-Microsoft. They've all been derelict on this, knowing the certificate-revocation standards are hopelessly broken, but not fixing it from their positions of power and responsibility. (Might it take a product-liability lawsuit, where somebody suffers financial loss because Chrome is deceptively showing the "secure" indicator even for cer…

Google, with its plentiful expertise and cash, counts as its two fiercest competitors two of the three organizations that would need to agree with any new solution to revocation. Meanwhile, you've offered a "sketch of a solution" that involves CAs (a) cooperating with Google and (b) employing computer science in the pursuit of writing actual code. Why not talk to Comodo and see how likely that is to happen? You know…

Cooperation of competitors is not necessary — that's an excuse for inaction. As with 'Safe Browsing' (or CRLSet), one browser could lead the way, letting the others follow the same model or improve later.

Similarly, CA buy-in is not a blocking prerequisite for a better approach — it's just another excuse for inaction. Exactly as with CRLSet, the browser vendor can say, "we'll scrape your revocations where we can find them, or you can provide them this way". Then, if an incompetent or recalcitrant CA hides their revocations, it's an issue between the CA and their harmed customers.

It's great you, me, and Adam Langley all agree that revocation is broken, including Google's stopgap proprietary solution. But hasn't everyone understood that for 15+ years? Why isn't there a fix?

The browser makers absolutely own responsibility for this, because they're the ones that show end-users a security indicator. They're shipping the software that creates a risk, they can unilaterally fix this on their own initiative, and they're not so poor or stupid that fixing it should be beyond their capabilities.

Yes, Google has done a lot for security. Their 'web security karma' is very net-positive. They still deserve a demerit, along with Mozilla and Microsoft, on this particular issue.

Referring this to the IETF for standardization is just another way of excusing more inaction and delay.

Re: No, don't enable revocation checking

#149

Post by dvanduzer »

edwintorok wrote: post #120
dvanduzer wrote: post #14

Earlier quoted context omitted.

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/

sayI appears to be the directory service designed for MinimaLT / Ethos. CurveCP looks like it fits in the same use case as MinimaLT. That's where I'd say Telehash lives, too (but I've only skimmed any of these papers so far).

Telehash started out life as a more generalized global DHT-for-your-apps design circa 2010, and the spec has since evolved significantly to include the same kind of wire-level crypto.

Opening an issue is the easiest way to get the FAQ updated (and we'd definitely appreciate the feedback): https://github.com/telehash/telehash.org/issues

Re: No, don't enable revocation checking

#150

Post by tptacek »

gojomo wrote: post #147
tptacek wrote: post #146

Earlier quoted context omitted.

Your feelings aren't material to the issue at hand. You're not supposed to feel good about CRLsets. Google didn't invent this idea. It was suggested by the CABForum. CRLsets are static, practically hardcoded revocations that every installation of Chrome receives. The idea that https://yourblog.com should expect specific consideration in Chrome updates is about as reasonable as suggesting that we revert back from the…

Yes, feelings are immaterial, but you shouldn't be trying to convince with bluster when you've erred on the facts. The more I read, the more it seems CRLSet implementation choices were entirely Google's. For example, when CABForum members want information about how CRLSets work, Langley suggests the best (and only!) reference is the Chrome source code: https://cabforum.org/pipermail/public/2013-August/002149.htm... I…

I said that the idea came from CABForum because that's what Langley said. Moving from 250k to 2.3M still wouldn't put your blog in the lifeboat. Also: the CRL entries in the CRLsets are manually curated; someone is doing that work for you, for free.
Post reply on HN