Live data from Hacker News

SSH3: SSHv2 using HTTP/3 and QUIC

github.com

201–206 of 206 posts

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#201
post #200

Earlier quoted context omitted.

* Deploying DNSSEC is obviously not trivial, as doing so has taken some of the largest companies on the Internet fully off the Internet for multiple hours, within the last year, so much so that it has become a running joke when companies have prolonged outages to suggest that DNSSEC is the culprit. * There are still resolvers that can't handle Ed25519 * Being able to use Ed25519 was never the ops problem with getting…

My favorite thing about normal ssh keys is the way it does not come with the obnoxious assumption that if I don’t rent my cert from some rent-seeker, it is super scary and invalid. And yet it gives me both identity verification and encryption. I get the reasons we got there for HTTPS due to how unsophisticated the least experienced users are, but I am glad this idea here won’t catch on in real life, because we don’t…

TLS certificates are free. Unsigned certificates are super scary and invalid. SSH and TLS do not work with the same threat model; first-contacts with SSH servers are comparatively rare (if they aren't, you should be worried about your SSH threat model, too).

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#202

Earlier quoted context omitted.

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

Why not have 1:1 relationship between QUIC connection IDs and open SSH sessions?

Profiling ... of SSH sessions at QUIC level, that's why we shouldn't do 1:1 mapping between QUIC session and SSH session.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#203

Earlier quoted context omitted.

> 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?

QUIC is indeed impressive and one of the developments that excite me.

I meant, I wish there were more application-layer protocols (like a new IRC, NNTP, rather than say Matrix or ActivityPub which is just JSON shunting over HTTP), the rest of the OSI stack gives us plenty of choice already :)

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#204
post #147

This seems bad? - SSH3 is a bad name: this isn't a successor to SSHv2 and will only cause confusion - The authors don't seem to understand that SSHv2 predates all of their chosen technologies, and provides "robust and time-tested mechanisms" they claim to be adding - How is "hiding your server behind a secret link" a feature? This is, at best, security through obscurity, which can be layered on any network protocol (…

I'd agree with you. The readme calls out "Significantly faster session establishment" and goes into greater detail later on. > Establishing a new session with SSHv2 can take 5 to 7 network round-trip times, which can easily be noticed by the user. SSH3 only needs 3 round-trip times. The keystroke latency in a running session is unchanged. I, for one, can say that sometimes session establishment can take a little whil…

ssh is fairly often used non-interactively.

so if you want to execute uptime on a remote machine, the session will only be open for a few ms, and those extra RTT are a problem. (Yes, I know about openssh controlmaster...)

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#205
post #200

Earlier quoted context omitted.

My favorite thing about normal ssh keys is the way it does not come with the obnoxious assumption that if I don’t rent my cert from some rent-seeker, it is super scary and invalid. And yet it gives me both identity verification and encryption. I get the reasons we got there for HTTPS due to how unsophisticated the least experienced users are, but I am glad this idea here won’t catch on in real life, because we don’t…

TLS certificates are free. Unsigned certificates are super scary and invalid. SSH and TLS do not work with the same threat model; first-contacts with SSH servers are comparatively rare (if they aren't, you should be worried about your SSH threat model, too).

Certificates aren't "free." They cost time at minimum, and complexity (you're forced to add a bunch of tooling to renew them) to satisfy the arbitrary requirements based around the fact that somehow their bits get old. The "free" ones think they get old in 90 days, and Apple decided for the whole world that I think one or two years is the absolute limit and anything longer-lasting is also "invalid."

A cert signed by your own CA isn't scary. You can trust and install your own CA, and unless you're an idiot and publish your private key you're not harming your security profile one bit, but like I said, I understand how we got here because if it were easy and not presented as scary, naive users would be tricked into installing new CAs every day. It's just annoying how it has (in practice) imposed this external prerequisite to use TLS encryption itself, which I think is pretty obviously the reason it took like 15 years for SSL to become ubiquitous.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#206

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

I'm surprised no one's opened an issue on their repo and that no brigade has opined with lots of comments and emojis...

There is now an open issue: https://github.com/francoismichel/ssh3/issues/79
Post reply on HN