Why Aren't We Using SSH For Everything?

An anonymous reader writes: A post at Medium asks why, in this age of surveillance and privacy-related bogeymen, we aren't making greater use of SSH for our secure computing needs?

"SSH is one of the most accessible secure protocols ever, second only to HTTPS of course. Let's see what we have so far: Binary protocol, mandatory encryption, key pinning, multiplexing, compression (yes, it does that too). Aren't these the key features for why we invented HTTP/2?

Admittedly, SSH is missing some pieces. It's lacking a notion of virtual hosts, or being able to serve different endpoints on different hostnames from a single IP address. On the other hand, SSH does have several cool features over HTTP/2 though, like built-in client authentication which removes the need for registration and remembering extra passwords."

Comments

Because it's not safe either

[Anonymous Coward]

Recent Snowden documents shed doubt on whether the NSA isn't actually able to crack ssh, too. http://www.spiegel.de/international/germany/a-1010361.html

Re:Because it's not safe either

[gweihir]

More likely the NSA can use some misconfigurations and crack some (really old) defective clients or servers that are still on protocol v1 or the like. OpenSSH should be pretty secure, but some commercial implementations really suck, and not only with regards to security.

Re:Because it's not safe either

[MightyMartian]

The article suggests heavily that a properly configured SSH client and server with secured cert chain is likely safe from prying. The problem with SSH, as with all things, is the use of older distros that may not be updated and not building a proper CA to sign certificates.

Re:Because it's not safe either

[caseih]

If anyone else hadn't heard about using a CA with ssh, as I hadn't, they might find this short tutorial interesting:

https://www.digitalocean.com/c...

Wish this was available back in my uni days when I managed many dozens of Linux workstations. Managing keys was always a pain.

Re:Because it's not safe either

[gweihir]

So they are brute forcing weak SSH passwords. Not impressive, anybody can do that and there is even a bot-net that does it, look up "low-intensity zombies". As to pre-shared keys, there is a known vulnerability of embedded devices that can make their keys vulnerable if they are generated in a low-entropy situation. That has been fixed AFAIK and does not affect proper computers.

As to IPsec: First it is known that the IPsec standard was sabotaged by the NSA by making it overly complicated and complex, doubtless in order to make implementation and configuration mistakes more likely. Second, I have no idea what "non keyed" means for IPsec. Maybe you mean PSK? That can again be attacked if keys are badly chosen. No surprise.

Really, the NSA will of course to what ordinary hackers can also do, but use sound practices and they will need to to an expensive and high-risk targeted attack and even that may fail. The goal here is not to make it impossible for them to get in, the goal is to make it far to expensive in most cases, to they cannot do dragnet-surveillance. One of the hugely dangerous things they are doing is that they collect data on everybody. If somebody becomes, say, a president in some place and they do not like that person, they can go through their archives and sabotage democracy with what they find. It may even be enough that people think they can do this. That makes them a clear and present danger to democracy, freedom, the rule of law, etc. Or in short: Terrorism is peanuts in comparison with the huge threat these people represent.

Layered with, not instead of, HTTP/2

[allquixotic]

One of the coolest client-side features of most SSH clients (at least OpenSSH and PuTTY support it) is the ability to turn any SSH connection into a SOCKS5 proxy, provided the server will let you. If your Internet connection has a restrictive stateful firewall on it that blocks your access to many useful legitimate sites, you can just stunnel out over TLS and then have the ability to go outbound on any port (including SSH's default port of 22) using your SOCKS5 proxy. I've used RDP over SSH over TLS before to get around restrictive filters.

We ARE using ssh and https for everything

[iamacat]

telnet and ftp practically died a while back, http is on the way out. In most corporate environments, other protocols such as X are local only and remote use is over ssh tunnels. IMAP/SMTP takes place over TLS when using decent providers. I guess there is a question of whether SSH and HTTPs should be merged. But a lot of work has been put in both and would be difficult to replicate and make as secure from the start. No hurry.

The only exceptions are organizations with lax security (like Sony apparently) and cases where security or integrity is completely not an issue. I guess if you broadcast a video as unencrypted UDP over a local network, that's fine.

Public Key, not SSH.

[Anonymous Coward]

SSH as a protocol was designed for interactive login, and it has some issues when used for other applications. But there is one key aspect of it that needs to break out of SSH, the public key cryptography part.

When creating an account on a web site, rather than entering a User ID and password the browser should generate a public-private pair, and send the public part to the other side. Logins can then be done just like SSH does, with a cryptographic exchange.

The "lost password database" goes away completely. If you got the database on the far end it would only contain public keys, which would not allow logins. The whole "everyone must change their password" nonsense goes away.

So don't force SSH on us, but let's all work to get more public key based logins.

Re:Because it's slow and featureless

[tnk1]

Yes.

There have been discussions where I work about setting up encrypted connections for some of the data that we're passing over the Internet. At first it was taken for granted that we'd use SSL or some form of encrypted link to do so.

Then someone very smart mentioned that the data is already sent in a manner in which it is difficult, albeit not impossible, to reconstruct usefully. It might be possible for someone like a state actor or organized crime to spend the time and resources on reconstructing the data, but without any personal information or financial transaction information in the stream, it ended up not even mattering at all anyway.

The flip side is that we really, really want the data to be processed quickly. That means not spending the time and effort on decryption processing overhead where our options are either accepting lower quality of service or alternately spending more on processing power.

Point is that we know that the NSA or FSB or North Korea or the Mafia could intercept and and reconstruct our data, but ultimately we don't care if they can, we don't know why they'd bother, and we don't promise our customers that we'll prevent that. What we do have are QoS guarantees, not to mention a general need for QoS so we don't seem shitty.

Make no mistake, for sensitive information, you should have encryption, despite the overhead. We do use it for anything that would be sensitive, such as authorizations, personal information, and transactions. Even then, we don't kid ourselves about SSL preventing some sort of determined attack by someone with sufficient resources. At that point, there is only so much you can do.

Security risk assessment is not an exercise about what is possible, it about what is *probable* and then assigning your limited security resources to defend against the most likely, but not always most glamorous threats.

For instance, the Sony hack was likely a common combination of social engineering, malware, and shitty risk management with the internal networks. Encrypting the connections would have probably done fuckall for them, because the hackers weren't intercepting traffic, they were actually breaking in with passwords or remote exploits. Having admins who knew how to compartmentalize their shit (and not click on malware) and maybe keep their passwords in an encrypted keychain with some multifactor authentication thrown in would have been priceless.

Internal networks are a cesspool of open shares, with proprietary or sensitive information liberally slathered around, waiting to be found. Everyone assumes the "firewall" or the "encrypted network" will protect them. What actually happens is that too many people are storing too much information on systems that are too numerous and heterogeneous for anything but the most dedicated internal IS department to keep track of. That is, unless there are some intelligent risk assessment and useful programs (like actual training and well enforced security procedures).

Re:Medium.com

[tompaulco]

Nothing wrong with blogging platforms. Nothing even wrong with interesting blogs having advertisement attached so that they can make a little money off of their interesting blogs. However, when it is the advertisement that is the entire focus of the blog and the blog owner is merely scrambling for some sort of information that looks interesting in order to fool you into clicking on their ads, then there is plenty wrong with that.
But alas, it is unfortunately the 99% that give the other 1% a bad name.
I keep hearing this annoying DJ on the radio who spends probably 5 minutes per hour trying to entice listeners with a snippet of news and then directing them to his blog to read the full article. With as much advertising as he does for that blog, I sure hope they are charging him a couple thousand dollars a week. Of course his blog probably only brings in a few hundred a month.