Gathering session cookies with Firesheep

There are a couple of points that seem worth commenting on specifically:

>Does it open the user up to some additional attacks (e.g. phishing)? Yes.
Extraordinary claims require extraordinary evidence.

>And the interaction patterns associated with "self-signed certs are OK" are intimately tied up with "the cert sometimes changes on you"

If that's the case, then it's clearly a bug. These situations are entirely orthogonal.

>My question to you: how do you train Joe Public to differentiate between: "This cert has changed!" (you are now being MITMed) and "This cert has changed!" (the server operator changed their cert)?

I don't really care, because even if they can't the worst case scenario is still strictly better than the present situation.

>"Hello, is that Marks and Spencer?"

Presumably M&S can afford a CA-signed certificate should they want one.

>The expense of certificates is no longer a factor here. Go get a free cert from StartCom and be happy.

Allowing these sorts of CAs comes with all the downsides of self-signed certificates, plus the additional problem that the client needs to trust that CA, which can't be guaranteed.

You can't. I know all about how TLS works, but I'd have no idea how to tell whether a cert is actually legitimate. (Look at details, try to find the fingerprints, Google them . . . ?) So you make a best guess. Browsers currently guess that any cert change is due to MITM, and thus throw up scary warning messages and make it difficult to continue. But in fact, as a paper by Microsoft Research observes:

"""
Ironically, one place a user will almost certainly never see a certificate error is on a phishing or malware hosting site. That is, using certificates is almost unknown among the reported phishing sites in PhishTank [7]. The rare cases that employ certificates use valid ones. The same is true of sites that host malicious content. Attackers wisely calculate that it is far better to go without a certificate than risk the warning. In fact, as far as we can determine, there is no evidence of a single user being saved from harm by a certificate error, anywhere, ever.

Thus, to a good approximation, 100% of certificate errors are false positives. Most users will come across certificate errors occasionally. Almost without exception they are the result of legitimate sites that have name mismatches, expired or self-signed certificates.
"""
http://research.microsoft.com/en-us/um/people/cormac/pape...

So if you're going to make an informed guess on the user's behalf, you should guess that the cert is self-signed or mismanaged and not bother the user about it.

Of course, this logic taken on its face would say you should just get rid of TLS entirely, which is wrong. The reason MITM attacks with self-signed certs don't occur is *because* of the warning messages. But the drastic overreaction here by browsers just erodes users' confidence in browser warnings. They need to present the issue more realistically and honestly, keeping in mind that most cert errors are actually innocuous.

(Chrome is particularly egregious here. I've seen it flat-out refuse to let me continue because it thought a cert was expired or revoked or something, but it was just some stupid Microsoft feedback site that I wasn't submitting anything secret to at all, so if it was a MITM I just didn't care. And it makes flat-out wrong claims like "This is probably not the site you are looking for!" Firefox is wordy and tedious, but at least it doesn't outright lie to you. Still, the severity of the warning message even on pages that you can easily guess are legitimate, like <https://amazon.com>, is really unwarranted.)

I think a lot of this debate can be solved by STS. Once all sites that really need TLS are using STS with long expiration times, and browsers come with a prepackaged list of such sites that they update regularly like their lists of malware sites, the UI for non-STS TLS should be relaxed considerably. STS is probably how TLS should have worked to begin with.

Also, serving certs through DNSSEC gives us a chance to make them easier to deploy, and moots the question of self-signing. So I think we can improve the situation a lot here. But browsers' current UI for cert errors still is not at all reasonable.

A protocol that is protected against passive eavesdropping, is thus more secure than a protocol which isn't.

Arguing that self-signed-https is NOT more secure than plain http, is precisely analogous to arguing that ssh is not more secure than telnet.

Running active MITM-attacks is actually more difficult, more costly and more likely to be discovered than merely sniffing plaintext-traffic that passes by. Thus defending against passive listening-attacks, is better than doing nothing at all.

ssh is, infact, more secure than telnet.

I agree that Joe Public can't be trained to evaluate the danger of a changed certificate - but (and this is a big but) even if he cannot - how does that make him worse off, compared to http ?

Yes, true. Joe Public won't notice active man-in-the-middle attacks when the site uses self-signed https. But that is ALSO true of plain http.
The browsers, effectively, claim that "self-signed https is MORE dangerous than plain http"

If we where arguing which is more secure of externally-signed and self-signed, then we'd agree: externally-signed is better for foiling man-in-the-middle.

But that's not my argument !

My argument is that self-signed-https is superior to plain http. And thus it's insane to put scary warnings on it, which are absent from http.

http is WORST. self-signed https is BETTER. externally-signed https is *BEST*