[Cryptography] Why aren’t we using SSH for everything?

[Jerry Leichter]

On Jan 3, 2015, at 3:03 PM, Henry Baker <hbaker1 at pipeline.com> wrote:
> FYI --
> 
> Why aren’t we using SSH for everything?
> 
> https://medium.com/@shazow/ssh-how-does-it-even-9e43586e4ffc
There are three widely-known protocols to provided authenticated/encrypted connections:

1.  SSL/TLS.
2.  SSH.
3.  IPSEC.

It's interesting to compare the three.  In terms of programming interface, IPSEC is what you would design if you had a blank piece of paper and the goal of allowing any network-enabled program to work completely transparently.  This is how we generally add new functionality while retaining old code.

SSL/TLS is at the far extreme:  It presents a network programming model entirely unlike the TCP stream-oriented model.  That doesn't make it bad, it just means you can't take, say, FTP and layer it over SSL/TLS without significant rework.  (Again, the issue isn't whether that's a good idea.  If you don't like FTP, pick something else.)  No surprise here - SSL/TLS didn't start off with the goal of supporting "secure connections" in the abstract, it started off with the goal of providing secure HTTP connections.  On the other hand, there are libraries for SSL/TLS that you can build against - though they've traditionally been very complex and difficult to use.

SSH also started off with a specific goal:  Providing remote terminal connections.  But the semantics of remote terminal connections is pretty close to TCP streams, so allowing forwarding of arbitrary connections was much easier than with SSL/TLS.  But for whatever reason, SSH has continued to exist as a standalone program rather than a library, which makes configuration more complex for the unsophisticated user.

IPSEC, of course, suffered from various design-by-standards-committee problems, leading to huge complexity underneath what could have been a very simple interface.  Early VPN's relied on IPSEC, but ran into all kinds of issues (like early WiFi routers that didn't recognize IPSEC connections as TCP.)  Today pretty much all VPN's you use are SSL/TLS based.  In this indirect way, SSL/TLS is finally supporting programs using the TCP socket bindings - by mapping the IP layer, which is packet oriented, to the SSL/TLS record orientation.

Of course, going to VPN software means that you're using SSL/TLS in a separate program - just like SSH, but much less configurable.  It's interesting that no one, as far as I know, has taken the reasonably standardized SSL/TLS VPN bindings and turned them into a library that forwards connections only for the program it's linked to.  Meanwhile, in the grand convergence, SSH is being used to implement VPN's.  But, it, too, could benefit from being turned into a library.

Or ... why not take either SSL/TLS or SSH and build them into system libraries, so that you need to nothing other than, say, change the format of a host name to get SSL/TLS or SSH protection for the socket you create?  (The socket API was, unfortunately, not designed with anything like this in mind - to much low-level crud is exposed to users.  But some of the changes made to support IPv6 raised the level a bit.)

From the point of view of the actual connection, whether it's SSL/TLS or SSH doesn't much matter.  The two do have very different ways of managing the credentials needed - each with advantages and disadvantages.  SSL/TLS is slowly picking up support for SSH-like "connection continuity" ideas, though as essentially additional steps on top of its existing base; SSH hasn't, as far as I know, moved toward SSL-like ideas.  I'd say neither approach is complete - we need a synthesis of the good ideas from both, and from elsewhere (OpenAuth and such).

Encryption and authentication have to "just be there" using standard techniques, not something you need to put in using a special, complicated procedure.  This was definitely the idea in IPSEC - and, BTW, would have also been consistent with the design approach of the ISO network protocols.  Two good germs of ideas completely spoiled by the standards process.

(Me, I miss DECnet in VMS:  Network support was built into the file syntax and the file system.  The file syntax included a place for a username and password.  Authentication was done by the OS when receiving the connection attempt, not re-invented by every program.  This was way too early to support encryption, so would have needed years of development for the modern era - but a much better base than what we ended up with.  Plan 9 ran with similar ideas in a Unix-like context; there were probably others.)
                                                        -- Jerry