[HN Gopher] Quicssh: SSH over QUIC
___________________________________________________________________
Quicssh: SSH over QUIC
Author : rhn_mk1
Score : 135 points
Date : 2023-04-27 15:06 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| exabrial wrote:
| Alright, so we're double-encrypting traffic? Or is it not
| encrypting the SSH tunnel? Or did QUIC finally come around to
| having a Sane not-encrypted mode?
| tialaramex wrote:
| It's double encrypting the traffic. SSH is completely unaware
| that there's a tunnel moving this data over the Internet,
| that's being done by the "Quicssh" proxy in their diagram which
| is software at both ends doing QUIC.
|
| If you were building this into SSH itself you'd have to do a
| bunch of work to arrange to do SSH-style KEX instead of the TLS
| KEX that QUIC would normally use, and then do SSH-style proof-
| of-identity for the server and client, rather than the
| equivalent TLS mechanisms. Once you have a shared secret,
| there's no reason QUIC streams aren't a drop-in replacement for
| the SSH encrypted TCP streams, thus no double encryption
| needed. It's definitely possible to design this, and maybe it's
| even worth somebody's time to do it, although my instinct is
| that won't be OpenSSH people.
|
| It would make no sense for the IETF to standardise a "not-
| encrypted mode" for QUIC given BCP 188 "Pervasive Monitoring Is
| An Attack".
| ilc wrote:
| 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.
| tankenmate wrote:
| 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.
| mvkg wrote:
| 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/5f5a17c3431a39
| a8287467d...)
| bcrl wrote:
| 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.
| Avamander wrote:
| I doubt e.g. OpenSSH would ever implement something like
| you describe though. They're seemingly very much against
| anything x509/WebPKI.
| ilc wrote:
| 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.
| mvkg wrote:
| 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.
| rwmj wrote:
| Lost opportunity to call this _(Sean Connery 's voice)_
| "quicsshilver" ...
|
| Does this map SSH channels into QUIC channels? They're in hand-
| waving terms similar in concept. Edit: I'm going to guess not
| since it's a proxy.
| aidenn0 wrote:
| What time did Sean Connery show up to Wimbledon?
|
| Tennish
| mayli wrote:
| How about mosh over quic?
| ilc wrote:
| Very possible if one of the tmux replacements wants to do it.
|
| But I can see not wanting to deal with the problems this
| creates. :)
| Avamander wrote:
| If one could run this alongside with Wireguard and H/3 on the
| same port, that would be very interesting against analysis.
| aztecrabbit wrote:
| port hopping support would be awesome, like hysteria do
| ggm wrote:
| Surely the protocol of choice over QUIC (assuming the endpoint
| which terminates the QUIC binding is itself the host being logged
| into) would be .. telnet?
|
| why double-encrypt?
| NelsonMinar wrote:
| What's the use case for this?
| bheadmaster wrote:
| I think the lack of head of line blocking could be useful for
| SSH session multiplexing when using it as an ad hoc VPN.
| remram wrote:
| It looks like the multiplexed SSH channels are in a single
| QUIC stream, so it doesn't help with head-of-line blocking?
| Honestly not sure what it does from reading the README.
| pfoof wrote:
| Apparently SSH over UDP with much less code and configuration
| compared to Mosh.
| trollied wrote:
| Last time I installed Mosh (on Ubuntu) I just installed the
| package & did not need to do any configuration. It just
| worked.
| loxias wrote:
| > Apparently SSH over UDP with much less code and
| configuration compared to Mosh.
|
| What configuration? I'm trying to assume best intent but have
| you ever used mosh? It has zero configuration. That's the
| whole point.
| Rucadi wrote:
| Since browsers implement QUIC, probably you can run SSH over
| QUIC on a web browser, making it possible to run ssh client on
| unconventional platforms that have a browser.
| remram wrote:
| Browser apps can't use raw QUIC, they can use HTTP (including
| HTTP3).
|
| Just like browser apps can't use TCP.
| rebolek wrote:
| Unconventional platforms usually get SSH years before browser
| supporting QUIC.
| srj wrote:
| Since quic sessions can be tracked by the connection id rather
| than the srcip/dstip/sport/dport/ipproto 5-tuple you could
| switch networks and have your session survive. Not sure if this
| implementation achieves that or not though.
| touisteur wrote:
| Wait, can one checkpoint/restore QUIC connections easily
| these days? Which implementations/libraries allow that?
| nnntriplesec wrote:
| Would this make ssh more robust against intermittent
| connectivity? like https://mosh.org/
|
| without needing to run mosh on the server
| ori_b wrote:
| Mosh is closer to tmux than to ssh.
| talideon wrote:
| Any similarity with tmux is purely because it's
| connectionless. It's mostly certainly more like ssh than it
| is like tmux. Both are remote shell protocols, while tmux is
| simply a terminal multiplexer.
| [deleted]
| loxias wrote:
| Mosh is not at all like ssh, tries hard to avoid
| duplicating ssh functionality, and this is by design.
|
| If it were like ssh the authors would have had to then
| handle security/authentication and all that jazz perfectly.
| It was written to "stand on the shoulders" of ssh, except
| handle terminal emulation and UTF-8 correctly. By using
| ssh, you don't have to trust "some new thing" as long as
| you trust ssh.
|
| It's not even a shell protocol if you think about it!
|
| Mosh bidirectionally synchronizes the state between the
| terminal window on the client and the virtual terminal on
| the server. It runs at a frame rate, which results in not
| filling intermediate network queues, which is where the low
| latency comes from. :)
| hackernudes wrote:
| Mosh is a terminal emulator itself and sends the diff of
| the output from the server to the client. Ssh just passes
| the terminal data through. I think that is why mosh is like
| tmux, because tmux is also a terminal emulator.
| FrancoisBosun wrote:
| Mosh has latency-hiding mechanisms. I used mosh for a bit on
| while riding a bus. Latency-hiding helped quite a bit to keep
| the UI responsive.
| cl3misch wrote:
| Do you mean UI as in X forwarding? I thought this wasn't
| possible, which kept me from using mosh so far.
| tempay wrote:
| They mean UI as in for command lines, like vim/emacs/shells
| LinuxBender wrote:
| Probably only if this implements a similar roaming concept as
| mosh by using a nonce or something along that line vs. ssh
| session keys that are mapped to an IP. Mosh was designed by MIT
| folks not just for high latency but also mobile networks which
| can change IP and lose connectivity frequently. Perhaps the
| code author is here on HN?
| loxias wrote:
| Mosh was designed for a great number of things, including
| what you mentioned.
|
| To me, mosh is "careful and impressively pedantically correct
| UTF-8 terminal emulator" + "careful and impressively
| pedantically correct state synchronization protocol". :)
| Avamander wrote:
| It doesn't have to be this piece of software implementing MP-
| UDP for roaming to work though. Nevertheless I doubt it has
| such functionality right now.
| zokier wrote:
| Is there actually anything ssh-specific here? Seems like quic
| support is something that could fit something like socat pretty
| well?
| remram wrote:
| I think so, I tried to proxy a raw TCP server and it didn't
| work.
| anderspitman wrote:
| It's SSH-specific only on the server side, right? The client
| side looks like a normal TCP tunnel (-o ProxyCommand)
___________________________________________________________________
(page generated 2023-04-27 23:00 UTC)