Transport-level encryption with Tcpcrypt

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

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.