Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 3:33 UTC (Thu) by djao (guest, #4263)
Parent article: Transport-level encryption with Tcpcrypt

It is important to emphasize that the tcpcrypt effort is being led by skilled and experienced cryptographers. The USENIX conference where the paper was published is highly regarded, and one of the authors (Boneh) is arguably the top cryptographer of this generation. In short, tcpcrypt is not your average snake oil -- it is a serious proposal, worthy of consideration.

I'm glad to see that tcpcrypt adopts the sensible policy of encrypting by default, even when authentication is not available. Many other protocols, such as SSL, refuse to work without authentication, or at best provide only second-class support for this use case, and this horrible design decision is in my opinion (yes, I am a cryptographer) the single worst mistake ever made in the history of network security. Firefox, in particular, is one of the worst offenders: an unauthenticated encrypted connection is met with scarier warnings and error messages than radioactive waste, whereas a totally unencrypted (and also unauthenticated) connection is allowed through with no warnings whatsoever! The Firefox example is a dramatic illustration of the absurdity that arises when programmers without cryptography expertise try to write security software. It would be supremely satisfying to see this vexing problem fixed at a lower level through ubiquitous deployment of tcpcrypt.

(Before anyone chimes in with the usual advice to "send a patch": it's been tried already, and it didn't work. For better or for worse, the Firefox developers are convinced that they are right, and nothing will sway them from that view.)

to post comments

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 4:35 UTC (Thu) by blitzkrieg3 (guest, #57873) [Link] (9 responses)

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.

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.

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 15:39 UTC (Thu) by zooko (guest, #2589) [Link] (7 responses)

> The Firefox example is a dramatic illustration of the absurdity that arises when programmers without cryptography expertise try to write security software.

Now hold on there, mister. The PKI paradigm in which public keys are supposed to be vetted by a centralized trusted third party can be blamed squarely on the cryptographers who invented public key encryption in the first place.

The reason Mozilla and every other user-facing app has this stupid design is a direct consequence of them trusting in cryptographers to give them good advice about security distributed systems design.

(Now granted, we all should have known at the start that cryptographers are the wrong people to go to for secure distributed systems design.)

Anyway, I can't hold silent while you reverse the history and saying that application hackers like the Netscape engineers are the ones to blame when they should have listened to cryptographers. That's backward! They did listen to cryptographers, and that's how we got here!

Since then a lot of distributed systems hackers (myself included) have pushed alternative models instead of the PKI model, and more recently (*after* we distributed systems hackers made significant progress) cryptographers like Prof. Boneh have started working on it too.

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 15:49 UTC (Thu) by Trelane (subscriber, #56877) [Link] (4 responses)

Link to these other models, for those of us non-cryptographer non-distributed people in the audience? Thanks!

Transport-level encryption with Tcpcrypt

Posted Sep 4, 2010 4:52 UTC (Sat) by zooko (guest, #2589) [Link] (3 responses)

Self-certifying filesystem:

ftp://cag.lcs.mit.edu/pub/dm/papers/mazieres:thesis.ps.gz

ssh's model which Peter Gutmann calls the "baby-duck" model or "key continuity"

Web of Trust by Phil Zimmermann

The FreeS/WAN project by John Gilmore, Hugh Daniel et al., known as "Opportunistic Encryption".

The Capability Access Control model:

original:

http://www.cs.washington.edu/homes/levy/capabook/Chapter3...

modern synthesis:

http://erights.org/talks/thesis/index.html

Zooko's Triangle and Pet Names:

http://www.skyhunter.com/marcs/petnames/IntroPetNames.html

ZRTP:

http://en.wikipedia.org/wiki/ZRTP

Tahoe-LAFS:

http://tahoe-lafs.org

(Those last three are self-citations.)

The overall theme here is that the good ideas about robust decentralized security came originally from systems researchers and hackers, not from cryptographers. Cryptographers traditionally focused on elegant mathematical models and (with almost no explicit justification) they settled on the globe-spanning, centralized, hierarchical security model that we all know and love today as "PKI".

Transport-level encryption with Tcpcrypt

Posted Sep 6, 2010 3:20 UTC (Mon) by zooko (guest, #2589) [Link] (2 responses)

I was remiss in omitting Carl Ellison:

Carl Ellison. Establishing Identity Without Certification Authorities. In Proc. Sixth USENIX Security Symposium, pages 6776, Berkeley, 1996. Usenix.

Again, this is a fellow who is basically a systems researcher, not a cryptographer as such (he has no publications in crypto theory to my knowledge), and he was publishing good ideas along these lines back in '96.

Oh, and of course Ron Rivest was doing a very similar thing in '96: http://people.csail.mit.edu/rivest/sdsi10.html

So there's the first example I can come up with of a bona fide cryptographer giving us something more robust and decentralized than the PKI model.

Transport-level encryption with Tcpcrypt

Posted Sep 6, 2010 3:26 UTC (Mon) by zooko (guest, #2589) [Link] (1 responses)

Oh, and I see that Rivest's SDSI 1.0 in '96 cites:

Matt Blaze, Joan Feigenbaum, and Jack Lacy. Decentralized trust management. In Proceedings 1996 IEEE Symposium on Security and Privacy, page (to appear), May 1996.

Also real cryptographers.

But I should emphasize that while SDSI and to a lesser extent PolicyMaker were influential, these were exceptions to the centralized hierarchical PKI model that dominated cryptography, and they were too late. By 1996 the damage had already been done when Netscape engineers baked the PKI model into their socket encryption protocol, SSL.

Transport-level encryption with Tcpcrypt

Posted Sep 6, 2010 3:27 UTC (Mon) by zooko (guest, #2589) [Link]

I wrote "by 1996 the damage had already been done...", but I meant that it had already been done two years earlier, when Netscape invented SSL.

Okay I'm definitely going to stop following-up to myself now. :-)

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 15:56 UTC (Thu) by djao (guest, #4263) [Link]

I do not, did not, and never have faulted the original Netscape engineers. They did the best job that they could at the time. In particular, Netscape predates SSH, and SSH was the first program to demonstrate that crypto is much easier to deploy without a PKI. (SSH is also, incidentally, the only crypto protocol in history successful enough to have driven its corresponding unencrypted alternative to extinction.) I also fully agree that cryptographers are largely at fault for the colossal PKI mistake.

But Firefox was developed well after the rise of SSH, and the particular design decision that I am criticizing, namely the decision to change the warning dialogs for unauthenticated encrypted connections from one mild warning to three consecutive very big scary warnings, was made in Firefox 2.0, released in 2006. The Netscape engineers had valid excuses for their mistakes. The Firefox engineers do not.

Transport-level encryption with Tcpcrypt

Posted Aug 29, 2010 1:54 UTC (Sun) by zooko (guest, #2589) [Link]

Oh hey I see David Mazières is on the Tcpcrypt project. I have to give him props for Self-certifying Filesystem (circa 2000) as being an early part of what I call the "good" tradition.

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 17:58 UTC (Thu) by emk (subscriber, #1128) [Link]

Thank you for your comments about tcpcrypt. I had written it off the first few times I saw it, because who needs crypto connections that "fail open" if a single TCP option gets stripped?

As it turns out, though, tcpcrypt does two very useful things:

1) tcpcrypt provides extremely low-overhead session key creation, more than an order of magnitude faster than SSL.

2) tcpcrypt provides non-secret, unique session identifiers that allow you to build authentication primitives at the application level. Among other things, you can use RSA to sign the session ID (turning tcpcrypt into a much faster SSL replacement) or perform mutual authentication using a client-only password and a corresponding hash on the server.

Essentially, tcpcrypt separates encryption from authentication, and provides the building blocks to do both well.

Even though tcpcrypt looks like junk at first glance, it's a _very_ slick protocol. But the authors really need to revamp their home page so that they stop getting written off as cranks who don't understand why "fail open" is a bad security policy.