Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH3: SSHv2 using HTTP/3 and QUIC

github.com

Post reply on HN
Print view View original

121–130 of 206 posts

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#121

Post by egberts1 »

insanitybit wrote: post #70
lajamerr wrote: post #25

Earlier quoted context omitted.

I assume he means with the encrypted metadata in HTTP/3 / QUIC that it makes it harder as a security admin to "peek" at what is going on in the network. In my opinion its short sighted, because if we care about security, then we should care about user security and privacy as well. Because if the security admin has the ability to packet inspect stuff, so does a potential malicious app.

Odd, surely SSHv2 already suffers from inability to inspect on the wire.

From the Github:

SSH3 is a complete revisit of the SSH protocol, mapping its semantics on top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for secure channel establishment and the HTTP Authorization mechanisms for user authentication.

So, it has nothing to do with SSH2; more about HTTP/3-QUIC security theater: hostname is still being sent over TLS/1.3 negotiation.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#123

Post by xorcist »

egberts1 wrote: post #8

Not going there with anything HTTP/3. Disclaimer: I write network packet parsers for XNS/IPS/IDS for a living, to look for "bad things".

Not sure why this is downvoted. HTTP3/QUIC is a lot more complex to implement than SSH.

SSL is a very well studied standard, but it is clearly a committee product with lots of features built on enterprise standards like X.509, and SSH is made by a few protocol engineers with a razor sharp use case.

It is easy to see why someone who audits parsers for a living would be much more comfortable with SSH as compared to a something over HTTP/SSL/QUIC.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#124

Post by neild »

vlovich123 wrote: post #20
alphazard wrote: post #7

This is pretty neat, definitely better to move to UDP, so that we can have the proper response to unauthorized contact--no response. QUIC is fine as is though, no need to layer HTTP3 on top of it.

The reason they’re using HTTP is to allow for hiding the SSH server so that it pretends to be a dummy HTTP server that responds to 404 on all requests unless you know the special random URL that hosts the SSH capabilities. It’s a neat idea but overkill when you’re not using that capability (didn’t dig into the code so maybe it is bypassed if you don’t ask for a secret URL). It does make me hesitant as I don’t know ho…

HTTP/3 is almost indistinguishable from any other protocol running over QUIC, and QUIC itself is almost indistinguishable from random noise in UDP packets. If you want to masquerade as HTTP/3 traffic, just using UDP on port 443 will generally be sufficient.

(Only “almost” indistinguishable, because it’s possible to decrypt the first packets of the client’s handshake and examine the ALPN parameters used to negotiate an application protocol. And QUIC may be further distinguishable from other UDP traffic through statistical analysis of packet sizes and response latencies, as well as the few unencrypted header bits.)

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#125

Post by egberts1 »

ironhaven wrote: post #100

Why is there http/3 in the middle? SSH over QUIC makes a lot of sense and was something I thought about before. The SSH protocol is designed to multiplex many “channels” over an encrypted tcp socket. Over each channel you can run things like a shell or SFTP. It would need some engineering but you could keep the same SSH features but replace the multiplexing channels over tcp with QUIC channels over udp. Where does HT…

Do you want to maintain a state machine for each QUIC-SSH session 1-N pairing? Or worse, M-N pairing?

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#126

Post by IAmLiterallyAB »

password4321 wrote: post #23

If you want to tunnel UDP (WireGuard) or TCP (SSH) over the WebSocket protocol, check out https://github.com/erebe/wstunnel

Looks neat. Have you looked into using the new WebTransport protocol?

https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ov... https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ht...

Still early stages, but it looks promising! Notably it supports multiple streams and unreliable datagrams since it goes over QUIC

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#127

Post by frutiger »

nixgeek wrote: post #39
adontz wrote: post #34

I believe security models for HTTP and SSH are pretty different. HTTP is usually public and anonymous, SSH is usually private and authenticated. While QUIC is definitely a great technology for HTTP use case, I'm not so sure about SSH. Not saying it's not, just it's something to reason about. For example x509 seems to be a disadvantage to me. I do not want anyone with a cheap DigiCert certificate be able to log in to…

“cheap DigiCert certificate” is already possible with misconfiguration of SSH’s TrustedUserCAKeys and without any out of tree patches. https://smallstep.com/blog/use-ssh-certificates/

SSH Certs are not related to x509 PKI certs. SSH certs are created with ssh-keygen and is the result of one key signing another. The public portion of the signing key (ie. the “cert”) needs to be distributed separately.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#128

Post by sargun »

adontz wrote: post #34

I believe security models for HTTP and SSH are pretty different. HTTP is usually public and anonymous, SSH is usually private and authenticated. While QUIC is definitely a great technology for HTTP use case, I'm not so sure about SSH. Not saying it's not, just it's something to reason about. For example x509 seems to be a disadvantage to me. I do not want anyone with a cheap DigiCert certificate be able to log in to…

You can already use certificates to login via SSH. Usually you setup your own certificate authority and sign your own certs because they need special attributes.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#129

Post by tux2bsd »

epaulson wrote: post #73

I know this isn't an actual v3 of the SSH protocol, but if there ever is a version 3 of SSH, it really needs some kind of (encrypted) SNI or at least a standardized metadata block that can be passed to any jumphost without having the know the specifics of the ProxyCommand on that middlebox.

[dead]

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#130

Post by formerly_proven »

pulpfictional wrote: post #104
r1ch wrote: post #97

I feel like they're missing some benchmarks here, show off the benefit that QUIC brings! OpenSSH's fixed window size significantly bottlenecks throughput on long fat links. I'd love to see ssh+rsync running at 2+ gbps.

There is also: https://www.psc.edu/hpn-ssh-home/ > HPN-SSH is a series of modifications to OpenSSH, the predominant implementation of the ssh protocol. It was originally developed to address performance issues when using ssh on high speed long distance networks (also known as Long Fat Networks: LFNs). By taking advantage of automatically optimized receive buffers HPN-SSH could improve performance dramatically on thes…

SSH started out with a maximum window size of 128K, which was bumped to 2M in the mid-2000s. It'd be entirely reasonable to bump this to the 64M to 128M range; it's not a fixed buffer allocated for each channel, and the peers explicitly manage the window size, so there really shouldn't be any compatibility issues. This would already solve most of these issues, the more complicated parts of HPN-SSH aren't really needed, and things like multithreaded crypto are entirely unnecessary with modern CPUs unless you need to saturate a 100G link with one connection.
Post reply on HN