One of my favorite tales by Hans Christian Andersen is titled “The Emperor’s New Clothes.” In this story, a couple of swindling weavers offer to make a suit of clothes for a gullible emperor, invisible to anyone not sufficiently intelligent or capable. The suit of clothes wasn’t real, of course, but since the emperor and his ministers couldn’t see it, they wouldn’t risk pointing out that fact and being exposed as stupid and incompetent.
Over the years, there have been many times when I’ve found myself nodding my head in pretend understanding when various technical acronyms, jargon and concepts are thrown around in a meeting or during a presentation. I feel like one of those advisors, pretending to know something that I do not, and I kind of feel like everyone else in the room is either like the advisor, or like the swindlers.
No invisible clothes here…
Since we use the acronyms SSL and SSH frequently in these blog posts, I figured it wouldn’t hurt to provide some fundamental description of what they are and what they do.
If you’ve never been confused about the difference between Secure Sockets Layer (SSL) and Secure Shell (SSH), then you’re a rare specimen. It’s not enough that the letters are so close–they’re both associated with securing data in motion. They’re also both used when securing interactive access to host-based applications, such as those running on IBM mainframe systems, or on UNIX platforms.
SSL started life as a specification developed by the Netscape Corporation for the purpose of providing a cryptographic protocol to secure HTTP communications. The most recent version of the SSL specification (version 3.0) was released in 1996. Since then, the Internet Engineering Task Force (IETF) has defined an equivalent, but not strictly interoperable standard called “Transport Layer Security” (TLS).
Convention often dictates that when SSL is “added” to a nonsecure protocol an “S” should be added to the end of the protocol name; for instance, HTTPS or FTPS. When IBM needed a way to encrypt terminal-based access to their mainframe and midrange systems, they implemented SSL for encrypting TN3270 and TN5250 protocols. You will occasionally see those represented as TN3270S and TN5250S, respectively.
The SSH network protocol was designed by researcher Tatu Ylönen in 1995 for the purpose of securing remote access and command execution on UNIX servers. Like SSL, subsequent revisions of the standard were developed by the IETF.
SSH “the protocol” is different than the set of client utilities (including one called ssh) that make use of the SSH protocol. These utilities provide remote interactive and batch access to UNIX and Linux command lines as well as secure file transfer capabilities. When SSH is applied to file transfer, you will frequently see the acronyms SFTP and SCP; both are SSH-protected file transfer methods.
So, there you have it. A basic explanation of SSL and SSH that will let you nod your head earnestly next time you hear them.
