Laurie: Improving SSL certificate security [LWN.net]

Laurie: Improving SSL certificate security

Posted Apr 3, 2011 16:27 UTC (Sun) by Kit (guest, #55925)
In reply to: Laurie: Improving SSL certificate security by geuder
Parent article: Laurie: Improving SSL certificate security

That wouldn't solve the problem of a MITM attack- you're forgetting that the page you're getting is from the _attacker_! If the attacker can get a valid certificate, they can just rewrite the page to make it say that /their/ certificate is valid... after all, the certificate is what is supposed to "prove" the authenticity of the page.

The "social problem" isn't going to be solved by implementing more convoluted systems that the user is simply annoyed/nagged by- any time the user is nagged by security you end up in the ActiveX situation: everyone will just be trained to hit 'yes'/'accept' and totally ignore the text, or the context.

to post comments

Laurie: Improving SSL certificate security

Posted Apr 3, 2011 17:58 UTC (Sun) by jthill (subscriber, #56558) [Link]

I wish people would distinguish certificates from keys. A CA signing a key doesn't make the key valid. Trusting a CA is tantamount to surrendering to a MITM attack in advance -- in every real sense, a CA _is_ a MITM.

If your partner's system and your system are uncompromised (i.e. the attacker is still "in the middle"), a valid key makes the connection absolutely secure. Google's effort is an attempt to make it easier to be ~mostly sure~ a key is valid, and I think it's a good one, but I also think that the real problem is going to be getting people to verify keyprints at all -- the entire CA-infrastructure tribe eats by keeping people ignorant and verification inconvenient, so you can expect any effort like Google's to be met with a FUD storm.

Laurie: Improving SSL certificate security

Posted Apr 3, 2011 18:01 UTC (Sun) by geuder (subscriber, #62854) [Link] (3 responses)

> If the attacker can get a valid certificate

Yes, the attacker can get a valid certificate, but not a valid EV certificate. That has been the assumption for a couple of comments in this thread. With just a valid non-EV certificate the browser would not display the extra color/number info suggested

> everyone will just be trained to hit 'yes'/'accept'

That's why I suggested 3 options, and a different one is "correct" every day (one could also change the algorithm such that a different one is correct completely randomly from human perspective)

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 9:26 UTC (Wed) by jamesh (guest, #1159) [Link] (2 responses)

It shouldn't have been possible to for the attacker to create Domain Validated certificates, but they managed to due to policy problems (possibly due to them outsourcing the validation to a reseller?).

For EV certificates, we're being told that they are more secure because the CAs would never take similar shortcuts when validating these new certificates.

The existing track record of CAs doesn't inspire confidence that we'll never see a bogus EV certificate.

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 15:41 UTC (Wed) by martinfick (subscriber, #4455) [Link]

No, really, I mean it, you can trust this certificate (it is an EV). Well, what about that other one you issued that isn't an EV? Oh, you can trust that one too, we issued it. So, then why would I get an EV one? Because you can really trust an EV one. So I can't trust the non EV one? Well, no, of course, you can. ....[repeat]

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 17:55 UTC (Wed) by dlang (guest, #313) [Link]

it doesn't really matter, when the EV certs get down to the level of normal certs, they will invent 'new, really secure, we really mean it this time' certs and jack up the price on them even more. and a few years later they will do it again.