Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 4:35 UTC (Thu) by blitzkrieg3 (guest, #57873)
In reply to: Transport-level encryption with Tcpcrypt by djao
Parent article: Transport-level encryption with Tcpcrypt

If you see the little locked icon in your address bar, you shouldsleep easy in the knowledge that the only other party to view your communications was the web site. The fact that no-auth algorithms are easily exploitable by MitM makes them kind of uninteresting, and users _should_ be scared into not connecting, especially if they're doing something like web banking, which is what the majority of TLS is used for these days.

to post comments

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 4:51 UTC (Thu) by djao (guest, #4263) [Link] (5 responses)

I never suggested that an unauthenticated connection should have a lock icon. In fact, the reverse is true -- they should not have a lock icon. The lock icon should remain reserved for situations where the user needs to sleep easy.

Your web banking example is a bad one. Firefox already allows unencrypted unauthenticated connections without any scary warnings, even if the user is doing web banking. Currently, an attacker can already launch a phishing attack using no SSL/TLS at all. Unless the user notices that the lock icon is absent, the attack will work often enough to be useful.

I propose allowing encrypted unauthenticated connections, with no warnings, and no lock icon. This does not make attacks any easier than they are now. Every attack that an attacker can perform using encrypted unauthenticated connections can also be performed using unencrypted unauthenticated connections.

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 14:39 UTC (Thu) by foom (subscriber, #14868) [Link] (4 responses)

> This does not make attacks any easier than they are now.

Yes it does. Let's say you have https://mybank.com bookmarked or memorized. You go to that url expecting it to be secure. That has always been the case up till now [modulo the questionable trustworthiness of the 5000 multinational certification authorities your browser trusts].

With your proposal, I would have to check on every connection to see if there's a "lock" icon for that site, because https now just means "please encrypt" not "please authenticate". That is definitely a loosening of security, and will make MiTM attacks possible where they were not before. Nobody is gonna go for that...

For your proposal to actually work, you need to do the opposite: transparently *upgrade* http:// to be anonymously-encrypted when possible. That's a great idea. But you've gotta leave https:// alone.

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 14:50 UTC (Thu) by djao (guest, #4263) [Link] (2 responses)

You make a valid point. However, this problem can be easily, almost trivially fixed. The browser can (and should) be programmed to give a huge scary warning if a web site which previously offered authentication in the past has changed so that it no longer offers authentication.

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 16:42 UTC (Thu) by gmaxwell (guest, #30048) [Link]

I don't know that I agree but instead I'd argue that few enough people are typing the "https" that it's irrelevant: Because most people are typing "http" (or providing no protocol at all) We absolutely _MUST_ solve the bootstrapping problem regardless of warning free cert-free-ssl, and people are diligently working on that problem, and any solution to that also addresses the concerns with warning-free-https.

The authentication-state caching thing you suggest is one possible solution, but it's somewhat fragile and still leaves a window of exposure. See https://secure.wikimedia.org/wikipedia/en/wiki/Strict_Tra... for more information on the initiatives in this area.

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 18:22 UTC (Thu) by Simetrical (guest, #53439) [Link]

This is basically exactly what STS (formerly known as ForceTLS) does. For added effectiveness, browsers will likely precache STS headers for many major sites. Once this is done, there will be no reason to present scary warnings anymore for self-signed certs. Firefox has just implemented this: it's RESOLVED FIXED as of two days ago, so I guess it will be in the next Firefox 4 beta.

I still agree that the current behavior is way over the top. As this paper observes, a certificate error these days is a guarantee that the site is not malicious, since only a complete idiot of an attacker would try pulling off an attack via a page that raised a giant error . . .

Transport-level encryption with Tcpcrypt

Posted Aug 27, 2010 10:12 UTC (Fri) by epa (subscriber, #39769) [Link]

Perhaps https should remain reserved for encrypted, authenticated connections, but a new 'httpx' or similar URI scheme would be introduced for encrypted but not-necessarily-authenticated ones.

95% of users have no idea what https means or even that there is a difference between http and https, so it's not a big issue, but I take your point that any change shouldn't downgrade the security currently offered by https bookmarks.

Transport-level encryption with Tcpcrypt

Posted Aug 29, 2010 16:37 UTC (Sun) by Tet (subscriber, #5433) [Link] (2 responses)

If you see the little locked icon in your address bar, you should sleep easy in the knowledge that the only other party to view your communications was the web site

Utter nonsense. Yes, that's supposed to be how it works, but in the real world, it's simply not true. The obvious example is 3-D Secure, as used by banks here in the UK (and elsewhere?). You go to a web site, fill your cart and go to the checkout. You enter your credit card details, because the lock icon is present and you're confident that it's not a scam site. Then you're sent to a secondary authentication page. The lock icon is still showing everything's good. But what you're seeing is actually an iframe pointing to an entirely different site (in my case, hopefully it's LloydsTSB ClickSafe). But the padlock icon has nothing to do with this site, and thus offers no guarantees that the connection is secure, or that the page is being served by an entity that you trust. As a technically adept user, I can (and do) explicitly check the certificate of the iframe. But I'm in a very, very small minority. It's trivially easy for a phishing site to show a valid padlock throughout the entire transaction.

Transport-level encryption with Tcpcrypt

Posted Aug 29, 2010 17:52 UTC (Sun) by foom (subscriber, #14868) [Link]

That is how it works.

The padlock is shown on the outermost site. It is up to that site to ensure the security of its own website against XSS, against hacking of its servers, and against using insecure content inappropriately. It's their responsibility, not yours, to make sure they use secure iframes not insecure ones. And your browser checks the certificate to make sure that it *actually* belongs to the site that your bank trusted. So no, you don't need to verify every iframe individually.

Okay, so it's not literally true that "the only other party to view your communications was the web site", it's the web site and other web sites that the web site trusts.

> It's trivially easy for a phishing site to show a valid padlock throughout the entire transaction.

Of course, but that has nothing to do with the rest of your complaint. In the case of a phising site, "the web site" that the user is visiting, and which is protected, is the phising site.

Transport-level encryption with Tcpcrypt

Posted Sep 2, 2010 8:47 UTC (Thu) by eduperez (guest, #11232) [Link]

That is why my bank refuses transactions if their website is displayed inside an iframe.