Self-published certificates can _not

Self-published certificates can _not_ stop DPI

Posted Aug 28, 2008 13:07 UTC (Thu) by alankila (guest, #47141)
In reply to: Self-published certificates can _not_ stop DPI by gmaxwell
Parent article: Firefox 3 SSL certificate warnings

While it is better in privacy sense to use SSL than not use SSL, there is still the issue that as man-in-the-middle attacks are just as possible as before.

The most serious objection I can see for any scheme that accepts untrusted certs without bothering user with it, is that it can be thwarted by constructing a proxy that impersonates remote SSL sites with lookalike certificates of its own. So the browser damn well can't just decide silently to proceed when it sees a self-signed cert.

And now comes the problem: Does the user really know if the site is supposed to have a real certificate instead of self-signed one? So you get back the UI question that says something like "This site has a self-signed certificate for privacy protection only. Proceed to connect? [N/y]" and most users will answer "y".

This, in effect, reintroduces the simple warning we just get rid of, and undermines the security of the real certificates by making it easier to substitute them with self-signed ones. In effect, the whole value of this new scheme is in the fact that it is actually annoying and scary. We could, I guess, introduce http/1.2 or something that encrypted ordinarily plaintext traffic, though. Just don't call it https, and don't tell user about it.

to post comments

Self-published certificates can _not_ stop DPI

Posted Aug 28, 2008 13:55 UTC (Thu) by gmaxwell (guest, #30048) [Link] (1 responses)

So the browser damn well can't just decide silently to proceed when it sees a self-signed cert.

So why then does the browser connect to plain HTTP sites without a warning? At *best* plain HTTP is equally vulnerable, and realistically it's a heck of a lot more practical to exploit plain HTTP.

"This site has a self-signed certificate for privacy protection only. Proceed to connect? [N/y]" and most users will answer "y".

Why the heck would it do that? Non-https sites don't cause the browser to say "This site is not protected by SSL at all. Proceed to connect?" today, so why should it do that?

I could see an argument that that "https" in the URL bar has some significance to the user, though I suspect any study of user behavior would show otherwise. But this could easily be addressed: Adjust the URL bar so the protocol is not displayed normally, have it be off to the left where you can reach it while editing the URL but not where it's normally displayed. Denote properly authenticated https with the traditional padlock icon, and the new and fancy colored URL bar. Users on the more clueless end of the spectrum will think that non-authenticated HTTPS == Plain HTTP, which is true in the worst case. No surprises.

Self-published certificates can _not_ stop DPI

Posted Aug 28, 2008 14:53 UTC (Thu) by johnkarp (guest, #39285) [Link]

I think the point is that an illusion of security can be worse than no security at all.