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

131–140 of 157 posts

Re: No, don't enable revocation checking

#131

Post by moe »

gojomo wrote: post #124
moe wrote: post #68

Earlier quoted context omitted.

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…

All interesting ideas... but don't directly address rapid trust revocation , as in the case of recent relevance: a site's private keys are assumed to have been compromised (as if by the heartbleed bug). Or are you suggesting every browser will contact many of its personal web-of-trust sources on every secure-connection? Without additional innovation, that seems just as prone to the performance bottlenecks or soft-fai…

Or are you suggesting every browser will contact many of its personal web-of-trust sources on every secure-connection?

For Hacker News? No.

For my bank? Yes, absolutely.

The implementation of a fast and scalable lookup is not exactly rocket science (cf. DNSBLs). It's a political problem, not a technology problem.

Re: No, don't enable revocation checking

#132

Post by Splendor »

tptacek wrote: post #130
Splendor wrote: post #129

Earlier quoted context omitted.

Does enabling revocation checking make me less safe?

Yes! It involves you reporting all the sites you visit to a CA!

I guess I knew that but hadn't grasped the security problem this presents. You've changed my mind. Thank you.

Re: No, don't enable revocation checking

#133

Post by einhverfr »

tptacek wrote: post #103
einhverfr wrote: post #102

Earlier quoted context omitted.

Ok, fair enough. I am just making sure my objection to Google's approach is clear. I would be OK if they guaranteed complete CRLsets from all participating CA's. Since they don't, their solution is more broken than what they are replacing. So I acknowledge that online revocation is problematic. I just think the crlset approach is an order of magnitude worse when the crlset is a subset of revoked entries sent by the c…

Respectfully, I think an accurate summary of your argument is that you would rather pretend to be secure using broken online revocation checks than to have to stomach the Chromium team providing a marginal amount of actual security by deciding which sites are and aren't worthy of protection.

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

Re: No, don't enable revocation checking

#134

Post by tptacek »

einhverfr wrote: post #133
tptacek wrote: post #103

Earlier quoted context omitted.

Respectfully, I think an accurate summary of your argument is that you would rather pretend to be secure using broken online revocation checks than to have to stomach the Chromium team providing a marginal amount of actual security by deciding which sites are and aren't worthy of protection.

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.

Re: No, don't enable revocation checking

#135

Post by gojomo »

moe wrote: post #131
gojomo wrote: post #124

Earlier quoted context omitted.

All interesting ideas... but don't directly address rapid trust revocation , as in the case of recent relevance: a site's private keys are assumed to have been compromised (as if by the heartbleed bug). Or are you suggesting every browser will contact many of its personal web-of-trust sources on every secure-connection? Without additional innovation, that seems just as prone to the performance bottlenecks or soft-fai…

Or are you suggesting every browser will contact many of its personal web-of-trust sources on every secure-connection? For Hacker News? No. For my bank? Yes, absolutely. The implementation of a fast and scalable lookup is not exactly rocket science (cf. DNSBLs). It's a political problem, not a technology problem.

Definitely agree that prompt revocation shouldn't be as hard as these apologetics-for-Chrome imply, and this hasn't festered as an unsolved problem for so long.

Re: No, don't enable revocation checking

#137

Post by enneff »

gojomo wrote: post #125
tptacek wrote: post #103

Earlier quoted context omitted.

Respectfully, I think an accurate summary of your argument is that you would rather pretend to be secure using broken online revocation checks than to have to stomach the Chromium team providing a marginal amount of actual security by deciding which sites are and aren't worthy of protection.

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

Re: No, don't enable revocation checking

#138

Post by hereonbusiness »

tptacek wrote: post #100
hereonbusiness wrote: post #65

So this complete infrastructure is crap. OpenSSL, a software half the internet uses but no one cares about because it's crap. CA's not revoking keys even though they know they're compromised. Revocation being worthless because it's too much of a hassle for anyone to bother. Great. Maybe now, when half the internet is already compromised and all our certificates are not worth the bytes they're made of ... maybe we sho…

Yes! Now it's time for us to generate a whole new broken infrastructure! I'm sure if we just rewrite all the Internet's crypto in Rust, everything will be great 10 years from now. No way will a radically different new transport cryptosystem grant researchers 100 new bugs to play with; after all, we'll have option types.

I'm no security expert but I guess there could be ways to keep TLS as a protocol more or less unchanged while fixing the obviously broken stuff surrounding it.

Re: No, don't enable revocation checking

#139

Post by cpeterso »

hereonbusiness wrote: post #65

So this complete infrastructure is crap. OpenSSL, a software half the internet uses but no one cares about because it's crap. CA's not revoking keys even though they know they're compromised. Revocation being worthless because it's too much of a hassle for anyone to bother. Great. Maybe now, when half the internet is already compromised and all our certificates are not worth the bytes they're made of ... maybe we sho…

Don't forget that 90% of the world's certificates are issued by five commercial CAs, who happen to be friendly with various national security agencies.

Re: No, don't enable revocation checking

#140

Post by dang »

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…

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

Post reply on HN