Robert McMurray's Blog [MSFT]

Discussing IIS, FTP, WebDAV, FPSE, WMI, ADSI, ISAPI, ASP, Java, FastCGI, etc. ;-)

FTP Clients - Part 2: Explicit FTPS versus Implicit FTPS

FTP Clients - Part 2: Explicit FTPS versus Implicit FTPS

  • Comments 12

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 only
for 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 only
for 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
  • I’ve been working with this a lot recently and thought I’d share some of what I found with you. You'll

  • 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.

  • 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

  • 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-status
    2008-12-17 00:42:59 - ControlChannelOpened - - 0
    2008-12-17 00:43:02 - USER NonSecureUser 331 0
    2008-12-17 00:43:05 SERVER\NonSecureUser PASS *** 230 0
    2008-12-17 00:43:08 SERVER\NonSecureUser EPSV - 229 0
    2008-12-17 00:43:08 SERVER\NonSecureUser DataChannelOpened - - 0
    2008-12-17 00:43:08 SERVER\NonSecureUser DataChannelClosed - - 0
    2008-12-17 00:43:08 SERVER\NonSecureUser NLST -l 226 0
    2008-12-17 00:43:10 SERVER\NonSecureUser QUIT - 221 0
    2008-12-17 00:43:10 SERVER\NonSecureUser ControlChannelClosed - - 0

    You'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-status
    2008-12-17 00:43:33 - ControlChannelOpened - - 0
    2008-12-17 00:43:33 - AUTH TLS 234 0
    2008-12-17 00:43:34 - PBSZ 0 200 0
    2008-12-17 00:43:34 - PROT P 200 0
    2008-12-17 00:43:43 - USER SecureUser 331 0
    2008-12-17 00:43:46 SERVER\SecureUser PASS *** 230 0
    2008-12-17 00:43:50 SERVER\SecureUser EPSV - 229 0
    2008-12-17 00:43:50 SERVER\SecureUser DataChannelOpened - - 0
    2008-12-17 00:44:50 SERVER\SecureUser DataChannelClosed - - 0
    2008-12-17 00:43:50 SERVER\SecureUser NLST -l 226 0
    2008-12-17 00:43:52 SERVER\SecureUser QUIT - 221 0
    2008-12-17 00:44:52 SERVER\SecureUser ControlChannelClosed - - 0

    You'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-status
    2008-12-17 01:01:01 - ControlChannelOpened - - 0
    2008-12-17 01:01:07 - USER SecureUser 331 0
    2008-12-17 01:01:10 SERVER\SecureUser PASS *** 230 0
    2008-12-17 01:01:12 SERVER\SecureUser EPSV - 229 0
    2008-12-17 01:01:12 SERVER\SecureUser DataChannelOpened - - 0
    2008-12-17 01:01:12 SERVER\SecureUser DataChannelClosed - - 0
    2008-12-17 01:01:12 SERVER\SecureUser NLST -l 226 0
    2008-12-17 01:01:17 - AUTH TLS 234 0
    2008-12-17 01:01:17 - PBSZ 0 200 0
    2008-12-17 01:01:17 - PROT P 200 0
    2008-12-17 01:01:26 - EPSV - 530 776
    2008-12-17 01:01:26 - PASV - 530 776
    2008-12-17 01:01:40 - QUIT - 20
    2008-12-17 01:01:40 - ControlChannelClosed - - 0

    So 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.

  • Robert,

    Thanks for the great article.

    I'm trying to set up my first FTPS site on Windows Server 2008.  My hang up is that I'm not sure which ports I need open.  After reading your article and Alun Jones' comments about FTPS, it seems explicit FTPS is the way to go.

    To enable explicit FTPS, is TCP port 21 all that needs to be open on the firewall?  

    Thanks,

    Aaron

  • Yes - explicit FTPS is definitely the way to go.

    The following page has some firewall related information:

    http://learn.iis.net/page.aspx/309/configuring-ftp-firewall-settings/

    If you're using the Windows Firewall, that article will lead you through configuring any settings that might need.

  • Hi, Did you ever get Explicit FTPS working over NATed Network ? I'm trying to get Explicit FTPS working with my firewall [m0n0wall] and it always timed out when initializing tls, when i tried it from the internal network [direct route] it will work just fine.

    BTW Implicit works through the firewall ok, i just add port 990 to the firewall and implicit FTPS will connect just fine,

    oh and I use filezilla for the client.

  • Hi adi, I got Explicit FTPS working through ISA Server 2006, but it's been a while. I think that I had to configure it by port and not explicitly as FTP tunneling. For example, in the Windows Firewall article that I mentioned earlier, you have to turn off stateful FTP inspection if you're going to use Explicit FTPS. I don't know much about m0n0wall, but if it's performing stateful packet inspection (and it probably is) then that might need to be disabled for FTPS. (Or you can just use implicit.)

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

  • Why the connection is broken, when I transfer a lot of files through FTPS?

    Can you tell me?

  • 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?

  • 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.

Page 1 of 1 (12 items)
Leave a Comment
  • Please add 3 and 5 and type the answer here:
  • Post