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."
"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."
SSH connections take For. Eh. Ver. relatively speaking:
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:
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.
Dewey, what part of this looks like authorities should be involved?
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.
Uh, Linux geek since 1999.
Someone must realize NSA leaked documents by Snowden are now out dated in some areas. Some security related bugs were patched since then.
Achille Talon
Hop!
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.
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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*?"
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.