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

161–170 of 206 posts

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#161

Post by insanitybit »

gsu2 wrote: 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 (…

> This is, at best, security through obscurity, which can be layered on any network protocol (e.g. https://en.wikipedia.org/wiki/Port_knocking); this implies that the authors don't have much of a security background...?

This isn't security through obscurity. The url would be a secret. This is a form of capability security, where to connect to the server you must be able to name the server.

A URL with a secret is, in my opinion, far more sane than port knocking, and will be much more efficient as well.

> (i.e. https://security.stackexchange.com/questions/148292/why-is-o...)

Your link doesn't support your statement at all. No one there answers "here's why oid is less secure", they say the opposite.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#162

Post by commandersaki »

gsu2 wrote: 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 (…

SSH over HTTP/(url) is a killer feature if you're working on hostile networks that block SSH and go even as far as to try and detect the protocol over the wire.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#163

Post by idlephysicist »

gsu2 wrote: 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 while but not to the extent that it would be a selling point (so to speak) for me to adopt SSH3.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#164

Post by eichin »

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.

That already has a (brutal) solution now - sslh https://www.rutschle.net/tech/sslh/README.html - the current version is more sophisticated, but it was originally just a perl script that would send the connection to sshd or the https web server, based on regex matching on an initial string (and I probably timing out and going to sshd if it didn't see one? Something like that, I haven't dug out the old code to check.)

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#165

Post by [deleted] »

gsu2 wrote: 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 (…

[deleted]

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#166

Post by overstay8930 »

Ayesh wrote: post #82
mkesper wrote: post #54

Earlier quoted context omitted.

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

Strict SSHFP can theoretically solve it [1], assuming it's used in the first place and has DNSSEC. I personally use it for all servers I manage purely because I like the additional security, but it not at all common and DNSSEC isn't all that perfect either. [1] https://aye.sh/blog/sshfp-verification

It's crazy that SSHFP hasn't taken off, I don't think a single person on earth has ever verified a host key before attempting to connect, and deploying DNSSEC is trivial now that you can use ECC and ED25519.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#168

Post by tengwar2 »

unilynx wrote: post #138
bitwize wrote: post #115

Earlier quoted context omitted.

In the 90s it was commonplace to design a new protocol on top of TCP/IP. These days, all the tooling and infrastructure is for HTTP. Designing a new protocol, you'd be starting from scratch; HTTP is much, much easier to build an application on top of.

I doubt QUIC is easier than TCP to build on. But it's much easier to get your new protocol through firewalls and other middleware when using port 443 than trying to introduce a new port (or worse: a new protocol number)

Which sounds like more of a disadvantage if you are running a firewall.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#169

Post by qudat »

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.

SNI is absolutely needed. Over at https://pico.sh we have to request an IP for each ssh server even though from a resource perspective we really only need 1 VM. It increases the complexity of our deployments and overall makes us want to figure out how to merge all of our SSH apps into one.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#170

Post by ranting-moth »

ryandvm wrote: post #108
InvaderFizz wrote: post #98

Earlier quoted context omitted.

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

I'm pretty sure even if CF went rouge you'd be able to keep your SSH connections ad free for a low $1.99/month subscription.
Post reply on HN