Concerns about security statements and naming

[ei-grad]

As an interested security enthusiast analyzing SSH3, I wanted to raise some questions about certain security assertions made in the documentation, as well as use of the SSH3 name/branding before formal standardization:

In particular:

• Statements definitively calling SSH3 "safe" or claiming "strong security" seem premature for prototype software without extensive external cryptanalysis or review over longer time periods.

• Use of the "SSH3" name and branding could be seen as presumptuous before going through an IETF standardization process and achieving consensus in the SSH community.

To contribute constructively, I think it would be beneficial to:

• Have more cautious security messaging in the README reflecting SSH3's current experimental state. This can encourage assistance improving its responsible development. #59

• Use a more tentative naming convention prior to standardization. #60

I opened this issue not as criticism but as constructive feedback from a security advocate hoping to help SSH3 progress and evolve responsibly. By discussing areas for improvement, my aim is to respectfully facilitate community involvement advancing SSH3 in a credible, ethical way over time. Please let me know if any part of this feedback could be clarified further!

[francoismichel]

Working on it all together in the PR referenced in this issue. :-)

[mholt]

I am not super familiar with SSH specification. I was just wondering if you could show me where the SSH standard is defined as version 2? I see the 5 RFCs but haven't turned up much in searching for "version".

Anyway, what about describing this project as being experimental or in beta, with a note that it hasn't been standardized as of yet?

[francoismichel]

It is not especially easy to find, but there is the following text in RFC4253, which explicitly defines it as version 2.0:

Since the protocol being defined in this set of documents is version 2.0, the 'protoversion' MUST be "2.0".

I am all in to say that it is still experimental, that should appear quite upfront once we merge #59. :-) We'll should add that it has not been standardized as well.

[mholt]

Oh weird, now Firefox's "find in page" is working (I already tried it on that document but got no results on any of the SSH RFCs). Anyway, now I see it, thank you. :)

I feel like this is a good candidate for a V3 even though it only upgrades the transport and authentication documents, the actual SSH connection is the same AFAIK.

[grobe0ba]

On the theme of potentially misleading security statements, the README.md contains the "Your SSH3 public server can be hidden" section. This is called "security through obscurity."

To quote NIST (NIST SP 800-123 Section 2.4): "System security should not depend on the secrecy of the implementation or its components." In this case, the use of a "secret" URL is directly analogous to running an actual SSH daemon on a different port; it can still be found, it can still be attacked. Including this in any documentation, let alone the first documentation people will see, is an egregious act of stupidity, practically to the point of malfeasance in any security-related software.

This is quickly followed by the sentence "Attackers and crawlers on the Internet can therefore not detect the presence of your SSH3 server." This is absolutely false. They have already connected to the server; it's right there in front of them. OS and network service fingerprinting has been around for a very long time. Congratulations, now people know there is a service here, and is using some variety of secret URL. Brute force is impractical, but most certainly not impossible. Not to mention the general idiocy that abounds; people are going to use things like "/secret-url". This also completely discounts the possibility of programmer error allowing a bypass; there are millions of those out there. Have you ever heard of the MITRE Common Vulnerabilities and Exposures reporting system? Feel free to see how common this event is.

That's as far in the README.md as I can get; it's clear that security is not actually a focus of this project. I could see this being an early high-school project, but since this is apparently the project of a PhD student and a professor, both of whom should absolutely know better than this, I can only assume this is intentional malfeasance at this point.

I highly recommend to anyone who sees this comment (before it's presumably moderated out of existence) to stick to proven technologies, like the OpenSSH project (which this project is also apparently trying to ride the coattails of, despite being completely unrelated in any way, shape, or form).

[mholt]

I disagree. I find several flaws with that argument and dispute the claim that "it's clear that security is not actually a focus of this project," despite having virtually nothing to do with this project or its development myself.

"Your SSH3 public server can be hidden" section. This is called "security through obscurity."

A secret link is no different from a bearer token. You have to guess the link just as well as you'd have to guess a password or API token or similar. That's not "through obscurity," that's literally a password.

OS and network service fingerprinting has been around for a very long time. Congratulations, now people know there is a service here, and is using some variety of secret URL.

I don't think this argument holds water. First, how does fingerprinting the OS and network reveal an SSH3 server? And even if discovered, how is this different from discovering a login page, that uses "some variety of secret password"?

SSH3 is essentially SSH inside TLS via HTTP. Not only is this novel, this requires much deeper packet inspection than traditional SSH.

Brute force is impractical, but most certainly not impossible. Not to mention the general idiocy that abounds; people are going to use things like "/secret-url".

You are describing passwords. (And bearer tokens, etc.)

SSH3 is not security by obscurity. Unlike SSH2, SSH3 offers protocol privacy. Not only is the protocol the content of an encrypted TLS connection like anything else (a webpage, app transaction, content stream, etc), the establishment of the connection is guarded by a secret password.

both of whom should absolutely know better than this, I can only assume this is intentional malfeasance at this point.

I'm gonna stop you there -- that's a serious accusation and doesn't follow after even a shallow critique of your argument. (It's also mildly insulting and unprofessional; critique the work not the author.)

