"FTPS" document finally makes it to RFC status.

News I’ve been waiting for for years – the document formally known as draft-murray-auth-ftp-ssl-16.txt has finally been released by the RFC editor as RFC 4217 – “Securing FTP with TLS


What exactly does this mean?  Technically, not very much – FTPS has been implemented by several FTP clients, servers and wrappers for several years.  I added FTPS support to WFTPD Pro back in 2001, after first expressing interest in doing so in 1997, but being held back by the lack of crypto support in Windows.


I nearly had it ready in 2000, but spent some time trying to debug an issue that turned out to be caused by a corrupted certificate issued by the Windows 2000 Server CA that I was testing against.  Let that be a lesson to you crypto developers – sometimes the code is right, and it’s the certs that are wrong!


A few minor things have changed since then in the document that is now RFC 4217, but almost nothing significant to the compatibility of FTPS offerings.


I will end with a brief FAQ for you – please let me know if there are any other questions you’d like to see answered:


1. What’s TLS, and what is its relation to SSL?


TLS is Transport Layer Security, and is the name of the protocol that grew from Netscape’s SSL and Microsoft’s PCT.  Most people still use the term “SSL”, but TLS is where all ongoing work is carried out by the IETF.


2. Is FTPS the official term?


No – the RFC is “Securing FTP with TLS”, and perhaps the official term should be “AUTH TLS”.  However, with the general public already familiar with the concept of “https” being the secured equivalent of “http”, the term “ftps” has sprung up in general use to describe an FTP transfer, or session, encrypted and/or authenticated with SSL or TLS.


3. How different is FTPS from HTTPS?


Quite significantly – HTTPS uses a separate port for incoming SSL connections (usually port 443), compared to the port for unprotected HTTP connections (usually port 80).  Because FTP is (and has always been) a session-based protocol, it allows the client to “negotiate up” to SSL or TLS security through the use of the AUTH command described in RFC 2228.


Note also that FTP uses two channels – a control channel and a data channel, and that these channels can be secured – or left unsecured – almost independently.  HTTPS is secured from the moment you connect to the HTTPS port, until you close down the connection.  FTP is secured on the control channel from the moment you send an “AUTH TLS” or “AUTH SSL” command, until you log out; the data channel is not necessarily secured by default, and security on the data channel can be turned on or off using the PROT command, with parameters “C” for “Clear” or “P” for “Private”.


FTPS always authenticates the server through its certificate, and can be configured to authenticate the client by certificate, or by USER / PASS commands supplying username and password.  HTTP and HTTPS have several other methods of authentication (none of which bear much examination at the moment) – NTLM CHAP, Basic, Digest, etc, etc.


4. What about SFTP?  What’s that?


I get to answer this question a lot.  With all these acronyms getting thrown around, it’s easy to get confused.  Many people automatically assume that any acronym including the letters “FTP” refer to protocols based on FTP.  Obviously, that’s why “FTPS” was chosen as an informal description of “Securing FTP with TLS”.  Unfortunately, others may create confusing acronyms by including the FTP letters, either by accident or on purpose.  One such confusion was always “TFTP – Trivial File Transfer Protocol”.  This is about as far from FTP as you can get, and still be associated with transferring files from one machine to the other.


The same is true of “SFTP” – it’s a file transfer extension to “SSH”.  As that sentence implies, to do an SFTP file transfer, you need to have an SSH connection in place.  This isn’t always practical.

Just another Microsoft MVPs site