ProFTPD mini-HOWTO - SSL/TLS

## SSL/TLS

NOTE: This mini-howto is definitely incomplete. Please contact me with suggestions, questions, requests, etc. for what you would like to see covered here. Thanks!

      http://www.faqs.org/ftp/internet-drafts/draft-murray-auth-ftp-ssl-12.txt

Example `mod_tls` configuration:

      <IfModule mod_tls.c>
        TLSEngine on
        TLSLog /var/ftpd/tls.log
        TLSProtocol TLSv1

        # Are clients required to use FTP over TLS when talking to this server?
        TLSRequired off

        # Server's certificate
        TLSRSACertificateFile /etc/ftpd/server.cert.pem
        TLSRSACertificateKeyFile /etc/ftpd/server.key.pem

        # CA the server trusts
        TLSCACertificateFile /etc/ftpd/root.cert.pem

        # Authenticate clients that want to use FTP over TLS?
        TLSVerifyClient off
      </IfModule>

Debugging
`ssldump`

Frequently Asked Questions

Question: Where can I find a list of clients that support FTPS?
Answer: This page is a good FTPS resource:

      http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html

including the list of FTPS clients. On a related note, there have been some reports that Debian's `ftp-ssl` client has a few bugs; using Peter Runestig's `ftp-tls` is known to work.

Note, though, that there are known issues with some FTPS clients:

      http://www.runestig.com/osp.html#NOTE1

Question: How come `mod_tls` does not support "implicit" FTPS (i.e. automatically encrypting sessions on port 990)?
Answer: The short answer is because the Draft no longer specifies support for such a mode. Here is a description of why the alternatives to the current mode (client-requested encryption using standard control channel) are "bad".

The long answer is covered in Eric Rescorla's excellent book, "SSL and TLS". There tend to be two different strategies used when adding new features to a protocol: separate ports for protocol variants, or upward negotiation. Port 443 for HTTPS is an example of the separate ports strategy. The drawback to the separate ports approach is that there is a finite number of ports available, and so this approach does not scale well. The benefit is that use of separate ports tends to require smaller changes to client and server code. Upward negotiation is more flexible, but requires that the protocol support some sort of feature negotiation or extension discovery, allowing clients and servers to easily agree to negotiate "upward" into a secure channel. The authors of the FTPS Draft felt that upward negotiation was the more appropriate of these two approaches for encrypting FTP channels.

Question: Can I require TLS on a per-user basis?
Answer: No. The IETF Draft specifying FTP over TLS requires that the TLS handshake occur before the client sends the `USER` command. This means that the server does not know the name of the user that the client will be using when the TLS session is established. It is possible that the client's certificate, if one is even presented, may contain information the server may use to map that certificate to a user, but such mapping is not currently supported by `mod_tls`. Note that this is also the reason the `TLSRequired` directive cannot appear in the `<Anonymous>` context: anonymous logins are based on the `USER` command.

Question: Why does `mod_tls` break FXP transfers?
Answer: The Draft specifying FTP over SSL explicitly omits site-to-site transfers. A TLS session is established between the client and the server on the control channel and, to save on the expensive overhead of TLS handshake, that session is reused for encrypting traffic on the data channel. In a site-to-site transfer, the client opens two control channels, one with each server, and then arranges for those servers to open a data channel between themselves. However, since the servers have not established a TLS session between themselves, that opening of the data channel fails.

Note that the above happens only if the server requires that TLS be used on data connections (e.g. `TLSRequired` is either on or data), of if the client tells the server that the client will be using TLS on the data connections (e.g. when it sends the `AUTH` command with an argument of `TLS-P`). Without these conditions, site-to-site transfers can occur normally, albeit unencrypted. Encrypted site-to-site transfers are not supported.

Question: How come `mod_tls` does not support SSLv2?
Answer: Various defects have been found in the SSLv2 protocol. Some legacy sites need to support SSLv2 for their HTTP traffic, in spite of its flaws. Use of FTP over TLS is fairly new, however, and there is not much "legacy" in that regard; it was felt that, as `mod_tls` aims to provide strong cryptographic security, supporting a known bad protocol is a Bad Idea.

Question: Using `mod_tls`, FTP sessions through my firewall now no longer work. What's going on?
Answer: The short answer is that FTPS and firewalls (and devices performing NAT) do not interact well. The control connection happens on a well-known port, and has no issues; it is the data connection that poses problems for FTP-aware firewalls. In a non-FTPS session, the firewall can inspect the FTP server's responses on the control connection to a client's `PASV` or `PORT` command, and thus know which on which ports/addresses the data connection will be established. In an FTPS session, though, those control connection messages are encrypted (that is the point of using FTPS, right?), and so the FTP-aware firewall cannot peek. Hence, it cannot know which on which ports the data connection will be established. For firewalls that are configured to always allow a certain range of ports (such as might be configured using the `PassivePorts` directive), FTPS should function without issue.

Unfortunately, this is a rather intractable--and known--issue. Earlier versions of the Draft defining FTPS used to allow something known as "implicit" FTPS, by which a client could contact a well-known port (akin to port 443 for HTTPS; FTPS used port 990) and the server, simply because the client contacted that certain port, would automatically encrypt the session. This approach has several drawbacks (the reason why it was removed from later versions of the Draft), but it did allow for simple TCP proxying. There has been no replacement.

Question: Sometimes my encrypted transfers are slow. Is there a way to speed them up?
Answer: There have been reports that increasing the tunable buffer size (using the `--enable-buffer-size` option of the `configure` script) to 8192 increases transfer speeds, most notably on very high speed networks. Increasing the buffer size does not appear to affect normal FTP transfers (in fact, it may benefit them as well, depending on the client).

Last Updated: $Date: 2004/04/10 18:01:18 $