The point is to upgrade the connections that are unencrypted now to use encryption. A MitM can only insert his own data into your dialog, he can't passively eavesdrop on an existing encrypted connection.
This is the waxed-mustache damsel-tied-up-on-the-railroad-tracks notion of Internet attackers, who, getting a sudden bee in their bonnet to torment 'avar from Hacker News, leap upon his connections only to find that, drat!, 'avar had enabled tcpcrypt and all his connections are safeguarded.
The real Internet attackers owned up your ISP 2 years ago, and on the real Internet you originate hundreds of new connections across that owned-up Internet every minute. The security negotiation on any "old" connection is irrelevant. All that matters is the security of each new connection. If they're safe, the protocol works. If they're not, the protocol is broken.
Nobody said anything about "old" connections in this thread. wmf mentioned how encrypting everything (even if you don't know who's at the other end) is "no worse than the status quo".
Protocols that don't use encryption now aren't broken, and they could be slightly improved by transparently using encryption, because at least you'd deter passive sniffing.
I'm citing the design aims of Tcpcrypt, from their website.
Not everything uses HTTP, a bunch of things like Torrent, IRC etc. use unencrypted protocols by default, and you have to explicitly add support to each one for encryption. Either by adding SSL support to the programs themselves, or by setting up a tunnel.
That's not the same as using opportunistic encryption that can happen at the kernel level. You could also do that with SSL to achieve the same aims, but the point is that it's opportunistic and happens without further userspace configuration.
Can you really imagine someone going to all the trouble to sniff your traffic - and then giving up at that point because you have tcpcrypt enabled, given that it's trivial for them to perform a downgrade attack?
So it ends up being opportunistic encryption, that's enabled when you don't need it and disabled when you do. It's just a security blanket.
Tcpcrypt is aimed at passive attacks. Not everyone who has the power to listen in and perform a passive attack can modify the traffic and execute an active attack.
Even when you can do an active attack it's not trivial in practice. The user my get suspicious if they've previously been able to initiate a tcpcrypt connection but can't do so now, and if you do this on a big scale (e.g. government sanctioned sniffing at an ISP) you'll probably be found out.
can you give me an example of a connection that can be passively sniffed and not injected into? unless you have some wacky physical media which has no Tx, if you can see their traffic at the very least you send spoofed packets to the destination or source. if you're on the source's LAN you just spoof DNS and/or ARP for either the default gateway or the destination. if you're on the destination's LAN you can spoof the destination or do packet injection. if you're in between either LAN you can arguably do any damn thing you like, depending on network topology and routes. but i don't see a case where i could see the traffic and not do something to either downgrade the connection, hijack it or mitm it.
so they're risking their data on an uncertain possibility that a user might catch on that i've been downgrading their sessions and stealing everything? once you explain this to a user, do you think they'll really trust it?
