3 ms·

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 4y ago
  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".
  • JoshTriplett 4y ago
    > 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. Or modify SSH to do TLS key exchange and TLS-based proof of identity.
  • mkj 4y ago
    The real win from quic might come from mapping ssh channels to quic streams (are they called that?). Then you could have many forwarded tcp streams internally (for a socks proxy etc) but wouldn't have to deal with SSH channel windowing slowing things down.