stick to proven technologies, like the OpenSSH project

Just going to play devils advocate for a second and suggest that a significant number of the most serious vulnerabilities in OpenSSH are not even possible in SSH3, at least this implementation, due to its use of Go, a language with stronger memory safety guarantees. In a very significant way, SSH3 is more secure right out the gates than any C program.

[james-d-elliott]

To quote NIST (NIST SP 800-123 Section 2.4): "System security should not depend on the secrecy of the implementation or its components."

This. System security should not depend on the secrecy. Quite literally security is not dependent on the secrecy in this instance. The secrecy is additional to, not instead of. Only takes a very quick glance to see New HTTP authentication methods such as OAuth 2.0 and OpenID Connect in addition to classical SSH authentication.

Regarding the remainder of the small portions of what I've read in your post, it seems like instead of asking curious questions it's just a whole heap of assumptions and accusations. Not what I'd consider constructive or wise.

[francoismichel]

Hello,

I won't repeat too much what has been said by the two above comments with which I agree. The original SSH3 article preprint already states that secret links are complementary to authentication mechanisms. They are not authentication mechanism. Just remember that secret links allows significantly reducing traffic (and code executed) from botnets scanning ports to find vulnerable SSH servers.

If an attacker knows the secret URL, that should not change anything compared to classical SSH servers. What I can do is adding a sentence insisting on that in the README if it really is unclear for some readers.

In this case, the use of a "secret" URL is directly analogous to running an actual SSH daemon on a different port; it can still be found, it can still be attacked.

As I like to say, URLs are the new ports. :-) What we enable here (in addition to authentication mechanism, not replacement) is, for instance, if the user wants it, to place the server behind a cryptographically random URL. This has nothing to do with user authentication nor authorization. The feature also limits the code executed by the server when it processes requests.

Brute force is impractical, but most certainly not impossible.

You can say that for pretty much everything security-related, everyone is aware of that and it should not be a problem. I don't know what point you're trying to achieve here, but it would probably be easier to retrieve the server URL with other ways than brute force (social engineering would be a way), so saying that bruteforce is theoretically achievable does not add much here. If you have the URL, you can now communicate with an SSH endpoint, yes. You're not logged in. You still have to authenticate, as it has been the case for decades. The security of SSH3 does not depend on the use of URLs and they don't replace authentication. :-)

This is quickly followed by the sentence "Attackers and crawlers on the Internet can therefore not detect the presence of your SSH3 server." This is absolutely false. They have already connected to the server; it's right there in front of them.

Saying that is omitting how many HTTP architectures work. The only thing you know is that you're connected to an HTTP server. Yes, the 404 may be generated by the actual code of the ssh3-server of this repository. However, I am sure you already know that accessing an ssh3 server through https://hostname:port/aaa does not mean that you access that same ssh3 server through https://hostname:port/bbb.

Regarding the tone of the message, don't forget we are humans reading your comments. :-)

I could see this being an early high-school project, but since this is apparently the project of a PhD student and a professor, both of whom should absolutely know better than this, I can only assume this is intentional malfeasance at this point.

I am not a fan of that kind of turn of phrase, as it is most frequently used as a way to call people idiots while pretending the opposite. And that hurts !

[grobe0ba]

To all, especially Francois: For what little it's worth, you have my sincere apologies. I was way over the line in every way, and my behavior quite inexcusable. I'm sorry for letting my bad attitude spill into here. No one here deserved any of that.

I've already made an ass out of myself (by behavior and ignorance), and failed to adequately explain myself whilst doing so, but I'll try to clarify just a small bit.

My only objection to the secret URL is that is (effectively) being labeled as security feature. I agree when correctly used it could help reduce exposure to some degree. The downside to the current presentation is that people, especially idiots like me, will see "security/safety/don't-cut-your-hand-off feature" and latch onto that as a primary mechanism regardless of design intent, while subverting every other safeguard that can be put in place. I deal with this at $soul_sucking_non_tech_day_job all day. It could be I'm just continuing to be an idiot. I'm not sure at this point.

Again, my sincere apologies for my terrible behavior. I really shouldn't be allowed to interact with people.

[mholt]

You're allowed to interact with people; thanks for being receptive to our feedback.

I was going to suggest changing the word "security" to "privacy" somewhere in the readme but then I realized that I couldn't actually find anywhere in that section where it declares the server hiding as a security feature. To me, it reads more as a privacy feature. In the "SSH3 security" section, it doesn't mention server hiding.

