No, don't enable revocation checking

Re:No, don't enable revocation checking by tptacek on Monday April 21, 2014 @11:04AM (#7621378)

Why are TLS block cipher constructions still MAC-then-encrypt, 13 years after Bellare and Namprempre proved that was the wrong way to do it? Because standards are hard.

You can blame the browser makers as much as you want, but among them as a group, nobody has worked harder on making TLS better and safer than Google. But here you are berating them for the effort.

[ Parent | on HN ]

Re:No, don't enable revocation checking by einhverfr on Tuesday April 22, 2014 @11:49AM (#7628379)

But the objection is still the same.

Here's the thing. I have been advertising the impact of this decision by Chrome on our SaaS business. It just isn't acceptable that cert revocation means one thing if you are Yahoo but another if you are a startup SaaS business.

As I have said repeatedly, this is a way to ensure that things are comfortable enough for the people at the top that everyone else is sacrificed in the name of it being too much trouble, working for free, etc. But as long as the big sites are protected by Google, nothing will get fixed and us smaller competitors will be screwed.

I am sorry, but that's just morally wrong. And it is the major reason I now recommend Firefox over Chrome.

[ Parent | on HN ]

Re:No, don't enable revocation checking by gojomo on Monday April 21, 2014 @02:36PM (#7622770)

Again, standards don't need to be a blocker for the revocation issue (as CRLSet itself demonstrates). "Standards are hard" is an excuse for inaction.

I can applaud Google's efforts in general yet still point out when there's one egregious, embarrassing gap. They are one of the only three institutions worldwide that could possibly fix this for users, and I'm not picking on them over the others.

[ Parent | on HN ]