Live data from Hacker News

SSH3: Faster and rich secure shell using HTTP/3

github.com

261–270 of 276 posts

Re: SSH3: Faster and rich secure shell using HTTP/3

#261
post #138

Earlier quoted context omitted.

I see your point, but I think you're missing the broader picture here. Web protocols are not just used because they are there, but because the stack is very elegantly layered and extensible, well understood and tested, and offer strong security guarantees. It's not like encryption hasn't been tacked onto HTTP retroactively, but at least that happened using proper staples instead of a bunch of duct tape and hope as wi…

> the stack is very elegantly layered and extensible I have to disagree pretty strongly on this one. Case in point: WebSockets. That protocol switch is "nifty" but breaks fundamental assumptions about HTTP and to this day causes headaches in some types of server deployments.

[dead]

Re: SSH3: Faster and rich secure shell using HTTP/3

#262

Earlier quoted context omitted.

mosh is still included in the Fedora repository (and probably others, I didn't check) major distros are maintained, and they wouldn't be shipping it if it had bugs and/or was being used as an exploit

Each distro package maintainer is always welcome to maintain patches in their forks for as long as they like, but the quality and life of each will be per distro as these efforts are coordinated with an upstream.

i was pointing out that saying the package is unmaintained is likely to be false. to add my comment to your comment, i would imagine that distros are not keeping important patches like security to themselves.

i.e. this package being somehow abandoned and therefore should not be trusted is likely to be false

Re: SSH3: Faster and rich secure shell using HTTP/3

#263

Earlier quoted context omitted.

Each distro package maintainer is always welcome to maintain patches in their forks for as long as they like, but the quality and life of each will be per distro as these efforts are coordinated with an upstream.

i was pointing out that saying the package is unmaintained is likely to be false. to add my comment to your comment, i would imagine that distros are not keeping important patches like security to themselves. i.e. this package being somehow abandoned and therefore should not be trusted is likely to be false

[deleted]

Re: SSH3: Faster and rich secure shell using HTTP/3

#264

Earlier quoted context omitted.

Each distro package maintainer is always welcome to maintain patches in their forks for as long as they like, but the quality and life of each will be per distro as these efforts are coordinated with an upstream.

i was pointing out that saying the package is unmaintained is likely to be false. to add my comment to your comment, i would imagine that distros are not keeping important patches like security to themselves. i.e. this package being somehow abandoned and therefore should not be trusted is likely to be false

The above has all been in reference to the mosh project, not any individual distro packaging. E.g. if you "brew install mosh" on macOS right now you will indeed get an official-but 3-year-old-release without any patches Fedora (or others) may have applied since https://formulae.brew.sh/api/formula/mosh.json. The same is true if one goes to the project's GitHub to download it manually.

> i would imagine that distros are not keeping important patches like security to themselves.

I'm not 100% sure what "keeping to themselves" means in context of GPL 3 code, but one can verify with the mosh GitHub link to see the upstream project has not had a single commit on any branch for the last 2.5 years.

The project is dead, it's up to your trust+verification of any specific downstream packaging as to how much of a problem that is for the binary you may be using. Some maintainers may not have noticed/cared enough yet, some maintainers may only carry security fixes of known CVEs, some maintainers may be managing a full fork. The average reader probably wants to note that for their specific binary rather than note Fedora still packages a downstream version (which may be completely different).

Re: SSH3: Faster and rich secure shell using HTTP/3

#265
post #2

I was skeptical of the claim that it's faster than traditional SSH, but the README specifies that it is faster at establishing a connection, and that active connections are the same speed. That makes a lot of sense and seems like a reasonable claim to make.

openssh is generally not praised for its speed but its security track record. i hope this thing doesnt sacrefice it for a little more speed in something that generally doesn't require more speed..

Re: SSH3: Faster and rich secure shell using HTTP/3

#266
post #231

Earlier quoted context omitted.

Everything you've said is true for web authentication, and almost nothing of what you said is true for HTTP authentication. This is HTTP authentication: https://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html https://github.com/francoismichel/ssh3/blob/5b4b242db02a5cfb... https://www.iana.org/assignments/http-authschemes/http-auths... Note the OAuth listed there is OAuth 1.0. Support for "native" HTTP authenticatio…

No, that isn’t true. All parts of the OAuth dance are just means to end up with a Bearer token in the Authorization header, and I don’t see why the process of obtaining this token couldn’t involve a web browser? Plus—HTTP auth isn’t limited to Basic, Digest, and Bearer schemes. There’s nothing stopping an implementation from adding a new scheme if necessary, and add it to the IANA registry.

It's quite clear that we're using the same words with different definitions. I don't have an 'official' reference/definition for them. Unless you do we'll have to call it a day here and accept the fact that other people use the same names for different things.

Re: SSH3: Faster and rich secure shell using HTTP/3

#267
post #231

Earlier quoted context omitted.

No, that isn’t true. All parts of the OAuth dance are just means to end up with a Bearer token in the Authorization header, and I don’t see why the process of obtaining this token couldn’t involve a web browser? Plus—HTTP auth isn’t limited to Basic, Digest, and Bearer schemes. There’s nothing stopping an implementation from adding a new scheme if necessary, and add it to the IANA registry.

It's quite clear that we're using the same words with different definitions. I don't have an 'official' reference/definition for them. Unless you do we'll have to call it a day here and accept the fact that other people use the same names for different things.

Fair enough. I do think however that we both care about standards, protocols, and quality engineering, albeit with different opinions. That's got to be worth something.

Re: SSH3: Faster and rich secure shell using HTTP/3

#268
post #215

Earlier quoted context omitted.

Why isn't this the default behavior to use this UDS? How to enable this?

> Why isn't this the default behavior to use this UDS? Because it’s insecure to use on multiuser systems, as it presents an opportunistic access to remote systems for root users on your local system: root can read and write into your UDS too. As a user, you have to explicitly opt into this scenario if you deem it acceptable.

I don't think that's the reason. root can theoretically do everything and not much is protected from root. root can su to your account and make a new SSH connection. root can replace the ssh command with one that copies their public key before opening a shell.

Re: SSH3: Faster and rich secure shell using HTTP/3

#270

Earlier quoted context omitted.

That is my main objection as well, but perhaps it's time to also revisit TOFU. Remember when Github had to rotate its host keys? It was hitting the news far and wide, and likely broke pretty close to every single CI pipeline out there. There was little heads up because it's the friggin host key, you have to act now . It's also pretty annoying when you have to deal with that in your own infra. Even if you have a prett…

Some day very soon everyone is going to get some uncomfortable lived experience showing just how dangerous and damaging putting all of our communications eggs in a handful of easily controlled corporate baskets is. It's now calvinball out there and distributed, not centralized, solutions are going to be required to route around the damage. The people who lived through it last time made the internet. And now that they…

I agree that we do need more decentralization, but for the decentralized infrastructure to scale, we need better building blocks. Internet is a much, much bigger place now. TOFU doesn't scale.
Post reply on HN