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

151–157 of 157 posts

Re: No, don't enable revocation checking

#151

Post by tptacek »

gojomo wrote: post #148
tptacek wrote: post #144

Earlier quoted context omitted.

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…

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…

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.

Re: No, don't enable revocation checking

#152

Post by dvanduzer »

lnanek2 wrote: post #117
dvanduzer wrote: post #9

I'm having a lot of trouble getting past: "Certificates bind a public key and an identity (commonly a DNS name) together." X.509 certificates bind a public key and a human recognizable string (a "common name") together to create a verifiable digital identity. Over-simplified, X.509 is about solving the "I'm Spartacus" problem. CRLs solve the "He was Spartacus" problem. I agree with the broad conclusion that CRLs aren…

For HTTPS to a web site, the common name is the site domain name. We're not talking about anything else here.

Aha. That perhaps explains all the downvoting. But this was my objection:

Name != Identity

It's nearly impossible to have a meaningful English conversation about these problems without getting that straight.

Re: No, don't enable revocation checking

#153

Post by psykovsky »

magicalist wrote: post #121
psykovsky wrote: post #111

Earlier quoted context omitted.

And I'm sure you are wrong. I only see a Validation option(not Revocation), which has 2 more options on how to check OCSP, and those are both checked using the defaults. The correct path on my OS is Edit -> Preferences -> Advanced -> Certificates -> Validation -> OCSP options(both checked)

I think you've altered your settings at some point. It's not the default. You would see a huge influx of bugzilla entries of "Firefox is broken" if hard fail was the default. edit: the checkbox in the validation subdialog (ocsp.xul) is tied to security.OCSP.require, which is set here with a default of false in the Firefox source: http://dxr.mozilla.org/mozilla-central/source/netwerk/base/p...

> I think you've altered your settings at some point. It's not the default.

I think some extension or some other thing changed them for me. I don't remember ever opening the OCSP dialog until now :/

Re: No, don't enable revocation checking

#154

Post by gojomo »

tptacek wrote: post #150
gojomo wrote: post #147

Earlier quoted context omitted.

Yes, feelings are immaterial, but you shouldn't be trying to convince with bluster when you've erred on the facts. The more I read, the more it seems CRLSet implementation choices were entirely Google's. For example, when CABForum members want information about how CRLSets work, Langley suggests the best (and only!) reference is the Chrome source code: https://cabforum.org/pipermail/public/2013-August/002149.htm... I…

I said that the idea came from CABForum because that's what Langley said. Moving from 250k to 2.3M still wouldn't put your blog in the lifeboat. Also: the CRL entries in the CRLsets are manually curated; someone is doing that work for you, for free.

And I understood correctly about who chose the "size of the lifeboat", also because of what Langley said.

The person upthread unhappy that Chrome didn't pick up their revocation (einhverfr) isn't worried about a measly blog, but their SaaS business.

If 2.3MB isn't enough to protect everybody, make it 23MB or take whatever other design steps are necessary. The world's most popular browser, from the world's most profitable internet company, in 2014 shouldn't be showing the lock-icon and "valid certificate" hours/days/weeks after a publicly-available revocation.

"Manual curation", rather than being impressive, is a design-smell here. And none of Google's work to outcompete other browsers, using proprietary Chrome features, is being done for me "for free".

Re: No, don't enable revocation checking

#155

Post by gojomo »

tptacek wrote: post #151
gojomo wrote: post #148

Earlier quoted context omitted.

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…

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.

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.

Re: No, don't enable revocation checking

#156

Post by lucian1900 »

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.

You're right to mock the attitude people have that the only thing wrong with OpenSSL is the language it's written in, but memory unsafety has nevertheless been a factor in many security flaws.

Re: No, don't enable revocation checking

#157

Post by einhverfr »

tptacek wrote: post #151
gojomo wrote: post #148

Earlier quoted context omitted.

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…

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.

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.

Post reply on HN