5 ms·

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 prac

by enneff 13y ago

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 than it looks. Adam has an impressive track record for actually improving internet security for users. Where's your suggestion for how revocation could be solved better and implemented in a practical way? I don't see you rolling up your sleeves to get the actual work done.

dang 13y ago
> armchair criticism [...] is a cancer of HN Yes. It has been for a long time. Long term, we want to figure out ways to improve thread quality. Not so much in terms of the toxicity problem, which has seen some progress lately (we hope), but the arguably harder problem of voluminous uninformed commentary clustering around the mean. If you (or anyone) have any suggestions, I'd love to hear them. hn@ycombinator.com is the best place to send them. (This is not about any particular comments in the current thread, only the problem in general.)
gojomo 13y ago
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 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.
- tptacek 13y ago
  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.
  - gojomo 13y ago
    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.

by enneff 13y ago

dang 13y ago

> armchair criticism [...] is a cancer of HN Yes. It has been for a long time. Long term, we want to figure out ways to improve thread quality. Not so much in terms of the toxicity problem, which has seen some progress lately (we hope), but the arguably harder problem of voluminous uninformed commentary clustering around the mean. If you (or anyone) have any suggestions, I'd love to hear them. hn@ycombinator.com is the best place to send them. (This is not about any particular comments in the current thread, only the problem in general.)

gojomo 13y ago

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

tptacek 13y ago
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.
- gojomo 13y ago
  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.