← Back to context

Comment by mixedbit

12 years ago

As the author notes, for such hack to have any chances of working reliably a third party is needed to synchronize connection setup. But a third party with a public IP could also forward an encrypted TCP connection between two machines that do not have public IP addresses. Such approach does not require any hacks and gives a strong guarantee that the third party can not snoop the connection.

The only thing that the third party learns is that there is a connection, but the proposes solution also has this drawback.

Yes, but your approach requires a lot of bandwidth on the 3rd party.

But a 3rd party doing nothing except helping with synchronization uses barely any bandwidth and someone could easily host it for free on some server that is not otherwise fully used, simply as a service to the public.

I have to disagree on that - can you really trust encrpytion? Are you sure? On the other hand, why depend on (supposedly) strong encryption against 3rd party if you can just avoid passing the message through their hands altogether?

This seems like a great stuff if it works. Unbeleviable I was able to avoid knowing about it until now. Kudos to top poster, great info.

  • If you don't want to trust encryption you are screwed. Unencrypted TCP doesn't give any snooping protection, it also doesn't give any way to enforce and validate that a route that packets traverse is trusted.

    • My point was different. If there is no need for someone to see the (encrypted, if you like) traffic, then it would be safer not to send it through their server at all. It is difficult to decrypt the stream you don't have access to.