Is there a security audit for this code?
SSH3: SSHv2 using HTTP/3 and QUIC
101–110 of 206 posts
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#102Why no support for mTLS?
Certificate based authentication for clients is a must.
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#103Meh. OpenBSD does it fine. If not, Mosh works great on flakey connections.
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#104I 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 these paths. Later advances include; disabling encryption after authentication to transport non-sensitive bulk data, modifying the AES-CTR cipher to use multiple CPU cores, more detailed connection logging, and peak throughput values in the scp progress bar. More information can be found on HPN-SSH page on the PSC website.
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#105Earlier 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.
More like incomplete state machine for HTtP/3-QUIc
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#106Earlier quoted context omitted.
The standards bodies don’t seem to buy the “bad things” argument and appear resolute on making it harder to MITM traffic on the wire and attempting to force IDS/IPS to all be run on the client. Is there a 5-10 year future where you just can’t do this as a middlebox?
Protocols supported MITM with correct configurations and it led to complete ossification of said protocols because middleboxes suck at following standards. It seems that at the time these features were dropped, most middleboxes have ignored features like exporting keys or configuring static RSA keys and went for CA-MitM attacks instead. You should expect these tools to break if they're actively trying to subvert prot…
Second paragraph: "most middleboxes ..."
It is the "others".
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#107Earlier quoted context omitted.
Front load service with nginx server or load balancer… nginx exposed on 443: if route is /web then route to web service on port 1234 if route is /ssh3-secret-string -> route to ssh3 server service on port 1265 if route doesn’t exist then 404 …
Can nginx proxy-pass encrypted data now? I tried this before and failed pretty hard, had to use HAproxy at the time and pass based on the hostname in the SNI header. Was still pretty unreliable. If so, I assume the encryption on the SSH is handled separately from the http headers.
https://nginx.org/en/docs/quic.html
Since 1.25.0
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#108SSH 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…
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 going to start extracting advertising value from their "customers".
How about we save the CDNs for the serious stuff and just run our SSH servers and low traffic HTTP sites ourselves?
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#109I 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…
> Who does new protocols these days? My business brain understands why, but my engineer’s heart laments.
QUIC is damn good though! Its minimal header has a very tiny overhead, and the protocol gives us so much for free. What’s to lament? The userspace impl?
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#110This is cool, but calling that SSH3 is not appropriate. It's an independent project, not a new version of the SSH protocol. Sure, it's "SSH3" and not "SSHv3". Still, introducing a confusion with something that could be an official protocol is not nice.