3 ms·

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 eav

by avar 16y ago

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.

tptacek 16y ago
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.
- avar 16y ago
  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.
  - tptacek 16y ago
    If you and a friend exchange certificates, TLS protects you from most governments, including US domestic law enforcement. If you and a friend set it up, tcpcrypt protects you from people who don't know to MITM TCP connections.
    - avar 16y ago
      Yes, and if we meet and exchange one-time pads we'll be even more secure. However neither that nor TLS "work out of the box: require no configuration, [and] no changes to applications".
      - tptacek 16y ago
        No, it's going to be about as hard for (say) the FBI to break TLS as it is for them to break an OTP; either way, it isn't happening. Can you say that for tcpcrypt? Of course not. I don't know what your second sentence even means. I didn't do anything to configure TLS. What did you have to do?
        avar 16y ago
        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.
        caf 16y ago
        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.
        avar 16y ago
        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.
        16y ago

by avar 16y ago

tptacek 16y ago

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.

avar 16y ago
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.
- tptacek 16y ago
  If you and a friend exchange certificates, TLS protects you from most governments, including US domestic law enforcement. If you and a friend set it up, tcpcrypt protects you from people who don't know to MITM TCP connections.
  - avar 16y ago
    Yes, and if we meet and exchange one-time pads we'll be even more secure. However neither that nor TLS "work out of the box: require no configuration, [and] no changes to applications".
    - tptacek 16y ago
      No, it's going to be about as hard for (say) the FBI to break TLS as it is for them to break an OTP; either way, it isn't happening. Can you say that for tcpcrypt? Of course not. I don't know what your second sentence even means. I didn't do anything to configure TLS. What did you have to do?
      - avar 16y ago
        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.
        caf 16y ago
        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.
        avar 16y ago
        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.
        16y ago