Freigeben über

FTP Clients - Part 2: Explicit FTPS versus Implicit FTPS

  • Artikel

In part 2 of my series on FTP clients, I thought it would be best to have a discussion about the differences between Implicit FTPS and Explicit FTPS. In my recent "FTP Clients - Part 1: Web Browser Support" blog post, I referenced Implicit and Explicit FTPS with a link to my Using FTP Over SSL walkthrough. But it occurred to me that some people may not understand the difference between the two, and my upcoming blog posts are going to build upon that knowledge, so I thought that a quick discussion of these two technologies would be prudent.

FTP over SSL (FTPS)

One of the many limitations of the File Transfer Protocol (FTP) is a general lack of security; e.g. user names and passwords are transmitted in clear text, data is transferred with no encryption, etc. In order to address this situation, FTP over SSL (FTPS) was introduced in Requests for Comments (RFC) article 2228 - FTP Security Extensions, and expanded in RFC 4217 - Securing FTP with TLS to address Transport Layer Security (TLS).

Following up on these RFC articles, the FTP service for Windows Server 2008 added support for FTPS, and the FTP SSL Settings Feature in the IIS Manager allows you to configure your FTPS settings to allow or require SSL, enforce 128-bit SSL, or customize your control/data channel SSL settings.

FTP SSL Settings

Explicit FTPS

Explicit FTPS is really what RFCs 2228 and 4217 envisioned; basically the way this works is an FTP client connects over the control/command channel (usually on port 21), and then the client can negotiate SSL for either the command/control channel or the data channel using new FTP commands like AUTH, PROT, CCC, etc.

The FTP service for Windows Server 2008 allows customized settings for both the command/control channel and the data channel through the Advanced SSL Policy dialog:

Advanced SSL Policy

There are several ways that Explicit FTPS might be implemented depending on your business needs:

Control Channel Data Channel Notes
Allow Allow This configuration allows the client to decide whether any part of the FTP session should be encrypted.
Require onlyfor credentials Allow This configuration protects your FTP client credentials from electronic eavesdropping, and allows the client to decide whether data transfers should be encrypted.
Require onlyfor credentials Require This configuration requires that the client's credentials must be secure, and then allows the client to decide whether FTP commands should be encrypted. However, all data transfers must be encrypted.
Require Require This configuration is the most secure - the client must negotiate SSL using the FTPS-related commands before other FTP commands are allowed, and all data transfers must be encrypted.

Implicit FTPS

Implicit FTPS takes SSL one step further than simply requiring that SSL-related commands must be sent first like you can with Explicit SSL; with Implicit FTPS, an SSL handshake must be negotiated before any FTP commands can be sent by the client. In addition, even though Explicit FTPS allows the client to arbitrarily decide whether to use SSL, Implicit FTPS requires that the entire FTP session must be encrypted. Basically the way that Implicit FTPS works is that an FTP client connects to the command/control channel, in this case using port 990, and immediately performs an SSL handshake; after SSL has been negotiated, additional FTP commands for the session can be sent by the FTP client.

Using FTPS in FTP service for Windows Server 2008 follows the Internet Assigned Numbers Authority (IANA) specification that the Implicit FTPS command/control channel is on port 990 and the Implicit FTPS data channel is on port 989.

Using FTPS in Windows Server 2008

Here's the way that you specify which type of FTP over SSL (FTPS) that you are using in Windows Server 2008:

  • If you enable FTPS and you assign the FTP site to the default port of 21, you are using Explicit SSL.
  • If you enable FTPS and you assign the FTP site to port 990, you are using Implicit SSL.
  • In point of fact, if you enable FTPS and you assign the FTP site to any port other than port 990, you are always using Explicit SSL.

Note: If you are using FTP on any ports other than the defaults of 21/20 and 990/989, you must make sure that those ports are not already assigned by IANA to another protocol. For more information, see the list of assigned port numbers on IANA's web site.

Parting Thoughts