Anyway, sorry that your day job forces you to deal with these situations often. Maybe SSH3 implementations can be designed in a way that adds friction or makes it impossible to misuse. I could, for example, foresee a Caddy module that implements it in a way that only allows you to hide a server that is already configured securely. Or to only allow hiding it behind a URL that it generates for you (to guarantee it is a cryptographically secure token).

[grobe0ba]

If it were changed to be a crypto-random string generated by the server, not user-configurable beyond true/false, that would satisfy my paranoia. Impossible to set up incorrectly, and less likely to be of immediate interest to a hostile third party when it gets pasted into the wrong window.

With respect to "security" vs. "privacy", the secret URL paragraph doesn't actually explicitly label it as security, it just strongly implies it to me, specifically the line that says "Using SSH3, you can avoid the usual stress of scanning and dictionary attacks against your SSH server." This implicitly makes it read as a security feature to me. I'm probably still just an idiot.

[james-d-elliott]

Impressive that you can introspect like that, I dip my hat. Not many people are capable of doing what you just did, I also like that this followup was objectively more constructive.

I think in general constructive criticism is good but it by definition requires you clearly make your point generally respectfully and offer some ideas as a solution. Maybe someone has a very important security critique, but if the delivery is not constructive it will likely fall on deaf ears more times than not; at least in my opinion since it takes a lot of character to not take it personally.

I think there may be two key things are not being taken into account, though I don't want to derail too much, but I think some of these thoughts also may contribute to the overall resolution of this issue if only minimally.

Passwords are effectively secrecy as security when you just have a password, the user picks this value as well in most instances (complexity policies should be assumed to be known). The elements that prevent these just being secrecy as security is the hash comparison (i.e. the request is artificially slowed down due to a time cost, just one reason storing them in the clear is bad), and you can put password attempts into a strictly controlled request bucket (i.e. attempts over time from individual IPs) which additionally slows down attempts. The later option could reasonably be applied here, either transparently (i.e. return the same 404 as a bad URL, probably the objectively better option), or opaquely (i.e. return 429). You could reasonably encourage users to use a crypto-random value and give tooling to make that very easy.

There is a fundamental difference with URLs and ports. Ports have a limit of 65 thousand combinations. URLs can almost have the same number of combinations as a password. You can also combine a port and URL.

[grobe0ba]

I can't argue with the URL having an effectively infinite combinations available; the big difference is that of the perception from the viewpoint of a user. Not a sysadmin using tooling, who is familiar with what is or isn't sensitive information. Just the average person, say... following a poorly written corporate guide to connecting to an internal system. That URL doesn't mean anything to them; they're just mashing buttons.

You might have https://www.bigcorp.com/access-portal. Now, you also have a social engineering attempt, "Do you know the URL for the service desk? I think it 's like bigcorp.com/something-portal...". This is why I'm in favor of the randomness there being enforced, rather than support for an arbitrary string. If it's hard to remember, and doesn't have anything particularly human-readable in it, it might stand out in their memory, but who is going to memorize what to them is just gibberish?

By and large, your average user knows not to copy/paste a password into a chat with random people. URLs though? URLs are just something to share; that's all that gets done with them. YouTube? Facebook? Internal documentation sites? Copy and paste into the e-mail, and away you go. This is just one more thing to add to the list.

I like the idea of request limiting, and I agree that the better option is to return a 404. Give an attacker as little information as possible. This would make it less hazardous to use an arbitrary string vs. random.

I still think making it an random=true|false is the way to go here; the internet is built on misconfiguration. Someone is going to miss that this really should be random, or manglement is going to say "IT MUST BE THIS," and at least partially defeats the whole point.

It's not perfect, and even I can see some of the gaps in my logic here (like bookmarking it and copy/pasting that). I just can't think of anything better than disallowing the use of an arbitrary string.

Re: personal introspection: I'm generally pretty good at that. It's shutting my mouth and thinking before I act that I'm bad at. Self-sabotage is practically my favorite past-time. You're 100% correct about giving feedback; I've yelled at enough people for doing exactly what I did. I definitely know better, which is just one more reason it was inexcusable. Hopefully in another 30 years or so I'll finally grow up...

[francoismichel]

Hey, thank you for the sincere response and positive energy, it makes me start this day with the smile ! :-) Concerning the README, what I can do rapidly is adding a clear sentence stating that it does not replace authentication by any means and that the only way for a server to be considered safe is to use strong authentication mechanisms.

For the long term, I can: 1) create an issue on reworking how the URL should be presented in the README 2) maybe rework the cli args name on the server. I can make it a -secret-url flag that generates a crypto-random URL.

The reason why the URL was not random by default was that I did not want the users to struggle to connect to their remote host. It could have had an empty path by default but I just wanted people to notice the existence of that feature.