> It's never a good idea.

I disagree with that profoundly:

I read the article. Yes, TCP over TCP include unnecessary performance-harming features in certain circumstances, because you have two unrelated collision avoidance systems running at the same time. Even so, in many scenarios TCP over TCP is an excellent idea: it can provide you with many benefits, in practical terms works great, and has no readily-available alternative which is better.

It doesn't solve the problem as theoretically neatly as possible, and carries some cruft. But hypothetical me at a starbucks about to open an ssh tunnel to a trusted connection, hypothetical you telling me that that's never a good idea. Okay then, what should I do instead?

TCP over UDP.

So sitting at starbucks with my laptop -- what do i do? I am not aware of an option to have SSH run over UDP, although I do know that some VPNs allow you to use UDP instead of TCP.

Unless there is a relatively simple way of getting an encrypted tunnel for my HTTP traffic using tools like ssh and netcat and other things I'm likely to already have installed, I disagree with the notion that it's never a good idea.

When you are running a SOCKS proxy through ssh, you are not doing TCP over TCP. We are talking about things like OpenVPN which can do TCP over TCP, but that is generally a bad idea. It's default mode is TCP over UDP, as it should be.

> When you are running a SOCKS proxy through ssh, you are not doing TCP over TCP

Are you sure? SSH uses TCP, and encapsulates the web traffic which also uses TCP... in what way is that not TCP over TCP?

Here, read this: https://github.com/apenwarr/sshuttle#theory-of-operation

"TCP-over-TCP" and "TCP carried on something that happen to be TCP" turn out to be two very different things.

Thank you for the link :)

Ok, so how can we fix this?

Perhaps we could disable retransmission on either the upper or lower layer?