Choosing whether to use Explicit FTPS over Implicit FTPS is a personal choice, and generally this choice may depend on your business needs or your FTP client. In several FTP clients that I've tested, the FTP client chooses one form of FTPS over another as the default method, and the FTP client may require some manual configuration to use the other.

Shortly after shipping the FTP service for Windows Server 2008 we discovered an issue where the FTP service was not cleaning up Implicit SSL connections properly, and we issued a hotfix rollup package for the FTP service that is discussed in Microsoft Knowledge Base article 955136.

I hope this helps to clear things up a bit. ;-]

Comments

  • Anonymous
    November 12, 2008
    I’ve been working with this a lot recently and thought I’d share some of what I found with you. You'll

  • Anonymous
    December 15, 2008
    Robert, you left out what I think is an important point - Implicit SSL is considered "deprecated" in the FTP over SSL / TLS standard. As such, at some point in the future you may find it no longer supported or extended; you may even find that port 990 is re-assigned to some other protocol. Speaking of port 990 being re-assigned to some other protocol, note that the Windows Mobile Device Support steals port 990, making Implicit SSL fail to bind in some instances.

  • Anonymous
    December 16, 2008
    Hi, I've set Control Channel= Allow Data Channel = Allow How can i make sure username and password are encrypted. Is there any switch in log file which tell it is encrypted?? Thanks Jas

  • Anonymous
    December 16, 2008
    Hi Jas, There is a way to tell if the user's credentials were encrypted by looking at the cs-method with regard to the order of the AUTH and USER/PASS verbs. For example, here is a non-encrypted login: #Software: Microsoft Internet Information Services 7.0#Version: 1.0#Date: 2008-12-17 00:42:59#Fields: date time cs-username cs-method cs-uri-stem sc-status sc-win32-status2008-12-17 00:42:59 - ControlChannelOpened - - 02008-12-17 00:43:02 - USER NonSecureUser 331 02008-12-17 00:43:05 SERVERNonSecureUser PASS *** 230 02008-12-17 00:43:08 SERVERNonSecureUser EPSV - 229 02008-12-17 00:43:08 SERVERNonSecureUser DataChannelOpened - - 02008-12-17 00:43:08 SERVERNonSecureUser DataChannelClosed - - 02008-12-17 00:43:08 SERVERNonSecureUser NLST -l 226 02008-12-17 00:43:10 SERVERNonSecureUser QUIT - 221 02008-12-17 00:43:10 SERVERNonSecureUser ControlChannelClosed - - 0You'll notice that the client sends USER and PASS with no AUTH command. The following example shows a client that negotiates TLS as part of the login: #Software: Microsoft Internet Information Services 7.0#Version: 1.0#Date: 2008-12-17 00:43:33#Fields: date time cs-username cs-method cs-uri-stem sc-status sc-win32-status2008-12-17 00:43:33 - ControlChannelOpened - - 02008-12-17 00:43:33 - AUTH TLS 234 02008-12-17 00:43:34 - PBSZ 0 200 02008-12-17 00:43:34 - PROT P 200 02008-12-17 00:43:43 - USER SecureUser 331 02008-12-17 00:43:46 SERVERSecureUser PASS *** 230 02008-12-17 00:43:50 SERVERSecureUser EPSV - 229 02008-12-17 00:43:50 SERVERSecureUser DataChannelOpened - - 02008-12-17 00:44:50 SERVERSecureUser DataChannelClosed - - 02008-12-17 00:43:50 SERVERSecureUser NLST -l 226 02008-12-17 00:43:52 SERVERSecureUser QUIT - 221 02008-12-17 00:44:52 SERVERSecureUser ControlChannelClosed - - 0You'll notice that AUTH succeeds prior to USER and PASS. By contrast, the following example shows a client that issues AUTH after having logged in with USER and PASS: #Software: Microsoft Internet Information Services 7.0#Version: 1.0#Date: 2008-12-17 01:01:01#Fields: date time cs-username cs-method cs-uri-stem sc-status sc-win32-status2008-12-17 01:01:01 - ControlChannelOpened - - 02008-12-17 01:01:07 - USER SecureUser 331 02008-12-17 01:01:10 SERVERSecureUser PASS *** 230 02008-12-17 01:01:12 SERVERSecureUser EPSV - 229 02008-12-17 01:01:12 SERVERSecureUser DataChannelOpened - - 02008-12-17 01:01:12 SERVERSecureUser DataChannelClosed - - 02008-12-17 01:01:12 SERVERSecureUser NLST -l 226 02008-12-17 01:01:17 - AUTH TLS 234 02008-12-17 01:01:17 - PBSZ 0 200 02008-12-17 01:01:17 - PROT P 200 02008-12-17 01:01:26 - EPSV - 530 7762008-12-17 01:01:26 - PASV - 530 7762008-12-17 01:01:40 - QUIT - 202008-12-17 01:01:40 - ControlChannelClosed - - 0So a simple way to check is to use logparser or similar tools to check your logs and make sure that client credentials are encrypted by making sure that AUTH precedes the USER and PASS verbs. You can force secure credentials by setting the control channel to "Require only for credentials", but the truth is - most clients probably won't switch back to non-encrypted after logging in, so you'll have a lot of sessions that are fully-encrypted even though you just want to protect their login credentials.

  • Anonymous
    December 17, 2008
    The comment has been removed

  • Anonymous
    December 17, 2008
    The comment has been removed

  • Anonymous
    October 24, 2010
    The comment has been removed

  • Anonymous
    October 26, 2010
    The comment has been removed

  • Anonymous
    October 27, 2010
    Ok, I'll try looking around on how to disable stateful inspection , thanks for the tip

  • Anonymous
    July 19, 2012
    Why the connection is broken, when I transfer a lot of files through FTPS? Can you tell me?

  • Anonymous
    January 25, 2014
    Hi Robert, I have added Port 990 is in my HW firewall exception list, I am able to connect FTP Server through FileZila but not able to list the directory. Do I need to Open Port 989 in Firewall also?

  • Anonymous
    December 03, 2014
    Implicit FTPS should not be used as it is not formally defined in any RFC (RFC 4217 does not even mention it). Maybe the article could be updated to discourage the use of implicit FTPS.

  • Anonymous
    March 18, 2015
    Robert, I stumble upon your blog and you have lots about FTPing.. I was wondering if you could help me -- I am using CoreFTP  LE V2.1 and im using a scrip that calls coreftp.exe .. "C:Program FilesCoreFTP>corecmd.exe sftp://ZZZZZZZZZZ:XXXXXXXXXXX@pfsdrop.barnesandnoble.com:8022  -O -s -log [MyQFileNew].sftp' For some reason I am getting the below error..And was wondering if it was ME or the clients server..and also IF you may know a solution for it. pfsdrop.barnesandnoble.com [8022] connecting... SSH-2.0-mod_sftp/0.9.7 client -> aes256-ctr server -> aes256-ctr 0e:58:1b:1b:b4:fd:f2:82:83:d6:b2:ea:75:06:20:93 ssh-rsa Sending password Disconnected Application error SFTP connection errorConnection Failedsent 130, recd 130 Total uploaded files:  0 Total uploaded data:  0 Total downloaded files:  0 Total downloaded data:  0 Thanks -Carlos

  • Anonymous
    October 07, 2015
    As mentioned in a number of places, Implicit Secure FTP is deprecated and should not be used.  This was at the request of the IETF who quickly worked out that following http and duplicating all port assignments with 'secure' versions didn't make sense.  (Not to mention the 'multi-homing' problem which required an update to TLS to get fixed.) Firewalls are always going to be tricky - see my old draft for a discussion of some of the issues ... tools.ietf.org/.../draft-fordh-ftp-ssl-firewall-07