The Difficulty In Doing Something Simple

According to my watch, it's 2011.  The popular and pervasive protocols telnet and FTP were first codified in RFCs around 1970.  At the time it may have made sense to use protocols which provided no encryption, and in some cases it still does today.  However, while many organizations try to limit the use of clear text protocols these days it sometimes seems like it is more difficult than it really should be to limit their use when security concerns are at play.

It would be silly to argue that FTP should be banned from use.  There are simply some cases where it makes sense- most notably when you want to provide access to large file repositories using a protocol that every OS will support.  However, in general, these cases involve repositories of public information.  Whether it's ISOs, PDFs, image files, or catalogs of programs/code being released for public download, FTP can be a good solution.

Where it doesn't make sense to use these, in my opinion, is in any case where the service is going to require a login.  I don't think I'm saying anything outrageous there.  I think a lot of organizations have banned the use of telnet simply because it has generally been used as a way to log in to a remote device and work from the command prompt.  In other words, the use case for telnet has been one where authentication is required and access to a CLI is granted as a result.  Generally, doing that over telnet is a bad idea.  In addition SSH has been widely implemented into almost any device that would have (or still does) come with telnet.

FTP is a different story though.  As I said above, it would be silly to ban it entirely since sometimes it's the right solution.  So the story of eliminating telnet use, which is somewhat akin to the story of efforts to eliminate smallpox, is black and white.  It's straight-forward.  We don't have a use case wherein telnet is an acceptable option.  However, for FTP we do.  The unfortunate side-effect is that there seems to be a psychological acceptance of FTP in almost all use cases as a result.  In other words, because no one would be silly enough to say "FTP is bad" with no caveats or exceptions to the rule, people outside of security haven't had any level of indoctrination regarding that idea.

So, you have a question which should be simple to answer: when is a clear-text protocol acceptable to use?  Not when credentials are being passed that's for sure.  And not in any case where the data being transferred is anything except public.  Yet, I still have conversations regarding system architectures where FTP is being used to transfer data and people claim the data is "not really sensitive," but they still want to use authentication on the FTP server to protect the data.  My response is always, "well the data itself might not be sensitive, but the credentials you are passing are."  Also, if the data is not sensitive, then what is the need for authentication?  It's not really public, then.  At best it's just non-sensitive.

It just seems like it shouldn't be that hard to get people to realize the dangers of using clear text protocols. However, the widespread, justified use of FTP seems to have lulled people thinking it's more broadly acceptable in all (or at least most) situations.  Another part of the problem though is that SSH has replaced telnet in a way that is basically seamless.  OSes support it out of the box, or there is a free, open-source solution available, and the same goes for SSH clients.

FTP is a little trickier to replace.  There are two primary, viable solutions: SFTP which is a file transfer protocol within SSH; or FTPS which is FTP within an SSL/TLS connection.  SFTP is natively supported on any *nix machine running SSH, and any *nix machine should have a client freely available.  However, if you want to use a Windows machine as a client, your options are limited.  Further, if you want to run the server on a Windows machine, you are limited in your choices of software, and will likely need to pay for something you're comfortable with.  Windows does support FTPS as a free, native server, but this is only in Windows 2008.  Again, you will still need 3rd party software to function as a client, but you have a strong field of free options from which to choose.

So, it's somewhat understandable why the use of FTP has not been deprecated in the same way telnet has.  However, it's not an intractable problem.  It still seems to me that the problem is largely psychological.  People think of FTP as being in widespread use so it seems like it should be easy to justify using it even when there are very good reasons not to use it.  Maybe I'm the only one who's come across this issue, but I'd be interested in hearing anyone else's thoughts on the topic.

More from Our Cybersecurity Experts