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

71–80 of 206 posts

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#71

Post by okasaki »

wackget wrote: post #65

What if you already run a web server which uses port 443? Strange that the readme doesn't mention that scenario because it's extremely common. Presumably you'd choose a different port but then it'd be pretty obvious you're running something if your server has a random HTTPS server exposed on port 444 or whatever.

You can run different hosts on one web server, like company.com goes to localhost:5555 (your app or whatever) and ssh.company.com goes to localhost:8443 (let's say you're running ssh3 on that port)

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#72

Post by gabeio »

georgyo wrote: post #12
out_of_protocol wrote: post #10

If you want SSH via UDP, try mosh. If you have it installed on both client and server side, it just works, re-using auth, sessions etc fron ssh itself and only replacing sending actual session bytes back and forth. Don't break on unstable connections, have way lower latency

Mosh and this project have fairly different goals. Mosh uses regular TCP SSHv2 to authenticate and setup the udp connection. As such your initial connection time is actually slower than just normal v2, and you cannot auth with something like oauth. Mosh is heavily focused on interactive sessions. You could not use mosh for batch programs easily.

> Mosh is heavily focused on interactive sessions. You could not use mosh for batch programs easily.

Correct, the goals are better human interaction with a high delay internet or server. Effectively allowing the client side to guess a bit as to where your input went (it does decently at it). But the key thing that I've loved is even if my client machine goes to sleep and I go to a different building I'm still connected to the server. That is wonderful. Agreed the connection time is slower. Mosh = Mobile shell.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#73

Post by epaulson »

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.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#74

Post by jeroenhd »

nixgeek wrote: post #44
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".

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 protocols to do things they're not designed to support.

I don't really see what changed, though. I guess static keys were dropped to provide forward secrecy, but other than that running your own rogue CA is as possible as it was 20 years ago. Middleboxes lagging behind in support for features like HTTP/3 is probably annoying, but that's because of a lack of implementation more than anything.

You can still use your domain tools/MDM configuration/settings to configure an HTTPS proxy and firewall off the normal ports if you want to MitM your network reliably. If yiur prozy doesnt support http/3, it will happily downgrade your connection to HTTP/1.1 for you. Android's insistence on not actually applying user-installed certificates is a pain for many apps, but other operating systems will happily and silently drop security measures like certificate transparency when they encounter a user-operated MitM CA.

The lack of MitMability comes down to Android being fussy, IoT devices you had no chance of ever controlling needing workarounds, and devices you don't have permissions to manage not being manageable. I really do wish Android would let MDM solutions inject certificates into the system store (though I can see why they don't with the wide range of stalkerware in the wild).

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#75

Post by vore »

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…

I don't see anything about using an X.509 certificate for logging in, just for a client authenticating the remote server. And, even then, TLS has support for mutual authentication so someone with a cheap DigiCert certificate logging into your server is not really a problem if you could configure mTLS on the server side to accept only certificates in a certain chain.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#76

Post by xyst »

wackget wrote: post #65

What if you already run a web server which uses port 443? Strange that the readme doesn't mention that scenario because it's extremely common. Presumably you'd choose a different port but then it'd be pretty obvious you're running something if your server has a random HTTPS server exposed on port 444 or whatever.

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

…

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#77

Post by kdklol »

acdha wrote: post #62
Ayesh wrote: post #46

SSH 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…

They list other advantages in the README such as tying into the web authentication model, which is pretty big for enterprise use as everything moves towards OIDC. If they could eventually use passkeys that’d be really nice.

SSH supports passkeys: https://developers.yubico.com/SSH/#_fido2

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#78

Post by magicalhippo »

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…

> OAuth assumes that both client and service provider can reach identity provider.

You could use client credentials flow with a certificate. Then all you need is to register the public key with the server, much like good old SSH.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#79

Post by idorosen »

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.

`ProxyJump` already exists, so you don’t need to know where netcat resides on the jumphost anymore.

SNI-like metadata might have some adverse security implications, but a fancier ProxyJump with session routing would be nice.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#80

Post by qingcharles »

okasaki wrote: post #71
wackget wrote: post #65

What if you already run a web server which uses port 443? Strange that the readme doesn't mention that scenario because it's extremely common. Presumably you'd choose a different port but then it'd be pretty obvious you're running something if your server has a random HTTPS server exposed on port 444 or whatever.

You can run different hosts on one web server, like company.com goes to localhost:5555 (your app or whatever) and ssh.company.com goes to localhost:8443 (let's say you're running ssh3 on that port)

* depending on your web server/reverse proxy configuration

[for instance, I run Kestrel and it really isn't designed to target more than one site; I do it, but it's like bending that Lego brick to make it fit where it shouldn't go]

Post reply on HN