Self-published certificates can _not

Self-published certificates can _not_ stop DPI

Posted Aug 28, 2008 2:49 UTC (Thu) by darwish07 (subscriber, #49520)
Parent article: Firefox 3 SSL certificate warnings

There are other reasons to encrypt traffic, though, including evading deep packet inspection (DPI), where the risks of accepting a bogus certificate are relatively low. One might get ads injected into their web browser inappropriatelyannoying, but hardly fatal.

Deep Packet Inspection/Modification can be done easily on a self-published-certificate website traffic by making the router in the middle acts as a HTTPS proxy, where that proxy makes the SSL connection between itself and the far-away server (the website server) then maintain a sockets pipe (using select()) between the browser, itself and the real destination server.

This of-course needs routing the traffic not by destination as normal IP implementations does, but by content using new routing table entries format like 'tcp port http and https go to localhost proxy port 8000' in the compromised or government monitored gateway. And yes, I've personally seen it done using the Linux networking stack.

(Log in to post comments)

Self-published certificates can _not_ stop DPI

Posted Aug 28, 2008 5:29 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]

Right, but it's even EASIER (less cpu expensive, less complex software, less clearly illegal, etc) on plain HTTP traffic. Not to mention that plain HTTP leaves you completely vulnerable to passive eavesdropping, which is completely prevented with a simple unauthenticated https.

We have this weird situation where many sites avoid using self-signed encryption in favor of *plain-text*. Thats broken. The preference should be authenticated certs from trusted cert vendors > authenticated certs from minor cert vendors > self-signed >>>> plain-text.

From the users perspective plain-text mode and self-signed should look exactly equal: Both are not authenticated both could be forgeries.

There is no need to single out self-signed HTTPS:, and doing so reduces user security rather than increasing it.

Self-published certificates can _not_ stop DPI

Posted Aug 28, 2008 13:07 UTC (Thu) by alankila (subscriber, #47141) [Link]

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.

Self-published certificates can _not_ stop DPI

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

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 (subscriber, #39285) [Link]

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