I’d sort of rather have the opposite: http over ssh. There’d be key pinning, multi streams, and many more cool things
Ah, you can already do this with tunneling. It just doesn't make any sense.
SSH3: Faster and rich secure shell using HTTP/3
221–230 of 276 posts
Re: SSH3: Faster and rich secure shell using HTTP/3
#222Earlier quoted context omitted.
It is not faster in this sense. However, an SSH connection can have multiple substreams, especially for port forwarding. Over a single classical connection, this can lead to head-of-line blocking, where an issue in one stream slows everything down. QUIC/HTTP3 protocol can solve this.
Fun fact: SSH also supports multiple streams. It's called multiplexing.
Multiple streams at the application level, which can be head-of-line blocked due to all being multiplexed on the same transport layer connection.
The former kind of multiplexing addresses functionality, the latter performance.
Re: SSH3: Faster and rich secure shell using HTTP/3
#223I was skeptical of the claim that it's faster than traditional SSH, but the README specifies that it is faster at establishing a connection, and that active connections are the same speed. That makes a lot of sense and seems like a reasonable claim to make.
Although, dollars-to-donuts my bet is that this tool/protocol is much faster than SSH over high-latency links, simply by virtue of using UDP. Not waiting for ack's before sending more data might be a significant boost for things like scp'ing large files from part of the world to the another.
That's not really a common TCP problem. Only when there's something severely weird going on in the return path (e.g. an extremely asymmetric and/or congested return path connection dropping ACKs while the forward path has enough capacity) does the ACK mechanism limit TCP.
Also, HTTP/3 must obviously also be using some kind of acknowledgements, since for fairness reasons alone it must be implementing some congestion control mechanism, and I can't think of one that gets by entirely without positive acknowledgements.
It could well be more efficient than TCP's default "ack every other segment", though. (This helps in the type of connection mentioned above; as far as I know, some DOCSIS modems do this via a mechanism called "ack compression", since TCP is generally tolerant of losing some ACKs.)
In a sense, the win of QUIC/HTTP/3 in this sense isn’t that it’s not TCP (it actually provides all the components of TCP per stream!); it’s rather that the application layer can “provide its own TCP”, which might well be more modern than the operating system’s.
Re: SSH3: Faster and rich secure shell using HTTP/3
#224Earlier quoted context omitted.
Although, dollars-to-donuts my bet is that this tool/protocol is much faster than SSH over high-latency links, simply by virtue of using UDP. Not waiting for ack's before sending more data might be a significant boost for things like scp'ing large files from part of the world to the another.
SSH has low throughput on high latency links, but not because it uses TCP. It is because SSH hardcodes a too-small maximum window size in its protocol, in addition to the one of TCP. This SSH window size limit is per ssh "stream", so it could be overcome by many parallel streams, but most programs do not make use of that (scp, rsync, piping data through the ssh command), so they are much slower than plain TCP as meas…
You're mixing application layer multiplexing and transport layer multiplexing.
If you use the former without the latter, you'll inevitably have head-of-line blocking issues if your connection is bandwidth or receiver limited.
Of course not every SSH user uses protocol multiplexing, many do, as it can avoid repeated and relatively expensive (terms of CPU, performance, and logging volume) handshakes.
Re: SSH3: Faster and rich secure shell using HTTP/3
#225Earlier quoted context omitted.
Although, dollars-to-donuts my bet is that this tool/protocol is much faster than SSH over high-latency links, simply by virtue of using UDP. Not waiting for ack's before sending more data might be a significant boost for things like scp'ing large files from part of the world to the another.
Not really that relevant - anybody regularly using SSH over high latency links is using SSH+mosh already anyway.
If you believe that, you clearly haven't had to work with mosh in a heavily firewalled environment.
Filtering inbound UDP on one side is usually enough to break mosh, in my experience. Maybe they use better NAT traversal strategies since I last checked, but there's usually no workaround if at least one network admin involved actively blocks it.
Re: SSH3: Faster and rich secure shell using HTTP/3
#226Earlier quoted context omitted.
Yeah we got those good old network ppl or their corporate (don't knows much about tech) overlord to thank for that. If you ever using wifi in the airport or even some hotel with work suite unit around the world, you will notice that Apple Mail can't send or receive emails. It is probably some company wide policy to first block port 25 (that is even the case with some hosting providers) all in the name of fighting SPA…
Port 25 is insecure and unencrypted; EU doesn't even need ChatControl to hoover up that data, and you'd better believe anything going through an airport wifi router unencrypted is being hoovered by someone no matter what jurisdiction you're in. Apple mail prefers 587 for secure SMTP and 993 for secure IMAP. People were (wisely) blocking port 25 twenty years ago.
The main problem with port 25 isn't that it's unencrypted, but rather that it's mixing two two concerns: (Often unauthenticated) server-to-server mail forwarding, and (hopefully always authenticated, these days) client-to-server mail submission.
A network admin can reasonably want to have the users of their network not run mail servers on it (as that gets IPs flagged very quickly if they end up sending or forwarding spam), while still allowing mail submission to their servers.
Re: SSH3: Faster and rich secure shell using HTTP/3
#227I don't know why it makes me a little sad that every application layer protocol is being absorbed into http.
Yeah we got those good old network ppl or their corporate (don't knows much about tech) overlord to thank for that. If you ever using wifi in the airport or even some hotel with work suite unit around the world, you will notice that Apple Mail can't send or receive emails. It is probably some company wide policy to first block port 25 (that is even the case with some hosting providers) all in the name of fighting SPA…
Blocking outbound port 25 is completely reasonable, just like blocking inbound port 80 or 443 would be (if inbound connections even were an option, which they aren't in most networks, at least for IPv4).
Blocking ports 587, 993, 995 etc. is indeed silly.
Re: SSH3: Faster and rich secure shell using HTTP/3
#228> Establishing a new session with SSHv2 can take 5 to 7 network round-trip times, which can easily be noticed by the user. SSH3 only needs 3 round-trip times. The keystroke latency in a running session is unchanged. Bummer. From a user perspective, I don't see the appeal. Connection setup time has never been an annoyance for me. SSH is battle-tested. This feels risky to trust, even whenever they end up declaring it p…
Yes, and those that have fought in these battles know its limitations. Head-of-line blocking when using multiplexing is definitely one of them. This is a very reasonable incremental improvement.
Importantly, it does not seem to switch out any security mechanisms and is both an implementation and a specification draft, which means that OpenSSH could eventually pick it up too so that people don't have to trust a different implementing party.
Re: SSH3: Faster and rich secure shell using HTTP/3
#229how complex is this to understand for auditors? i fear of the ever increasing complexity of protocols which are security-relevant...
Re: SSH3: Faster and rich secure shell using HTTP/3
#230Earlier quoted context omitted.
Mosh uses UDP in addition to optimistic updates, so there is an actual latency improvement.
HTTP/3 also rides on UDP, so the effect should be comparable.
> SSH3 only needs 3 round-trip times. The keystroke latency in a running session is unchanged.
If implemented with latency in mind, yes. After a quick look at the code, it seems they are buffering data on both sides with hardcoded buffer sizes at 1500 (TCP packet size) or 30Kb, which could be negating any latency improvements.