Tcpcrypt

http://tcpcrypt.org/

by rnicholson • 16 years ago

92 70 16 years ago

tcpcrypt.org

drdaeman2• 16 years ago

Why reinvent the wheel when we already have IPsec?

wmf4• 16 years ago

Basically, 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)."

theBobMcCormick• 16 years ago

Have 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• 16 years 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• 16 years ago

Indeed; 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

arethuza• 16 years ago

There 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.

ycweb3• 16 years ago

IPSec 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.

tptacek13• 16 years ago

This is basically useless as-is for things like banking security, because the security of SSL is premised on inherent resistence to "active" (MITM) attackers.

wmf4• 16 years ago

The stuff that matters has already been secured. It looks like tcpcrypt is designed to encrypt everything else.

tlrobinson• 16 years ago

Correction: 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.

peterwwillis4• 16 years ago

i 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)

wmf4• 16 years ago

Obviously 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.

peterwwillis4• 16 years ago

what'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.

caf4• 16 years ago

Agreed - it's just a way of wasting CPU cycles on a false sense of security. Anyone who is going to trouble of sniffing your traffic is going to go the extra yard to disable your "tcpcrypt".

Especially when an automated MITM tool to do so becomes available.

thorax2• 16 years ago

I 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.

avar12• 16 years ago

Just 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.

tptacek13• 16 years ago

The 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.

peterwwillis4• 16 years ago

considering about every third time i visit a high traffic site with ssl i get a new cert pushed to me, i don't think ssh is a good comparison.

also, perhaps i skipped over this, but tcpcrypt seems like a level of encryption well below application, thus if we did get a hijacker trying to 'change the self signed cert' after an initial connection (or just dropping the encryption) we wouldn't know, unlike ssl/browsers. am i incorrect?

tptacek13• 16 years ago

I really dislike it when people distinguish between passive and active attackers. Modern attackers are active by default; they proxy connections from phishing sites or attack the DNS.

Moreover, even in the '90s, when people actually did stuff like attaching solsniff to the SprintNet backbone, being passive equated to being active, because the passive vantage point gives you TCP sequence numbers, which is all you need to hijack a connection from across the Internet.

Your browser already does the thing you're asking for with regards to SSL. Just click through the warnings, which are telling you "encryption without authentication offers very little security, but if you're sure, go ahead and pretend it's doing something for you".

alister• 16 years ago

> Modern attackers are active by default; they proxy connections from phishing sites or attack the DNS.

The biggest attackers by far are the NSA and similar agencies -- that's passive attack -- scanning your emails, VOIP calls, browsing habits, etc.

sweis2• 16 years ago

The performance comparison to SSL is not really fair, since tcpcrypt does not offer security against passive attackers.

Gonsalu• 16 years ago

You 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.

sweis2• 16 years ago

Good 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.

caf4• 16 years ago

How serious can they be about ubiquitous encryption, if they can't even be bothered enabling HTTPS on their site?

thwarted• 16 years ago

Sounds like the ubiquitous opportunistic encryption that was a goal of FreeS/WAN.

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.

wmf4• 16 years ago

I 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-Istence2• 16 years ago

I 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• 16 years ago

port 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• 16 years ago

Thank 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-Istence2• 16 years ago

Oh 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• 16 years ago

There's not much point in encryption unless you know who you're talking with.

fexl• 16 years ago

Mark 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

"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• 16 years ago

They don't look very trustworthy to me.

ycweb3• 16 years ago

A 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

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.

Tcpcrypt

Related Stories