9 ms·
Tcpcrypt
- drdaeman 16y agoWhy reinvent the wheel when we already have IPsec?
- wmf 16y agoBasically, IPSec requires configuration and tcpcrypt doesn't. There's more in the Usenix Security paper: "A big challenge to IPSec is that it breaks middleboxes that require access to the transport layer. Given the increasing prevalence of NAT in particular, this excludes a large portion of the population from using IPSec. Tcpcrypt, by contrast, operates at the transport layer and so avoids these problems. Another challenge for IPSec is that it is hard to create a notion of a “session” in a connection-less environment (the network layer)."
- deleted 16y ago[deleted]
- theBobMcCormick 16y agoHave you configured many IPSec connections? It's a fricking pain in the rear. Nothing is every compatible "out of the box" and there are so many knobs to tweak and configure. Which is probably part of why everyone just uses SSL anymore, even for VPN's.
- api 16y ago"Why introduce this HTML/HTTP thing when we have Gopher? Don't re-invent the wheel!" Re-inventing the wheel is good. It's the only way we'll ever get better wheels.
- Groxx 16y agoIndeed; for all we know, our wheels are oblong if not triangular. Without reinventing the wheel sometimes, you'd never come up with stuff like this: http://en.wikipedia.org/wiki/Mecanum_wheel http://en.wikipedia.org/wiki/Mecanum_wheel
- arethuza 16y agoThere were potential licensing issues with Gopher - by the time the creators of Gopher realized that this had scared off a lot of people and that they had shot themselves in the foot everyone had settled on using the Web - which had no such licensing issues.
- ycweb 16y agoIPSec doesn't support authentication well. For example, if you have a shared secret like a web cookie, how would you use this to authenticate one endpoint of an IPSec connection? It's hard, because the granularity of IPSec session keys is not the same as the granularity of tcp connections. Tcpcrypt, by contrast, makes it easy to do this--just hash the session ID together with the other authentication data.
- tptacek 16y agoThis is basically useless as-is for things like banking security, because the security of SSL is premised on inherent resistence to "active" (MITM) attackers.
- wmf 16y agoThe stuff that matters has already been secured. It looks like tcpcrypt is designed to encrypt everything else.
- tlrobinson 16y agoCorrection: the stuff that really matters (like banks) has already been secured. The other stuff still matters a lot, especially when users often share passwords between secure and non-secure websites. Or when companies offer a single sign-on service without mandatory encryption (I'm looking at you Facebook and Twitter) This would be better than nothing (if it were ubiquitous), but I'd rather everything use SSL.
- avar 16y ago> I'd rather everything use SSL That's not going to happen as long as browsers treat the continuum of security like this: BEST: Oh nice, a SSL connection with a CA signed cert COOL: A normal HTTP connnection OMGWTFBBQ: ZOMG SOMEONE HAS A SELF SIGNED SSL CERT THE SKY IS FALLING LET'S PRESENT 10 CLICK THROUGH DIALOGS BEFORE THE USER CAN OPEN THE BLODDY SITE As opposed to: BEST: Oh nice, a SSL connection with a CA signed cert COOL: Oh nice, a SSL connection, but no CA signing, treat like HTTP UI-wise COOL: A normal HTTP connection, show the user the traffic isn't encrypted.
- tptacek 16y agoThe reason your browser goes "ZOMG" when it sees a self-signed certificate is that there is no way to distinguish the "'avar made himself a handy self-signed certificate" case from the "someone has substituted a random certificate into my Bank of America login". Think about it. Long story short: don't hold your breath waiting for browsers to chill out about self-signed certs.
- peterwwillis 16y agoi really don't like any aspect of this at all. so, my encryption is not guartanteed, i don't know if it's working, it doesn't cover all network traffic, and isn't shipped by default with any operating systems. i'm never going to use this and i'm never going to recommend it to anyone for any purpose. (sorry, i drank a jug of haterade this morning)
- wmf 16y agoObviously the goal is to be built in to the OS. Flipping your objection around, you could say that with tcpcrypt more of your traffic will be encrypted than is now; it's no worse than the status quo.
- peterwwillis 16y agowhat's the point of "more encryption than you have now" if it can be disabled by mitm (this includes the 'wireless networks' cited as a good reason to use it) and you don't even know if it's working? if i want to use encryption, i want to know its encrypted. there is no point otherwise. an example: i'm using an unencrypted network and plaintext protocol. if there's no attacker on the network, my data is "safe." if there is an attacker, my data is effectively compromised. if i'm using this solution around the same network connection and there is no attacker on the network, my data is safe. if there is an attacker, they'll see it's this lame attempt at encryption, disable it through mitm, and my data is effectively compromised. in a real life setting i can't depend on this to secure my data. however, ssh, openvpn, ipsec and other solutions provide assured encryption (unless you screw up the configuration). you don't even need a CA with ssh or openvpn - copy your keys or certs by a usb key once and you immediately have a strong defense against mitm. i'd love to see sites provide a secure encryption alternative to SSL which allows for out-of-band transfer of secure keys and 1-to-1 authentication to prevent a nation's clandestine operations from peeking at my traffic. that probably won't happen though. in the meantime i protect my last-mile access with a secured tunnel; i just pray SSL is strong enough to not be attacked at a hop from my tunnel endpoint to the site.
- avar 16y ago
- thorax 16y agoI really like when people acknowledge the difference between passive and active attackers. I really, really want there to be more passive protection by default without requiring every computer/node/server to have a trusted certificate. I really would like to see a better handling for this in the case of https as well. I want a way to see a mechanism that a site can offer to provide passive communication protection but where the site does not guarantee its identity, thus meaning it's possible for a MitM attack if you're willing to accept that risk.
- avar 16y agoJust because you don't have signed certificates you can still protect against MitM attacks. Your browser just has to remember what the certificate was the first time, and alert you it if changes. Sound familiar? It should, ssh(1) does this by default.
- tptacek 16y agoThe first time you connect to any SSH server, the connection can be hijacked. People used to do this for sport at Usenix. Why would anyone accept this weakness with their bank account? My mom barely understands the lock icon.
- avar 16y agoWhat sort of person goes to a conference like Usenix and connects to an external server for the first time? I've been to a dozen conferences, all of whom I've used ssh at, and I've never connected to an external box for the first time.
- tptacek 16y agoI can't imagine what possible point you could be trying to make. Am I making this up or not? I doubt I am, but who cares? The issue with first-connection security in SSH is a fact, not an opinion.
- sweis 16y agoThe performance comparison to SSL is not really fair, since tcpcrypt does not offer security against passive attackers.
- Gonsalu 16y agoYou haven't read the site, have you? > If, however, a Tcpcrypt connection is successful and any attackers that exist are passive, then Tcpcrypt guarantees privacy.
- sweis 16y agoGood catch. I meant to say that tcpcrypt is vulnerable to active attacks, rather than passive. The point is that it is not a useful comparison to say that tcpcrypt is 36x faster than SSL, when it offers a weaker level of security.
- ycweb 16y agoIf you use X.509 server authentication with 2,048-bit RSA keys, tcpcrypt offers about a 25x speed-up over SSL for equivalent security. (Actually slightly better, since tcpcrypt offers forward secrecy while, in the benchmark, SSL does not.) The key optimization is batch signing, where a single RSA signature can authenticate a bunch of connections at once. There are graphs showing this in the paper and talk slides.
- caf 16y agoHow serious can they be about ubiquitous encryption, if they can't even be bothered enabling HTTPS on their site?
- thwarted 16y agoSounds like the ubiquitous opportunistic encryption that was a goal of FreeS/WAN. http://www.freeswan.org/ http://www.freeswan.org/ 2004/03/01 FreeS/WAN is no longer in active development. Although we've created a solid IPsec implentation widely used to construct Virtual Private Networks, the project's major goal, ubiquitous Opportunistic Encryption, is unlikely to be reached given its current level of community support.
- wmf 16y agoI looked into FreeS/WAN in the early days (1997?) and they made two architectural mistakes: You had to put some special records in your reverse DNS zone (which most people can't do) and it introduced a 30-second delay the first time you contacted each non-FreeS/WAN IP address (which made Web browsing completely unbearable). These misfeatures protected against MITM attacks, but they also ensured that FreeS/WAN would never be deployed.
- X-Istence 16y agoI can't find this anywhere, and I looked in the source code as well, what is the license for this? The Linux kernel module is GPL, however there is no license on the rest of the source code. I have no idea if I can use any part of this and port it over to FreeBSD as a kernel module for example.
- cperciva 16y agoport it over to FreeBSD as a kernel module for example. Just for the record: As long as I'm the FreeBSD security officer, this is not going to be in the FreeBSD source tree. (I can't stop you from building and distributing a kernel yourself, of course.)
- mey 16y agoThank you. My thoughts were something along the lines of, who do I trust more, the well vetted kernel tcp stack, or this unknown modification to my tcp stack in the name of security. It's hard enough making sure the normal stack doesn't have any issues (and, in my understanding, why Windows/OSX/Solaris have taken parts of the BSD TCP stack)
- X-Istence 16y agoOh no, it was merely an example. I would rather prefer my code not to be in the FreeBSD source tree, I don't think it is good enough yet.
- yason 16y agoThere's not much point in encryption unless you know who you're talking with.
- fexl 16y agoMark Handley makes that very point on page 3 of his paper here (sorry about the PDF): http://www.cs.ucl.ac.uk/staff/m.handley/slides/tcpcrypt.pdf http://www.cs.ucl.ac.uk/staff/m.handley/slides/tcpcrypt.pdf "Encryption without authentication is like meeting a stranger in a dark alley." However, on subsequent pages he writes about ways to do authentication over tcpcrypt using the session ID, including signing it with an SSL certificate or using HMAC with shared passwords. As he says, "many different authentication schemes [are] enabled by the session ID concept." The tcpcrypt.org site itself says "Tcpcrypt abstracts away authentication, allowing any mechanism to be used, whether PKI, passwords, or something else." Perhaps these mechanisms can help us gradually avoid the problems with both central authority schemes and key continuity schemes, but I haven't thought about it or researched it enough yet to know. I have a love-hate relationship with SSL, and when I hear about hijacked CAs and even see root certs in the name the various governments in Firefox, I get the chills. But I can appreciate SSL's strengths. On the other hand, I really like SSH's key continuity, but I also appreciate some of its difficulties on the web. As an experiment, I recently deleted all CAs from Firefox and started approving web sites by exception one by one. Does anyone here have a good handle on how tcpcrypt's "abstracted" authentication schemes might thread that needle, simultaneously avoiding the difficulties and pitfalls in both camps?
- nik61 16y agoThey don't look very trustworthy to me.
- ycweb 16y agoA lot of the SSL vs. SSH discussion on here is just demonstrating the fact that there is no one-size-fits-all solution for authentication. The point of tcpcrypt is to get the best security possible under any setting, so it can be used with both SSL- and SSH-like settings. See slide 5 of the talk on the web site: http://tcpcrypt.org/tcpcrypt-slides.pdf http://tcpcrypt.org/tcpcrypt-slides.pdf One thing I haven't seen discussed yet is that fact that come October, the EKE patent is going to expire, which means that all of a sudden it's going to be legal to do strong authentication using only human-chosen passwords. Strong password authentication is desperately needed, because people overwhelmingly both chose week passwords and don't think carefully about where they send those passwords. Somewhat independent of tcpcrypt, section 4.3 of the tcpcrypt Usenix paper suggests a nice and simple secure password-authentication protocol. Deploying such a protocol would make a huge difference, except... what are you authenticating? You can prove possession of a password, but this doesn't actually protect you unless the authentication is tied to session traffic, and you are authenticating communication endpoints. SSL, IPSec, and even SSH don't provide adequate hooks for doing this (though SSH would be easier to retrofit than the other two). Tcpcrypt does. So the way to view this is that in the absence of authentication, tcpcrypt will be vulnerable to MITM. But as soon as you go to authenticate yourself to a server (by typing a password or verifying a certificate), the authentication will fail, and the MITM will no longer be able to deceive the user.