Why aren’t we using SSH for everything? (2015)
medium.com
medium.com
For instance: the HTTPS stack will, with effort, allow you to opt in to protocol forwarding, via mechanisms that were designed to prevent accidental forwarding. The SSH stack, on the other hand, requires you to opt out of arbitrary TCP/IP port forwarding. Screwing that up will, more often than not, get you owned up Phineas Phisher-style.
The things this post appreciates about SSH are equally available in the HTTPS stack (even more so in the HTTP/2 stack). Unlike SSH, with its janky Connection Protocol, HTTP has for the last 10 years been designed as an arbitrary application protocol. SSH does a better job providing interactive terminal sessions. HTTP does a better job at everything else.
Also consider attack surfaces here, how many exploits have there been on say openssl and apache/nginx over the Past 1/5/10 years. How many on OpenSSH?
>For instance: the HTTPS stack will, with effort, allow you to opt in to protocol forwarding, via mechanisms that were designed to prevent accidental forwarding. The SSH stack, on the other hand, requires you to opt out of arbitrary TCP/IP port forwarding. Screwing that up will, more often than not, get you owned up Phineas Phisher-style.
Lets not forget that libraries like OpenSSL require you to "opt out" of shit like ECB mode and NULL ciphers.....
This. I can't believe the top comment on this post is supporting TLS (as implemented currently) over SSH (where everyone is basically using openssh). There's pretty much a guaranteed "named" widespread TLS based attack exposed every month or so. Whether it's due to TLS the spec or the prevalent implementations, it doesn't matter. Any application designer choosing a protocol has to contend with the fact of shitty implementations of the underlying layer when thinking of security.
Legacy SSH uses conventional DH signed with pinned RSA keys to run CBC and HMAC. Legacy TLS uses conventional DH with RSA keys to run CBC and HMAC. Both have complicated negotiation schemes that include cipher parameters nobody should ever use.
Modern TLS uses forward-secure ECDH, signed with pinned RSA keys, to boot up an AEAD. Modern SSH uses ECDH signed with pinned RSA keys to boot up an AEAD.
There are two important reasons why TLS has more attacks than SSH:
1. Contra the article's claim of SSH's ubiquity, TLS is actually ubiquitously deployed, and so older version of the protocol by necessity live longer and cause more trouble.
2. TLS is used by browsers, and browsers support content-controlled code. You can't have BEAST or CRIME or AlFardan's RC4 attack without something to force a client to generate thousands of related connections.
But neither of these are factors for people who would consider using SSH instead of TLS. Those same people can deploy minimized configurations of TLS, and use native applications instead of browsers. See, for instance, what payments companies do with their iOS applications.
TLS has never supported ECB, by the way.
Not even close.
While TLS technically supports client-side certs, all extant implementations of it are unbearably clunky to use, completely ignored by all vendors. Meanwhile the tooling around SSH keys (like ssh-agent) is seamlessly integrated with your OS and works so well that it's easy to forget it even exists.
Browser vendors completely dropped the ball on this; they dropped it so hard it continues to hurt even after all these years.
I've yet to get to the point of moving to "modern ssh" (ed25519 key/certs, chacha20-poly1305 encryption etc) - with certificate only. Because keys are *so' convenient. But they're also, while better than passwords, pretty bad: No expiry, no easy rotation, no easy revocation.
I will say this though: it should be quite feasible to move to modern ssh, banning keys and passwords (other than perhaps as a second factor), and moving to certs only. But clearly deployment of reasonable ssh setups are lacking behind the technological improvements.
I hope things have gotten better now, but five years ago I ran into this in spades. Pulling teeth both to implement and then to explain. Especially if it's from a cert chain, and doubly so if you want to only trust certain from your CA.
And I think across the whole stack we ended up with three TLS stacks, and some HSM hardware. So I got to figure out trust stores multiple times.
I should have run screaming, but I stayed at that job an extra five months just to make sure that everyone really understood the mutual certificate auth code at a practical level. There's gotta be a better way.
I really think we need a hybrid system that is more like PGP, where you have a key chain and get advisary info from your peer group about the veracity of a CA Signed cert.
Update: looks like an effective tool could be socat, which seems to be a SSL-capable take on netcat. On the server side, reckon it would work to use stunnel. You could have xinetd host a launcher that wraps stunnel around a simple socket server. Clients could connect to that with socat.
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.
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.
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/
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).
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.
Or are they not suitable for that?
Integration to the PAM-stack would be a little more complicated, but there are some tools for working with certificates[eg: 1]. I'm not aware of any that is designed to work for console-like login remotely, though.
[1] http://www.ftsafe.com/application/signon/linuxpampkcs11/
The only place I've personally seen client-side certificates implemented in a browser was for StartSSL's site (which is famously janky in it's workflow). In contrast, pretty much anyone who does anything on the CLI in a unix environment has a client-side ssh key set up, already good to go.
That said, I don't remember the previous posting of this article, so linking to previous comments is useful. It lets me compare the discussions and see how opinions do or don't change.
Whose comment? fjarlq's comment? If so, I also might be wrong, but I read it as "Here's old discussion on the topic. Might be worth reading to see if what you want to talk about today has already been hashed out, or if there's discussion that you might find interesting.".
I see where you're coming from, but I think everyone is well served not always looking for ulterior motives where there are none. A link to a rich previous discussion on a topic is almost always both relevant and informative, and saves others from having to go an search for the relevant thread(s).
If there's one great failing of computer science as a field, it is the lack of history -- people just don't know what was, or how things came to be. And so we have a lot of effort wasted on recreating yesterdays mistakes, today, rather than building on old solutions to create better ones for tomorrow (to partly paraphrase Alan Kay).
The answer is HTTPS.
Managing an SSH server with millions of customer pubkeys is a pain. Python/twisted and Go have decent SSH implementations but there are quirks and side effects a plenty.
Shells are scary. You have to be very careful about how you execute the program on the remote side of the pipe. Shell command parsing and escaping is gnarly.
Windows...
HTTPS with basic auth headers is much easier to scale.
The one gotcha is that it took a while for HTTP git to get "smart" and offer as efficient transport as SSH with access to a .git dir.
Even though client TLS certs are technically supported by a handful of services, there's nothing for HTTPS that matches the security and convenience of ssh-agent. It has a long way to go to catch up to where SSH was ten or fifteen years ago.
But for git you have the right answer.
I completely forgot this aspect because on OS X you can delegate git auth to Keychain with a helper.
https://help.github.com/articles/caching-your-github-passwor...
I hope this pattern catches on for services other than git.
Then your public keys provide not only identity, but services can verify that identity through their web of trust.
And millions of passwords isn't because ... ? Whatever solution the industry has arrived at for storing a large number of user passwords and authenticating against them, can be applied to SSH keys too. I would be greatly suprised if Github uses ~/.ssh/authorized_keys to handle SSH authentication at its scale.
> Python/twisted and Go have decent SSH implementations but
So is the case with HTTPS implementations. It's just a standard, how it's implemented is not under its control. On the other hand, we have some good implementations of HTTPS, and similarly we have good implementations of SSH too: libssh2.
> Shells are scary.
So don't use shells over the SSH protocol. Make the server execute (upon successful auth) something that isn't a shell.
> Windows...
Agreed. Until user-agents popularly support a protocol, adoption faces large obstacles.
> HTTPS with basic auth headers is much easier to scale
Easier how? You have to do less computation to verify the password? This has nothing to do with the transport, and everything to do with the cryptographic strength of the password. SSH is better here because of its good support of keys (versus TLS client certs).
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.
http/2 and TLS1.3 are great but make some assumptions that might not be right for everything.
Whats App is using Noise now in their apps.
More on Evennia itself: http://evennia.com
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.
> Only specialists appear to understand the PKI infrastructure ... Compare to FTP, it's easy to grok managing and securing a string.
It's also easy to break into a typical string-password-protected service. If FTP needed the higher security, it would have to use complex crypto. Crypto is hard.
But, as I said above, it doesn't have to be hard to use, only implement.
> It's leaky
Agreed, SSH should have some support for matching keys with hosts automatically. But it already supports doing this manually. Check out IdentityFile in ssh_config's manual.
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.
Nothing wrong with OpenSSH supporting the option to use certs. They can be useful to some users.
But the entire X.509 scheme to my knowledge was based around some idea of third party verification.
This gave rise to the business of selling CA "services". Problematic to say the least.
And still to this day, "self-signing" appears to be disfavored. Or perhaps the openssl binary is just too loaded with options for users to learn the commands to generate CA and server certs and keys.
Whether it truly is or not, ostensibly "SSL/TLS certificates" to the public seems to require third party involvement.
ed25519 keys do not have this problem. And generating them is relatively fast.
> RPC API
Please don't. Managing SSH sensibly (with checking keys properly) in any greater scale is awful. SSH was never meant for general communication, which reflects how it operates on implementation level and on protocol level. SSH servers require usable home directory locally and remotely (OpenSSH has some workarounds, but this quickly becomes ugly), you need to manage SSH keys, both public and local, and protocol has plenty of options useful for interactive administrative service, but terrible from security standpoint (have you disabled everything unnecessary? and are you sure it was everything?). If you use SSH in non-interactive, non-supervised mode, it is a disaster waiting to happen.
> Why aren’t we using SSH for everything?
Because it is not suited for everything. It is only suited for providing shell and for some non-interactive but human-supervised tasks.
As far as the server side - apart from the storage of the keys (which is required with any cryptographic protocol), I'm not sure where the challenge comes in.
Bootstrapping trust is a problem in any situation. SSH server keys paired with an out of band mechanism for distributing public keys or SSHFP can prove to be a fairly reasonable method. I'd say somewhat more reasonable than what we had with HTTP + TLS for the longest time (until say Let's Encrypt). Even with that, certificate stores aren't particularly easy to manage.
Going back to the language-specific implementations of SSH. Those servers can be run without the necessary submodules to do shell-like stuff. I agree with you, it'd be crazy talk to use the system SSH daemon to do much of what's described by the author, but as a protocol, perhaps it is more reasonable.
DNSSEC is a disaster. Avoid it.
The only thing DNSSEC has given us is widespread DDoS amplification.
The author states "For something as harebrained as the CA system, remarkably few criminal breaches trace back to it -- There have been many false CAs, and certificates issues. We have no idea what they've been used for (http://arstechnica.com/security/2015/03/google-warns-of-unau...). In addition to this, there exist many CAs whose primary purpose is to perform MITM-style attacks
The author's points about DNSSec being expensive - somewhat, but more an more providers are offering DNSSec at the same price as normal DNS. Fedora is even enabling it on all their end hosts.
As far as the "Government controlled PKI": 1. What's better? Some security, or no security? 2. If the government wanted to crack DNSSec, there still exists the fact that we can share KSKs out of band for verification.
DNSSec is capable of providing better security than the current system. It does have some implementation gaps, but what do you propose alternatively?
> Managing SSH sensibly (with checking keys properly) in any greater scale is awful.
The certificate key format introduced by OpenSSH allows for quite easy large-scale key management so long as your clients and servers are OpenSSH or golang x/crypto/ssh
Will it? What is the proxy server happens to have a key whose fingerprint hash is the same as the original server's key?
SSH very recently upgraded how keys are fingerprinted; the screenshots in this article are the old method, which as I learned recently, are MD5 hashes. (I had thought they were SHA1.) SHA-256 is what gets used now. But, for example, Ubuntu's LTS doesn't have the update. I'm glad they made the change, but I'm left wondering how key exchanges aren't somewhat vulnerable on unupgraded machines.
(e.g., fingerprints now look like:
SHA256:7h5Q0O1Qc8G7Hv/hVIrx1d6ZTgnITwrutr1XDBYY0sg
)If I understand correctly that's basically a preimage attack, and even for MD5 where you can find arbitrary colliding pairs very easily today, AFAIK no one has come up with a single preimage example or practical attack.
I suppose the natural thing would be to marry the Robust IRC server/gateway to a golang ssh front-end, so that one could ssh in and be dumped right in a (nick authenticated) robust irc sesssion...:
"SSH session keys are ephemeral and are exchanged between hosts using DHE."
It's expensive. That's why we aren't using Encryption for everything.