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-in auto-updates to make a subset of "high-value revocations" work, at a daily frequency, for Chrome users only, is not a very web-friendly solution.
It's like a gated community hiring its own rent-a-cops... maybe that's an improvement for the fortunate ones on the inside, and maybe a necessary stopgap. But to people outside that perimeter – like someone whose revocation doesn't make it into the Google CRLSet – it feels like an abdication of duty by the web's stewards.
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.
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.)
(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.
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 Amazon more secure and the small SaaS provider less so. And it makes sure that the big providers have less incentive to fix the underlying concerns.
