Overview
The most widely used secure file transfer protocols, SFTP and FTPS, get their security from underlying protocols. SFTP from SSH and FTPS from SSL. Let's compare the two.
In the past, there was only one popular method for transferring files over a network - FTP, which simply stands for File Transfer Protocol. FTP supports bulk file transfers and even allows users to navigate remote directories, create directories, delete directories, and perform a few other tasks similar to those done on local filesystems.
FTP is a TCP-based protocol. Hence, it can be very useful for downloading/uploading files over a LAN or even through the Internet. However, FTP was designed at a time when the use of the Internet was limited to a few organizations and network-based threats were non-existent.
Today, a multitude of threats already exist and FTP connections can be compromised through sniffer attacks, brute force, and other forms of cyber attacks. To protect file transfers from these threats, secure file transfer protocols were developed. Of these protocols, two have gained widespread adoption - FTPS and SFTP.
FTPS actually gets its protection from SSL/TLS (Secure Sockets Layer/Transport Layer Security), while SFTP gets its own from SSH (Secure Shell).
Recommended read: SSL vs TLS - Know The Difference
Similarities between SSH and SSL
When you compare their security attributes, you'll find that SSH and SSL have very strong similarities. They both offer data-in-motion encryption, server authentication, client authentication, and data integrity mechanisms.
Data-in-motion encryption
Data-in-motion encryption is a security capability that prevents eavesdroppers from viewing data sent over a network. In other words, it keeps transmitted data confidential. It's supported in both SSH and SSL and acts by converting the plaintext data into what is known as ciphertext.
All an eavesdropper would see when viewing ciphertext on an encrypted connection would be an incomprehensible string of characters.
These two screenshots show what an eavesdropper sees when sniffing an unencrypted connection and an encrypted connection. Notice how the unencrypted connection fails to conceal the username and password. In the unencrypted connection, those login credentials are already unintelligible.
Unencrypted connection (e.g. FTP)
Encrypted connection (e.g. SFTP or FTPS)
Both SSH and SSL provide data-in-motion encryption through what is known as symmetric key encryption. This kind of encryption employs a shared key that's used for both encryption and decryption. Some common symmetric key ciphers include AES, 3DES, Blowfish, Twofish, and RC4.
To learn more about symmetric key ciphers, read An Introduction To Stream Ciphers and Block Ciphers
Server and client authentication
An encrypted connection becomes useless if you've unknowingly connected to a bogus server or a malicious client. While SSH and SSL use symmetric cryptography to preserve the confidentiality of transmitted data, they use another form of encryption for authentication. Authentication allows one party to verify whether the other party is really who it claims it is.
To implement authentication, SSH and SSL use asymmetric cryptography a.k.a. public key cryptography. The popular public key encryption algorithms are RSA, DSA, and ECDSA, all of which are supported by both SSH and SSL.
Unlike symmetric encryption, which uses a single key for encryption and decryption, asymmetric encryption uses two keys - a public key and a private key.
Recommended read: Symmetric vs Asymmetric Encryption
Public key encryption can be used by a client to authenticate the server. This is known as server authentication. Server authentication prevents client applications from inadvertently connecting and then transacting with a malicious server that's impersonating a legitimate one.
Conversely, public key encryption can also be used by a server to authenticate a client. This is known as client authentication. The article What Is An SFTP Key includes a nice introduction on client authentication and public key cryptography.
Data integrity mechanisms
When you're receiving sensitive information, data integrity is as important as data confidentiality. You'll want to make sure the data you receive is exactly the same data that was originally transmitted by the sender.
Businesses, in particular, require a high level of assurance for data integrity when they conduct transactions over the Internet. Tampered data can adversely impact business processes and may even be a sign of fraudulent activities.
Data integrity mechanisms enable transacting parties to check whether the transmitted message was unaltered along the way. MAC (Message Authentication Code) algorithms like SHA1, SHA256 (and other versions of SHA) and MD5 are typically employed by both SSH and SSL for carrying out data integrity checks on transmitted messages.
The article Understanding Hashing includes a nice discussion on the subject.
Differences between SSL and SSH
One of the most noticeable differences between SSL/TLS and SSH is that SSL normally (yes, there can be exceptions) employs X.509 digital certificates for server and client authentication whereas SSH does not. And because SSL uses digital certificates, it consequently also requires the presence of a public key infrastructure (PKI) and the participation of a certificate authority (CA).
Although it's possible to employ what are known as self-signed certificates, in which case SSL then becomes very similar to SSH due to the absence of a CA, this is not a recommended practice. Self-signed certificates are only acceptable in intra-organizational transactions, except in large (e.g. globally distributed) organizations.
Another big difference is that SSH has more functionality built into it. For instance, on its own, SSH can enable users to login to a server and execute commands remotely. SSL does not have this capability. You would need to pair it with another protocol (e.g. HTTP, FTP, or WebDAV) in order for it to have similar functions.
SSH also readily supports connection multiplexing, flow control, terminal management, and other features. Of course, those additional features no longer fall under our original discussion wherein we started comparing SSL and SSH in relation to SFTP and FTPS.
So before we stray away any further, let's end here.
Get Started
Would you like to try file transfer server that supports FTPS and SFTP as well as other protocols? Try the free, fully-functional evaluation edition of JSCAPE MFT Server today.