Part of the appeal of the ssh chat server from the article is that you can connect to the server using an existing console tool. It's not necessary to have a purpose-built client. So I've been trying to think: how could you get that convenience, but using HTTPS instead of SSH. [based on your example above]
In an update above I've talked about socat. That's less convenient than ssh, because socat is obscure vs ssh.
A hassle I've had trying to get a SSL server going in this last hour - it seems like you need to be signed by a recognised authority. ssh is convenient in that you get solid encryption, but you only need a fingerprint, not an authority sig.
> Part of the appeal of the ssh chat server from the article is that you can connect to the server using an existing console tool.
If what you're looking for is confirmation that ssh is indeed the most ubiquitous (at least ignoring Windows) console app to support encrypted console chat apps, then yes, I think you're correct for that very narrow design goal. For just about any other set of design constraints I think you have a much harder argument to make that ssh is more usable than HTTPS.
> A hassle I've had trying to get a SSL server going in this last hour - it seems like you need to be signed by a recognised authority. ssh is convenient in that you get solid encryption, but you only need a fingerprint, not an authority sig.
What you call a hassle is a major feature of all correct TLS implementations. SSH offers no guarantee that the server you're connecting to is who they say they are. I don't count SSHFP DNS entries because (a) they're rare, and (b) DNS is trivially intercepted. DNSSEC may fix that but support is rare. Without the ability to guarantee the identity of the site you're connecting to, encryption doesn't really matter. You may just be having an encrypted conversation with an attacker.
CAs don't gaurentee identity either. If you care deeply about either, you need to be comparing fingerprints. SSH clients have built in support for this, web browsers do not. Although I concede mechanisms like HPKP exist, they are not the default.
I would argue that automating verification via signatures is mostly strictly better than manually verifying fingerprints. But for ssh, you'd have to turn off basic key authentication (of users and hosts), and force the use of an trusted CA.
Trusting a slew of CAs to identify your server, when you only actually use one CA is indeed nuts (not to mention the fragility of certificate revocation for TLS, due to a (misguided) effort to avoid denial-of-service attacks).
You're not wrong (about most ssh deployments) - but ssh absolutely supports running your own CA. Perhaps there's a start-up opportunity in running a letsencrypt-like CA for ssh certs, though. I'm sure many people would be happy to pay a fee to have better key rollover, and arguably more secure server authentication.
You can use Lynx. It is a terminal based web browser, and is older than SSH. It exists for many platforms and is not particularly obscure or difficult to use.
This doesn't work as a solution to the problem in focus here.
Consider: could you implement a chat app that worked as effectively as the ssh one if you used lynx as the client? No, because interaction with lynx is synchronous.
The original article is making a point that you can build effective apps that work over ssh. The post at the root of this thread raised concerns about using ssh specifically.
Hypothetically you could have a console based web browser that supported javascript and websockets, and then expose the chat server over javascript. But that wouldn't be a good solution either: it's a specialised client and a large number of layers to achieve something that the ssh chat app shows to be straightforward - a secure, generic approach to exposing async functionality to a thin console tool.
In an update above I've talked about socat. That's less convenient than ssh, because socat is obscure vs ssh.
A hassle I've had trying to get a SSL server going in this last hour - it seems like you need to be signed by a recognised authority. ssh is convenient in that you get solid encryption, but you only need a fingerprint, not an authority sig.