SSL And The Future Of Authenticity

win32sux · 04-11-2011, 04:14 PM

Quote:

In the early 90's, at the dawn of the World Wide Web, some engineers at Netscape developed a protocol for making secure HTTP requests, and what they came up with was called SSL. Given the relatively scarce body of knowledge concerning secure protocols at the time, as well the intense pressure everyone at Netscape was working under, their efforts can only be seen as incredibly heroic. It's amazing that SSL has endured for as long as it has, in contrast to a number of other protocols from the same vintage. We've definitely learned a lot since then, though, but the thing about protocols and APIs is that there's very little going back.

Generally speaking, all secure protocols need to provide three things: secrecy, integrity, and authenticity. If any of these break, the whole protocol breaks. SSL doesn't do any of the three very elegantly by today's standards (and in many cases just barely squeaks by), but most of the practical attacks we've seen over the past ten years have focused on the authenticity piece. The designers of SSL chose to use Certification Authorities as a key component of the authenticity process, and we've been stuck with that decision even after having long since outgrown the circumstances in which it was originally imagined.

Lately, however, the general perception of Certification Authorities seems to be shifting from the old vibe of "total ripoff" to a new vibe of "total ripoff and also insecure." So there has been a growing amount of talk about changing the authenticity piece of SSL. I'd like to take a moment to discuss the problem, though, so that we don't accidentally make the same mistake twice.

Complete Article

Thanks to Slashdot for covering this.

Telengard · 04-11-2011, 04:48 PM

Steve Gibson of GRC has covered the good and bad of SSL in great depth on his podcast, the latest episode of which is titled "The Comodo SSL Breach".

index and show notes
high quality audio and video

My own thought is this. The way certificates are used on the web is defective. Whenever I've been asked to accept a certificate I'm not given any reason to trust the party offering the certificate. I used to read them all word for word, but after some time I realized that I was wasting my time. You might say that I just don't know how to read the certificate, and that's probably true. If a technically inclined user such as myself can't decide whom to trust based on a certificate, what does that say about average users who just click through every dialog they see?

win32sux · 04-11-2011, 08:13 PM

Quote:

Originally Posted by Telengard

My own thought is this. The way certificates are used on the web is defective. Whenever I've been asked to accept a certificate I'm not given any reason to trust the party offering the certificate. I used to read them all word for word, but after some time I realized that I was wasting my time. You might say that I just don't know how to read the certificate, and that's probably true. If a technically inclined user such as myself can't decide whom to trust based on a certificate, what does that say about average users who just click through every dialog they see?

Well, if you tell your browser to accept a certificate which it isn't able to verify by means of a trusted third party's signature, then you're pretty much set for getting owned, regardless of whether you read the certificate or not (that is, unless you have some way to securely verify the certificate's authenticity using out-of-band means, of course). I'm not exactly sure what one would hope to gain by reading the unsigned certificate (unless you're using OoB means, which is almost unheard of with average users), as it could be a totally convincing forgery. It doesn't matter whether it's coming from a trusted party or not, as it could have been tampered with using any number of techniques, be it on the server itself or on the way down to the client (even on the client itself, FWIW).

Telengard · 04-11-2011, 09:57 PM

Quote:

Originally Posted by win32sux

Well, if you tell your browser to accept a certificate which it isn't able to verify by means of a trusted third party's signature, then you're pretty much set for getting owned

In theory, yes. In practice users are frequently stuck deciding whether to accept the certificate or do without the product or service. And it isn't just browsers, but also IRC clients, Java and other applications.

win32sux · 04-11-2011, 11:45 PM

Quote:

Originally Posted by Telengard

In theory, yes.

It's not theory. If you accept a certificate without having verified the authenticity of it (which can't be done by only reading it), then you're playing Russian roulette. Granted, most people probably aren't under MITM attack, but still, they wouldn't have a clue if they were.

Quote:

In practice users are frequently stuck deciding whether to accept the certificate or do without the product or service.

I agree (although I don't know the actual frequency of this phenomena).

FWIW, I do remember at least three occasions in which a site provided a certificate which my browser complained about. The first occasion was due to server-side misconfiguration, which was quickly addressed after filing a report with the site's IT people. In that case, I didn't have much of a choice and had to wait for the problem to be fixed (I decided that accepting the certificate manually wasn't an option). The second occasion I remember was on an e-commerce site, and there I simply decided to take my business elsewhere. On the last occasion, I actually had to bite the bullet after some really lame OoB verification to somewhat gauge the possibilities of being under MITM attack. The fact that I wasn't gonna be transmitting anything truly private/confidential weighed in substantially, and I took measures to reduce the impact of any injection attacks done via MITM (mainly browser hardening as well as isolation via MAC and disposable VM). IIRC, it was a US Navy website, and a subsequent Firefox update a couple weeks later allowed the certificate to be properly validated.