draft-ietf-masque-connect-ip VS ABPTTS

Soonish there's going to be a standardized way to do this, via CONNECT-IP:

https://github.com/ietf-wg-masque/draft-ietf-masque-connect-...

I had a similar experience when I was testing A Black Path Toward the Sun[1], specifically using SSH and SCP over the HTTP/HTTPS tunnel, as well as when I was writing unreleased SSH pen testing tools at two different organizations.

I found that SSH is more complicated than I would have expected at a low level, and far more barebones than I would have expected at a higher level. It's incredibly sensitive to certain types of small delay for its packets. On the other hand, the actual terminal traffic is basically just a pair of streams. For an interactive SSH session, there's no useful concept of "send a command and wait for it to finish on the remote system", because the remote system is just piping the output of the shell back to the SSH client. You can hack in something like generating a random tag and appending "; echo '---complete:{random_tag}---'" to every command and assuming the command is complete when that string appears, but it's not built in, and of course every SSH server OS can have different syntax requirements, so now the client has to detect and handle each of those.

It makes sense given that SSH is a general-purpose protocol that's supposed to work for just about any CLI, so I was surprised for the same reason as the author of the article. Their issue makes sense in context as well - SSH has to support server shells like the Windows command prompt that don't even have the concept of an array of arguments at a low level, just the command string.

[1] https://github.com/nccgroup/ABPTTS

I wrote this for pen testing purposes, but it worked so well that I've used it to get around public WiFi limitations like the author of TFA:

https://github.com/nccgroup/ABPTTS

(Still need to port it to Python 3 someday)

I was very surprised at how finicky some TCP software is. SSH/SCP in particular was not at all tolerant of seemingly minor delays that every other client/server combination ignored. My gold standard for testing became "can you perform an arbitrary number of tunneling layers, where the layers alternate between SSH and the HTTP tunnel, and still behave as reliably as a direct connection?"