Hacker News Reader

Comment by ilc | Hacker News Reader

This looks like the worst of all worlds.

You get TCP on both sides of the connection and QUIC in the middle, which will be acting as a single stream protocol, not getting to use all of its advantages.

View on HN

But both TCP connections are to localhost so, you get 64K MTU unlike 1500/9000 over a network connection. Also, blocking / polling will be much quicker locally (in the order of microseconds not milliseconds minimum for over the Internet).

And lastly you can host it on port 443 so it will look similar to a HTTP connection externally.

It's not anywhere near as bad as you conjecture.

It is every bit as bad. QUIC streams could map nicely to the SSH model of discrete channels. Sure, you can run it over tcp/443 and have it look like a normal TLS connection to anything that isn't monitoring the traffic patterns, but it's effectively just adding a TLS pipe which only achieves the use of QUIC's congestion control algorithm and handshake but nothing else. I would love to see an SSH implementation which uses QUIC correctly; this isn't it.

edit: it also has a hardcoded parameter to not validate certs which defeats the whole purpose of it using TLS in the first place... (https://github.com/moul/quicssh/blob/5f5a17c3431a39a8287467d...)

I doubt e.g. OpenSSH would ever implement something like you describe though. They're seemingly very much against anything x509/WebPKI.

You imply OpenSSH is the place to do this work.

Given the protocol changes needed, it may be a new implementation. I actually expect it would be.

I believe section 7 of RFC 9000 would allow for the creation of a handshake protocol which could conform to SSH without the need for including x509.

Thanks for the tip, wasn't aware of this.

MOSH already exists, and it is a proper ssh-like protocol over UDP that takes advantage of the properties of UDP. It's great for use when traveling and being forced to use horrible high latency wireless connections.

MOSH is really a on-purpose "horrible SSH" as far as SSH goes, but it is instead intended to be what you actually need for remote, unstable, unreliable slow connections: a somewhat reponsive experience, a kinda of remote desktop protocol but for terminals, you only send the input and output deltas; you intentionally don't block waiting at any side for precise confirmation of every single byte in or out of a remote terminal.

It’s a bit of a silly hack and it seems pretty stupid to be encrypting things twice. But there’s also a pretty stupid advantage which is that openssh sets pretty small limits on socket buffer sizes whereas quic (hopefully) does not, so if you are rsyncing or scping files over a long distance (and have reasonably modern cpus and crypto libraries) you’ll find things are faster. You could use hpn-ssh but then that’s potentially more configuration to do.

I think this might also come with quic advantages like tolerance for changing ip (eg if one client is mobile) though I think people have other wireguard based solutions they like for that.

The most obvious disadvantage to me is security: sometimes local connections are treated differently by sshd, eg allowed to log in as root.

It's like SCTP only worse.

SCTP has better header overhead than HTTP/2+QUIC

Plus there is like 11 different variants of QUIC out there.

Reply on news.ycombinator.com