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

51–60 of 206 posts

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#51

Post by arp242 »

tjoff wrote: post #45
arp242 wrote: post #35

Earlier quoted context omitted.

Anyone should treat any new crypto project which hasn't seen a lot of testing from others as such, no matter who it came from. Even if this was some sort of proposal of the OpenSSH people. The project is associated with the Louvain university; I would rate the risk of outright malicious tomfoolery to be quite low.

Well, if it was a proposal of the OpenSSH people you'd bet it would get a lot of testing from others real quick. But to even consider calling it SSH3 is really quite silly, first impression doesn't exactly inspire confidence.

"Confidence" in what? Ability to name things? It's making a mountain out of a molehill. It's certainly not an issue with the crypto or code.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#52

Post by password4321 »

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".

My understanding is limited, but HTTP/3 boils down roughly to HTTP/2+QUIC.

Major cloud providers are still shaking issues out of HTTP/2 like "Rapid Reset" 2 months ago, the nesting and layers open gaps and new edge cases as naive implementations were clearly not yet battle hardened even against old attack families like amplification/resource exhaustion.

https://news.ycombinator.com/item?id=37830987 The novel HTTP/2 'Rapid Reset' DDoS attack

https://news.ycombinator.com/item?id=37837043 HAProxy is not affected by the HTTP/2 Rapid Reset Attack

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#53

Post by tssva »

PrimeMcFly wrote: post #42
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

Why would you tunnel WireGuard over SSH?

Perhaps reread the comment. It presents info for running Wireguard or SSH over websockets and not running Wireguard over ssh.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#54

Post by mkesper »

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…

Ssh hostkeys offer no solution for first connect to ephemeral hosts.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#55

Post by password4321 »

PrimeMcFly wrote: post #42
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

Why would you tunnel WireGuard over SSH?

Although not relevant to my post above, tunneling WireGuard over SSH sounds like an interesting challenge...

Because WireGuard and SSH are at different layers of the network stack, it might be necessary (though slow) to bridge two WireGuard networks through a single TCP socket port-forwarded by SSH. I'm actually curious now what tools would best be used to accomplish this, how much effort would be needed to configure things, and how badly performance would suffer when faced with normal internet traffic congestion.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#56

Post by password4321 »

v3ss0n wrote: post #18
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

eternal is better than mosh https://eternalterminal.dev/

I would probably choose between the two based mostly on their security track record, but I haven't needed the comparison yet.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#57

Post by jeroenhd »

mkesper wrote: post #54
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…

Ssh hostkeys offer no solution for first connect to ephemeral hosts.

If hosts are configured with SSH certificates as part or their setup, you can definitely skip TOFU and determine trust on the first connection. That won't work for the "I need to connect to a random IP address" scenario, but any cloud server exposing SSH can be configured with a certificate signed by a company/personal SSH certificate authority.

You could configure something delightfully atrocious like https://github.com/mjg59/ssh_pki but I think for most use cases where you connect to loads of SSH servers, host keys and certificate authorities will work just fine. We can do with an ACME-like protocol for distributing these certificates, though.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#58

Post by tjoff »

arp242 wrote: post #51
tjoff wrote: post #45

Earlier quoted context omitted.

Well, if it was a proposal of the OpenSSH people you'd bet it would get a lot of testing from others real quick. But to even consider calling it SSH3 is really quite silly, first impression doesn't exactly inspire confidence.

"Confidence" in what? Ability to name things? It's making a mountain out of a molehill. It's certainly not an issue with the crypto or code.

Judgement? Having attention for detail? Being in touch with the community?

Just a bad look / first impression.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#60

Post by chungy »

v3ss0n wrote: post #18
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

eternal is better than mosh https://eternalterminal.dev/

"ET uses TCP"

Right there, Eternal doesn't even try to cover the same use case as Mosh. It might be an alternative, same way regular SSH is an alternative, but there's no way it can be "better"

Post reply on HN