3 ms·

> 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 i

> 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. https://letsencrypt.org/ https://letsencrypt.org/ takes much of the hassle of getting a verified TLS certificate away and can even be fully automated for example: https://caddyserver.com/ https://caddyserver.com/

throwaway2048 11y ago
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.
- e12e 11y ago
  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).
e12e 11y ago
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.

throwaway2048 11y ago

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.

e12e 11y ago
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).

e12e 11y ago

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.