News for hackers. Stuff that matters.

A comment on No, don't enable revocation checking. Parent comment

Re:No, don't enable revocation checking by chmars on Sunday April 20, 2014 @06:49AM (#7616442)
Honestly, I don't see a point in certificate revocations anymore, i.e., your implicit conclusion seems to be correct. And I don't blame Google for our broken revocation system – especially because the even the best revocation system couldn't fix the current certification system that is broken in its core.
[ Parent | on HN ]
Re:No, don't enable revocation checking by einhverfr on Sunday April 20, 2014 @11:46AM (#7617153)
Google's problem is they decide which revocations are worth passing on to the browser. That's at least as broken by design.....

Believe me I am aware of the limits of soft-fail, but the answer cannot be even in the short-run to let a browser vendor tell us which revocations are worth knowing about.

[ Parent | on HN ]
Re:No, don't enable revocation checking by enneff on Sunday April 20, 2014 @12:47PM (#7617451)
Soft fail doesn't work at all. CRLset works for the certificates that it covers (some 25k of them, btw).

Which approach is worse?

[ Parent | on HN ]
Re:No, don't enable revocation checking by mpyne on Sunday April 20, 2014 @02:25PM (#7617882)
> but the answer cannot be even in the short-run to let a browser vendor tell us which revocations are worth knowing about.

So you trust the browser vendor to ship you executable native code but you don't trust the browser vendor to apply reasonably decent criteria for the top x% most-needed cert revocations on the Internet?

[ Parent | on HN ]
Re:No, don't enable revocation checking by tptacek on Sunday April 20, 2014 @12:27PM (#7617351)
Do you know the limits of "soft-fail"? Because I don't see you addressing them.
[ Parent | on HN ]