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 no.

[Anonymous Coward]

>Admittedly, SSH is missing some pieces

Should read, "Admittedly, SSH is missing some crucial features, that make its use in this context impossible."

Re:Because no.

[hey!]

The lack of features may be a feature.

The more features something has, the more likely an oversight in the design or implementation will prove to be a liability.

I do

[Dan East]

I use SSH for everything. I use it between my cell phone and the wall charger. I use it between my thermostat and my furnace. Probably most importantly, I use it between my my remote control and TV. Never can be too careful these days.

Re:I do

[wbr1]

Looks like you are onto something. Its the SSH of things. I think I need to start a CloudSSH provider now and leverage the intrinsic value of the buzzword.

Re:I do

[Caesar Tjalbo]

2015 is the year of SSH on the desktop.

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

[AchilleTalon]

Someone must realize NSA leaked documents by Snowden are now out dated in some areas. Some security related bugs were patched since then.

Re:Because it's not safe either

[Anonymous Coward]

Despite the similarity of the names, OpenSSH and OpenSSL are maintained by entirely different teams. Of note is that the organization which maintains OpenSSH recently forked OpenSSL into LibreSSL which, once it stabilizes, is expected to behave more safely.

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.

Windows

[Lennie]

If anything is missing, it's probably only missing on Windows.

Support on Linux and Mac is jut fine, I think.

Windows:
- client support is kind of OK
- virtual filesytem support is kind of OK

The biggest missing solution:
- Windows server support. There are some expensive solutions, not sure how well they work.

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.

Re:Layered with, not instead of, HTTP/2

[Dagger2]

And if SOCKS isn't enough, you can also do ssh -w 42:42 to link a pair of tun interfaces between the two sides. (Slightly less cool because you have to manually configure networking on both ends for it.)

And then the summary decides to hold compression up as the super amazing feature that nobody has ever heard of...

Cygwin works fine.

[ron_ivi]

I know back in 1995 when Cygwin came out it got a reputation of being pretty flakey.

But it's come a long way in the last 2 decades.

These days, pretty much any time you think you have a "hmm, Linux can do this but I don't know how to do it on Windows", Cygwin is probably a very good possibility.

Because it's slow and featureless

[Just Some Guy]

SSH connections take For. Eh. Ver. relatively speaking:

% time ssh localserver exit
ssh localserver exit 0.02s user 0.02s system 2% cpu 2.061 total

Subsequent requests using the same connection are quick enough:

% time ssh localserver exit ssh localserver exit 0.00s user 0.00s system 20% cpu 0.039 total

But compare to an HTTPS connection to a remote host:

% cat curlcfg
verbose
trace-time

url = "https://www.google.com/"
output = "/dev/null"
head

url = "https://www.google.com/"
output = "/dev/null"
head

% curl -K curlcfg
...

A brand new request to a remote server takes just 263ms, and a second request only 81ms. Considering that the server is 25ms away, that makes it a bit faster than a cached SSH connection to a local machine.

But even more than that, SSH in this context is a transport, not a protocol. It allows you to build and manage secure connections, but you still have to write a protocol on top of it ("I'll send this command, and you reply with..."). Even if you "cheat" and use SFTP, you're still missing out on fixes to the thousands of little issues people have worked out with HTTP over the years. What's the SFTP equivalent of If-Modified-Since? How will redirects to remote servers work? What's your cross-domain scripting policy? How are you going to handle anonymous connections?

Use SSH for SSH. Use HTTP for HTTP. They're separate things for good reasons.

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:Actually...

[Anonymous Coward]

Why aren't we using SSH to monitor the computer's microphone?

We ARE using SSH to monitor your microphone.

Sincerely,
The [3 characters redacted]

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:Public Key, not SSH.

[viperidaenz]

The "my hard drive crashed and now all my private keys are gone so I've irreversibly lost access to all my accounts" problem comes up though.
You also need a secure method of either transferring keys between devices or linking new keys to existing accounts.

Trust

[mrflash818]

I think, because only a fraction of 'net users are security conscious.

The rest just use the 'defaults' of their apps and search result links for things like email , online shopping, and online banking, and trust(?) that the people providing the access to their email, online banking, and online shopping, kept them safe.

Re:PITA

[geantvert]

Hummm... configuring openssh is really not difficult on most modern Linux distributions.
Install the openssh packages, execute ssh-keygen once per user and you are basically done.

The only tricky part for some novice users is to copy the public key to the server (in .ssh/authorized_keys) but recent versions of openssh provide the ssh-copy-id tool that can do that for you.

 

Another idea...

[marciot]

Condoms are pretty good for safe sex. I think we should be using condoms to protect our bank accounts, for giving everyone safe drinking water, for screening passengers at airports and for securing your valuables in hotel rooms.

Re:BINGO

[hey!]

I think you just answered the poster's question, by the way. SSH is quite good for what it does, but what it does doesn't cover every conceivable need.

A better question might be,"Why aren't we using SSH *in more situations where it might be useful*?"

Re:Medium.com

[arglebargle_xiv]

What's wrong with Medium? It's essentially just a blogging platform, right?

So is Slashdot, if you're Bennett Haselton.