Throwaway's maxim: no new protocol works without HTTP
SSH3: SSHv2 using HTTP/3 and QUIC
131–140 of 206 posts
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#132Earlier quoted context omitted.
What does “official” mean? The OpenSSH team? IETF? Anyway, SSH authentication is extremely inflexible, and the protocol is not particularly performant, especially on large bandwidth-delay links. Moving to HTTP3 seems like an excellent idea if it’s implemented well. (Although… we really need a way to do TLS/QUIC to an endpoint without a domain name.)
The RFCs for SSH2 were all published by IETF, so I would definitely expect IETF to be involved in a project that claims to be "SSH3". If some random person started an OS project and called it "Windows 12", people would rightfully be confused.
The IETF SSH working group was disbanded in 2006. You will be waiting a long time if you expect anything else to come from there by magic.
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#133I 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.
SSH certificates (I encourage using them!) are not x509, absolutely incompatible.
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#134Earlier quoted context omitted.
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 neede…
> unless you need to saturate a 100G link with one connection
Maybe not 100gig, but I routinely transfer data over 10gig links. I used to be a heavy user of HPN, but Gentoo pretty much stopped supporting it because the multithreading is supposedly broken.
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#135This is a really cool project and a great idea that seems to be decently implemented.
Calling it “SSH3”, however, is misleading at best, and misrepresents what the project is. Please consider choosing a better name.
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#136This is not related to OpenSSH or the RFCs for SSH3 published by IETF. It is just someone's random project.
I think it was a lot of hubris to call this ssh3, as if it were to be picked officially
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#137Why 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?
Yes. The attack surface would be much smaller.
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#138SSH over QUIC would be nice. I don't see any advantage of layering HTTP/3 here. It adds more friction, and the only advantage it brings is being able to "hide" the SSH server over a URL path. I guess x.509 certificates would be fine, but SSH hostkeys, SSHFP or TOFU is enough and far more secure (because it implicitly pins the server public key). It's a relatively new project from the looks of it, so I'd definitely no…
In the 90s it was commonplace to design a new protocol on top of TCP/IP. These days, all the tooling and infrastructure is for HTTP. Designing a new protocol, you'd be starting from scratch; HTTP is much, much easier to build an application on top of.
I doubt QUIC is easier than TCP to build on. But it's much easier to get your new protocol through firewalls and other middleware when using port 443 than trying to introduce a new port (or worse: a new protocol number)
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#139Earlier quoted context omitted.
It sure would be nice to be able to easily throw up a CDN like Cloudflare in front of my ssh server with no client side special sauce required. I didn't see it stated in the documentation, it this feels like something that might work for that setup.
Why are people obsessed with implanting CloudFlare right in the middle of everything they do? There is absolutely nobody that needs DDoS for their SSH server. I get that CloudFlare has been a well behaved netizen so far, but let's be real, it won't last forever. It never does. Eventually the shareholders start turning the screws and CloudFlare is going to succumb to the same pressures every company does and they're g…
Absolutely nothing to do with DDoS in my case. I want censorship regimes to have to break large portions of the internet for their citizens to stop even the most simple leak vector. Let them block Cloudflare, Akamai, and Cloudfront.
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#140Earlier quoted context omitted.
How intentionally vague.
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.
The owning organization or user should already have full admin on all endpoints.
Malicious apps and attackers should not.