Live data from Hacker News

SSH3: SSHv2 using HTTP/3 and QUIC

github.com

21–30 of 206 posts

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#21
post #5
post #2

Is this wayland all over again? We do three or four new things well, and everybody is supposed to just stop doing everything else ? Is this "a secure shell" (as in, somebody's personal spin on the topic) or like a new "official" direction? The readme isn't clear on these aspects.

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

> (Although… we really need a way to do TLS/QUIC to an endpoint without a domain name.)

Generate self-signed cert, let the client TOFU. And skip the HTTP part. Just like SSH. There's no reason to do things like a browser.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#22
post #17

This is pretty neat, definitely better to move to UDP, so that we can have the proper response to unauthorized contact--no response. QUIC is fine as is though, no need to layer HTTP3 on top of it.

Isn’t it necessary for oauth?

It might be easier to integrate but you’ve got a custom server and client in this case so it should be possible to do both without HTTP being involved for the server/client layer without an HTTP server? At least I think that’s right but it’s been a long long while since I wrote OAUTH code.

Seems like it’s primarily to implement the masking feature to pretend to be a normal HTTP server hosted on a port until the shared secret URL is knocked.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

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

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.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#26
post #16
post #5

Earlier 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.)

Yeah, right now for auth, if you want to use e.g. OIDC I think the best you can do is to essentially shove everything in the square hole using very short-lived SSH certificates and OOB auth flow; e.g. "open this browser link to get a cert for the next 15 minutes/24 hours." So, you're basically treating short-lived certs like session tokens, more or less. I got this working with my own homegrown SSH CA infrastructure…

Cloudflare offers this as a service. It’s obviously a second class citizen (it’s intensely buggy, has low availability, doesn’t work especially well even on a good day, has incoherent configuration, and no support whatsoever).

On the other hand, all Cloudflare configuration seems incoherent, and it gets more so over time. I was recently highly entertained when I tried to access one of the Zero Trust [0] pages. The UI cheerfully informed me that only the new UI could configure Zero Trust, and it redirected me to a new domain that was IIRC “one.dash.cloudflare.com”. You can’t make this up — maybe it’s called One Trust internally? The new panel looked quite a lot like the old one except that the Zero Trust pages worked.

Well, “worked”. None of the Zero Trust config makes any sense.

[0] Is there any logic at all to what lives under the Zero Trust umbrella?

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#27
post #17

This is pretty neat, definitely better to move to UDP, so that we can have the proper response to unauthorized contact--no response. QUIC is fine as is though, no need to layer HTTP3 on top of it.

Isn’t it necessary for oauth?

The client and server need to talk http to the authorization server, that doesn't mean they need to talk http to each other.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#28
post #4
post #2

Is this wayland all over again? We do three or four new things well, and everybody is supposed to just stop doing everything else ? Is this "a secure shell" (as in, somebody's personal spin on the topic) or like a new "official" direction? The readme isn't clear on these aspects.

It's just someone's project. As far as I can tell it's unrelated to IETF, if that's what you mean by "official". In any case it's presumptuous for the author to call this "SSH3".

it's probably just ssh + http/3
Post reply on HN