31–40 of 87 posts
I wish I could register for services with nothing but a public key. No email address. No username. When I want to login, generate a login token and I'll sign it and give it back.
2. Only specialists appear to understand the PKI infrastructure which underpins this security enough to properly manage the keys; possibly with expensive appliances. Compare to FTP; it's easy to grok managing and securing a string.
3. It's leaky. When you connect by FTP you present only the creds you desire. When you connect over SSH you expose all of your identities / keys to the other server. Pretty dumb.
Some MUDs already support ssh, don't they? I know that some nethack servers do.
More on Evennia itself: http://evennia.com
Opinion: In terms of "authentication" I still think ssh has the edge over anything associated with http/https and www. Two parties should be able to authenticate to each other without involving a third.
It's expensive. That's why we aren't using Encryption for everything.
Idea: Maybe it's the "sh" in ssh that make it so useful. Environmental variables instead of "HTTP headers". envdir Opinion: In terms of "authentication" I still think ssh has the edge over anything associated with http/https and www. Two parties should be able to authenticate to each other without involving a third.
Earlier quoted context omitted.
I'm not sure I understand the comparison. openssl s_client creates a TLS connection, but doesn't drive the HTTP protocol; it's a generic bidirectional encrypted transport. Lots of chat protocols use TLS in exactly this manner. But I'm going a step further: I think even if you're stuck with HTTPS/HTTP/2, you're still better off tunneling your application protocol over that than SSH.
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…
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/ takes much of the hassle of getting a verified TLS certificate away and can even be fully automated for example: https://caddyserver.com/
Trust his advice at your own peril.
Encryption is about 2 orders of magnitude more computing intensive than non-encryption. It's expensive. That's why we aren't using Encryption for everything.
Idea: Maybe it's the "sh" in ssh that make it so useful. Environmental variables instead of "HTTP headers". envdir Opinion: In terms of "authentication" I still think ssh has the edge over anything associated with http/https and www. Two parties should be able to authenticate to each other without involving a third.