RFC 4217 defines FTP over SSL/TLS:
http://www.faqs.org/rfcs/rfc4217.htmlThe
mod_tls module for proftpd is an implementation
of RFC 4217.
RFC 2228 defines FTP Security Extensions, of which mod_tls is one implementation. Another
such RFC 2228 implementation is the mod_gss module, available
from SourceForge.
Example mod_tls configuration:
<IfModule mod_dso.c>
# If mod_tls was built as a shared/DSO module, load it
LoadModule mod_tls.c
</IfModule>
<IfModule mod_tls.c>
TLSEngine on
TLSLog /var/ftpd/tls.log
# Support both SSLv3 and TLSv1
TLSProtocol SSLv3 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
# Allow SSL/TLS renegotiations when the client requests them, but
# do not force the renegotations. Some clients do not support
# SSL/TLS renegotiations; when mod_tls forces a renegotiation, these
# clients will close the data connection, or there will be a timeout
# on an idle data connection.
TLSRenegotiate none
</IfModule>
Debugging
There are a couple of tools available for debugging and analysing FTPS
traffic. One of the easiest to use is the s_client application, part of OpenSSL.
The following examples assume that proftpd+mod_tls is listening
on 127.0.0.1, port 21:
# openssl s_client -connect 127.0.0.1:21 -starttls ftp
CONNECTED(00000003)
depth=1 /CN=castaglia3-serverCA/C=US/emailAddress=tj@castaglia.org/O=Castaglia/OU=Castaglia Research and Development/OU=TJ Saunders/ST=Washington
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/CN=castaglia3-server/C=US/emailAddress=tj@castaglia.org/O=Castaglia/OU=Castaglia Research and Development/OU=TJ Saunders/ST=Washington
i:/CN=castaglia3-serverCA/C=US/emailAddress=tj@castaglia.org/O=Castaglia/OU=Castaglia Research and Development/OU=TJ Saunders/ST=Washington
1 s:/CN=castaglia3-serverCA/C=US/emailAddress=tj@castaglia.org/O=Castaglia/OU=Castaglia Research and Development/OU=TJ Saunders/ST=Washington
i:/CN=castaglia3/C=US/ST=Washington/L=Seattle/O=Castaglia/OU=Castaglia Research and Development/OU=TJ Saunders/emailAddress=tj@castaglia.org
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/CN=castaglia3-server/C=US/emailAddress=tj@castaglia.org/O=Castaglia/OU=Castaglia Research and Development/OU=TJ Saunders/ST=Washington
issuer=/CN=castaglia3-serverCA/C=US/emailAddress=tj@castaglia.org/O=Castaglia/OU=Castaglia Research and Development/OU=TJ Saunders/ST=Washington
---
Acceptable client certificate CA names
/CN=castaglia3-clientCA/C=US/emailAddress=tj@castaglia.org/O=Castaglia/OU=Castaglia Research and Development/OU=TJ Saunders/ST=Washington
/CN=castaglia3/C=US/ST=Washington/L=Seattle/O=Castaglia/OU=Castaglia Research and Development/OU=TJ Saunders/emailAddress=tj@castaglia.org
/CN=castaglia3-clientCA/C=US/emailAddress=tj@castaglia.org/O=Castaglia/OU=Castaglia Research and Development/OU=TJ Saunders/ST=Washington
/CN=castaglia3/C=US/ST=Washington/L=Seattle/O=Castaglia/OU=Castaglia Research and Development/OU=TJ Saunders/emailAddress=tj@castaglia.org
---
SSL handshake has read 3731 bytes and written 344 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: D1F2E7C001BCFE57D797F34BD1518BDCC6160106D56A238CC0F957337C093435
Session-ID-ctx:
Master-Key: F8EE2812270E8FCD87D1B26F20546EF9BABAE40F36BC6F8DF45B0E2F089571E731EAFAEA5E61BCA7D9D204BE06F28B21
Key-Arg : None
Start Time: 1232997620
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
220 ProFTPD 1.3.2rc4 Server (TJ's FTPS Server) [127.0.0.1]
quit
221 Goodbye.
read:errno=0
Note that the "verify error" message is not of particular concern for us,
since we are not using s_client to verify the server's
certificate in this example.
The parts of the s_client output which are of particular interest
are the highlighted "Certificate chain" and "Acceptable client certificate CA
names" sections.
The "Certificate chain" section shows the certificate chain/trust path, from
the server's certificate up through the root CA for that certificate. Note
that this assumes the certificates in the trust path are available on the
server. By default, OpenSSL constructs this certificate chain using the
server's certificate (configured using TLSRSACertificateFile or
TLSDSACertificateFile) and the trusted CA certificates configured
using TLSCACertificateFile and/or
TLSCACertificatePath. See the TLSCertificateChainFile
FAQ for more details on how to influence
the constructed certificate chain.
The "Acceptable client certificate CA names" section contains the list of
CAs that can issue certificates that mod_tls is willing to trust.
These CAs always come from the configured
TLSCACertificateFile and/or TLSCACertificatePath.
This list of acceptable client CAs is presented to the client whenever the
server is requesting the client's certificate (which is what
mod_tls does by default). If you use:
TLSOptions NoCertRequestthen the server will not send this list of acceptable client CAs; using
s_client in that case, you would see:
--- No client certificate CA names sent ---In case you're wondering, a list of CAs is sent to the client, rather than just a single CA, because this allows clients the ability to determine which certificate (as a client can have many) to use when talking to this particular server.
Another tool, slightly older, is ssldump. This tool is more like ethereal or
tcpdump for any SSL/TLS traffic; it is deliberately modeled after
tcpdump.
To use ssldump for watching your FTPS traffic, you will need
the server key file (for decrypting), and possibly root privileges (for
listening on the network interface). Here is an example where
ssldump is used to listen on the loopback interface
(lo0), port 21:
# sudo ssldump -d -k server.pem -i lo0 port 21
New TCP connection #1: localhost(64148) <-> localhost(21)
0.0423 (0.0423) S>C
---------------------------------------------------------------
220 ProFTPD 1.3.2rc4 Server (TJ's FTPS Server) [127.0.0.1]
---------------------------------------------------------------
0.0427 (0.0004) C>S
---------------------------------------------------------------
AUTH TLS
---------------------------------------------------------------
0.0430 (0.0002) S>C
---------------------------------------------------------------
234 AUTH TLS successful
---------------------------------------------------------------
1 1 0.0433 (0.0003) C>S SSLv2 compatible client hello
Version 3.1
cipher suites
Unknown value 0x39
Unknown value 0x38
Unknown value 0x35
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
SSL2_CK_3DES
Unknown value 0x33
Unknown value 0x32
Unknown value 0x2f
TLS_RSA_WITH_IDEA_CBC_SHA
SSL2_CK_IDEA
SSL2_CK_RC2
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
SSL2_CK_RC4
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
SSL2_CK_DES
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL2_CK_RC2_EXPORT40
TLS_RSA_EXPORT_WITH_RC4_40_MD5
SSL2_CK_RC4_EXPORT40
1 2 0.0658 (0.0225) S>C Handshake
ServerHello
Version 3.1
session_id[32]=
09 25 df 7a a8 e8 71 a2 9f 56 a6 7b dd 95 ac 67
7d 2e 81 b2 1c ca b4 5f 1e 95 13 47 01 28 20 19
cipherSuite Unknown value 0x39
compressionMethod NULL
1 3 0.0658 (0.0000) S>C Handshake
Certificate
1 4 0.0658 (0.0000) S>C Handshake
ServerKeyExchange
1 5 0.0658 (0.0000) S>C Handshake
CertificateRequest
certificate_types rsa_fixed_dh
certificate_types dss_fixed_dh
certificate_types rsa_sign
certificate_types dss_sign
certificate_authority
30 81 b8 31 1c 30 1a 06 03 55 04 03 13 13 63 61
73 74 61 67 6c 69 61 33 2d 63 6c 69 65 6e 74 43
41 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 1f
30 1d 06 09 2a 86 48 86 f7 0d 01 09 01 16 10 74
6a 40 63 61 73 74 61 67 6c 69 61 2e 6f 72 67 31
12 30 10 06 03 55 04 0a 13 09 43 61 73 74 61 67
6c 69 61 31 2b 30 29 06 03 55 04 0b 13 22 43 61
73 74 61 67 6c 69 61 20 52 65 73 65 61 72 63 68
20 61 6e 64 20 44 65 76 65 6c 6f 70 6d 65 6e 74
31 14 30 12 06 03 55 04 0b 13 0b 54 4a 20 53 61
75 6e 64 65 72 73 31 13 30 11 06 03 55 04 08 13
0a 57 61 73 68 69 6e 67 74 6f 6e
certificate_authority
30 81 c1 31 13 30 11 06 03 55 04 03 13 0a 63 61
73 74 61 67 6c 69 61 33 31 0b 30 09 06 03 55 04
06 13 02 55 53 31 13 30 11 06 03 55 04 08 13 0a
57 61 73 68 69 6e 67 74 6f 6e 31 10 30 0e 06 03
55 04 07 13 07 53 65 61 74 74 6c 65 31 12 30 10
06 03 55 04 0a 13 09 43 61 73 74 61 67 6c 69 61
31 2b 30 29 06 03 55 04 0b 13 22 43 61 73 74 61
67 6c 69 61 20 52 65 73 65 61 72 63 68 20 61 6e
64 20 44 65 76 65 6c 6f 70 6d 65 6e 74 31 14 30
12 06 03 55 04 0b 13 0b 54 4a 20 53 61 75 6e 64
65 72 73 31 1f 30 1d 06 09 2a 86 48 86 f7 0d 01
09 01 16 10 74 6a 40 63 61 73 74 61 67 6c 69 61
2e 6f 72 67
certificate_authority
30 81 b8 31 1c 30 1a 06 03 55 04 03 13 13 63 61
73 74 61 67 6c 69 61 33 2d 63 6c 69 65 6e 74 43
41 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 1f
30 1d 06 09 2a 86 48 86 f7 0d 01 09 01 16 10 74
6a 40 63 61 73 74 61 67 6c 69 61 2e 6f 72 67 31
12 30 10 06 03 55 04 0a 13 09 43 61 73 74 61 67
6c 69 61 31 2b 30 29 06 03 55 04 0b 13 22 43 61
73 74 61 67 6c 69 61 20 52 65 73 65 61 72 63 68
20 61 6e 64 20 44 65 76 65 6c 6f 70 6d 65 6e 74
31 14 30 12 06 03 55 04 0b 13 0b 54 4a 20 53 61
75 6e 64 65 72 73 31 13 30 11 06 03 55 04 08 13
0a 57 61 73 68 69 6e 67 74 6f 6e
certificate_authority
30 81 c1 31 13 30 11 06 03 55 04 03 13 0a 63 61
73 74 61 67 6c 69 61 33 31 0b 30 09 06 03 55 04
06 13 02 55 53 31 13 30 11 06 03 55 04 08 13 0a
57 61 73 68 69 6e 67 74 6f 6e 31 10 30 0e 06 03
55 04 07 13 07 53 65 61 74 74 6c 65 31 12 30 10
06 03 55 04 0a 13 09 43 61 73 74 61 67 6c 69 61
31 2b 30 29 06 03 55 04 0b 13 22 43 61 73 74 61
67 6c 69 61 20 52 65 73 65 61 72 63 68 20 61 6e
64 20 44 65 76 65 6c 6f 70 6d 65 6e 74 31 14 30
12 06 03 55 04 0b 13 0b 54 4a 20 53 61 75 6e 64
65 72 73 31 1f 30 1d 06 09 2a 86 48 86 f7 0d 01
09 01 16 10 74 6a 40 63 61 73 74 61 67 6c 69 61
2e 6f 72 67
ServerHelloDone
1 6 0.1005 (0.0346) C>S Handshake
Certificate
1 7 0.1005 (0.0000) C>S Handshake
ClientKeyExchange
1 8 0.1005 (0.0000) C>S ChangeCipherSpec
1 9 0.1005 (0.0000) C>S Handshake
1 10 0.1164 (0.0159) S>C ChangeCipherSpec
1 11 0.1164 (0.0000) S>C Handshake
1 12 1.7856 (1.6692) C>S application_data
1 13 1.7856 (0.0000) C>S application_data
1 14 1.7861 (0.0004) S>C application_data
1 1.7866 (0.0004) S>C TCP FIN
1 15 1.7868 (0.0002) C>S Alert
As you can see, the level of granularity used by ssldump is on
the level of each SSL/TLS packet; while useful in some cases, I suspect that
using openssl s_client will provide most of the information you
will want in figuring out your certificate and verification issues.
Question: How do I generate the certificate files used
by
Question: Does FTPS protect both the control connection
and the data connections?
The long answer is, of course, that it depends. In the case of
Question: Where can I find a list of clients that
support FTPS?
Note, though, that there are known issues with some FTPS clients:
Question: How come
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.
All that said, in ProFTPD 1.3.3rc2, the
Question: Can I require TLS on a per-user basis?
However, in 1.2.10rc2, the
Question: When I use the following in my
Question: Why does
Note that the above happens only if the server requires that TLS be used on data
connections (e.g.
Question: How come
Question: Using
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.
To attempt to deal with the above issue, the RFC for FTP over SSL/TLS
suggests using the
Note that in order to configure the
Question: Sometimes my encrypted transfers are slow.
Is there a way to speed them up?
Question: I can login using FTPS, but I cannot see
any directories. Why not?
The following may also appear in the
You may also see the following appear in the
Question: Using FTPS, after uploading a very large file,
my next directory listing fails:
By default,
This means that 5 minutes or more into an FTPS session, even if your FTPS
client reused an SSL session ID, the OpenSSL internal session cache will
time out that SSL session ID. The next time your FTPS client goes to reuse
that session ID for a data transfer,
Fixing this situation requires two parts: a) the ability to change
the cache timeout used for the OpenSSL internal session cache, and b)
renegotiating the SSL session ID with the FTPS client periodically, to keep
the SSL session ID up-to-date in the session cache.
The first part, configuring the session cache timeout for the OpenSSL internal
session cache, is only possible in ProFTPD 1.3.4rc2 and later (see
Bug#3580). The
No matter how long you configure the cache timeout, eventually you will have
a session which lasts longer than that timeout. Which brings us to the second
part of the solution: i>and data connections. If you have:
Question: Where can I find a list of clients that
support FTPS?
Note, though, that there are known issues with some FTPS clients:
Question: How come
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.
All that said, in ProFTPD 1.3.3rc2, the
Question: Can I require TLS on a per-user basis?
However, in 1.2.10rc2, the
Question: When I use the following in my
Question: Why does
Note that the above happens only if the server requires that TLS be used on data
connections (e.g.
Question: How come
Question: Using
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.
To attempt to deal with the above issue, the RFC for FTP over SSL/TLS
suggests using the
Note that in order to configure the
Question: Sometimes my encrypted transfers are slow.
Is there a way to speed them up?
Question: I can login using FTPS, but I cannot see
any directories. Why not?
The following may also appear in the
You may also see the following appear in the
Question: Using FTPS, after uploading a very large file,
my next directory listing fails:
By default,
This means that 5 minutes or more into an FTPS session, even if your FTPS
client reused an SSL session ID, the OpenSSL internal session cache will
time out that SSL session ID. The next time your FTPS client goes to reuse
that session ID for a data transfer,
Fixing this situation requires two parts: a) the ability to change
the cache timeout used for the OpenSSL internal session cache, and b)
renegotiating the SSL session ID with the FTPS client periodically, to keep
the SSL session ID up-to-date in the session cache.
The first part, configuring the session cache timeout for the OpenSSL internal
session cache, is only possible in ProFTPD 1.3.4rc2 and later (see
Bug#3580). The
No matter how long you configure the cache timeout, eventually you will have
a session which lasts longer than that timeout. Which brings us to the second
part of the solution: i>and data connections. If you have:
Question: Where can I find a list of clients that
support FTPS?
Note, though, that there are known issues with some FTPS clients:
Question: How come
The long answer is covered in Eric Rescorla's excellent book, "SSL and TLS". There tend to be two
differmod_tls?
Answer: The mod_tls module uses the
same certificate files as Apache's mod_ssl. The
mod_ssl documentation explains what the files are, how they
are used, and how to generate your own:
http://www.modssl.org/docs/2.7/ssl_faq.html
Question: Short answer: yes.
mod_tls, it depends on your TLSRequired setting.
If you use:
TLSRequired on
then you are configuring mod_tls to require SSL/TLS
protection for both control connections (e.g. protecting the username
and password used to log in) and data connections. If you have:
TLSRequired off
then it is up to the FTPS client whether both control and data connections
will be protected via SSL/TLS. Other TLSRequired settings
can be used to specify specific combinations: data connections only,
control connections only, authentication plus data data connections only,
etc. The TLSRequired
documentation has the
details.
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.
http://www.runestig.com/osp.html#NOTE1
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".
mod_tls module was
enhanced to support implicit FTPS via the UseImplicitSSL
TLSOption.
Answer: Prior to ProFTPD 1.2.10rc2, 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.
mod_tls module was modified to allow
such per-user TLS requirements. To do this, the AllowPerUser
parameter of the TLSOptions directive is used. For example,
the following example mod_tls configuration allows non-SSL
anonymous sessions, but requires SSL/TLS for all other sessions:
<IfModule mod_tls.c>
TLSEngine on
TLSRSACertificateFile ...
TLSCACertificateFile ...
TLSOptions AllowPerUser
TLSRequired on
<Anonymous ~ftp>
User ftp
Group ftp
UserAlias anonymous ftp
RequireValidShell off
# Note how TLSRequired is set to off here in the <Anonymous> context
TLSRequired off
</Anonymous>
</IfModule>
The modification also allows mod_ifsession-based conditions, so
that one can have settings like:
<IfGroup trusted>
TLSRequired off
</IfGroup>
However, there is a risk involved in using the AllowPerUser
option: it causes mod_tls not to enforce TLSRequired
until after the potentially sensitive USER and PASS commands have
been sent by the client. This allows clients, even when
TLSRequired on or TLSRequired ctrl are in effect,
to send the USER and PASS commands unencrypted. Depending on your
site's security needs, the ability to require SSL/TLS on a per-user basis
may or may not be worth the ability to require SSL/TLS for the USER and PASS
commands.
proftpd.conf:
TLSRequired on # or "TLSRequired auth", or "TLSRequired auth+data"
TLSOptions AllowPerUser
I get the following error when I try to start proftpd:
cannot enforce both 'TLSRequired auth' and 'TLSOptions AllowPerUser' at the same time
Answer: The reason this error occurs is because
you have a configuration which is impossible to support. The
TLSRequired setting (e.g. "on", "auth", or "auth+data")
requires that SSL/TLS be in use during authentication. But in order to
support the TLSOption AllowPerUser setting, the
mod_tls cannot require that SSL/TLS be in use during
authentication, since it does not know the user until after
authentication has completed. The requested configuration cannot be supported,
and thus the server will refuse to start.
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.
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.
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.
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.
CCC FTP command (Clear Command Channel). The CCC command makes an encrypted control channel
revert back to an unencrypted channel. This helps to solve data connection
problems in situations where network equipment (such as firewalls, routers,
NAT) peek at the control channel in order to open ports. By sending the
CCC command and unecrypting the control channel, the network
equipment can once again peek at the commands (i.e. PORT
and EPRT) in the control channel. Since the CCC command must
come after the client has logged in, the USER and
PASS commands on the control channel will still be protected by
SSL/TLS.
mod_tls module to allow use of
the CCC command by clients, the following must appear in your
proftpd.conf:
TLSRequired auth+data
See the TLSRequired description for more details.
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).
Answer: You have most likely configured
mod_tls to require SSL/TLS protection for data transfers as
well as control commands, by using:
TLSRequired on
However, if your FTPS client does not expect to handle encrypted data
transfers (and directory listings count as data transfers, as they are
sent over a data channel), you may see your client appear to hang, waiting
for data it can read. Make sure your client is prepared to handle the
security requirements you have configured on the server.
TLS for any data
transfers (which include directory listings):
client did not reuse SSL session, rejecting data connection (see the NoSessionReuseRequired TLSOptions parameter
This message appears because an additional security restriction that was
added in ProFTPD 1.3.3rc1. The TLSOptions documentation for this "NoSessionReuseRequired" option
describes the situation in more detail.
TLSLog on occasion:
PROT: unwilling to accept security parameter (C), declining
The PROT FTP command is used to set the protection level to
be used for data transfers. Some clients send a PROT command
with a security parameter of C, meaning "Clear",
which effectively tells the server not to protect data transfers. The
mod_tls module will refuse the C security parameter
if, like above, there is "TLSRequired on" in your
proftpd.conf. This case also indicates a disagreement between
the client's security expectations and the security policy you have configured
on the server.
425 Unable to build data connection: Operation not permitted
The TLSLog contains:
client did not reuse SSL session, rejecting data connection (see the NoSessionReuseRequired TLSOptions parameter
but I do not want to use that option, and would like to rely on the
additional security protection provided by requring SSL session reuse.
And my FTPS client is correctly reusing SSL session IDs (as earlier data
transfers were working properly). So why is my data transfer failing after
the upload of a very large file?
Answer: The answer involves SSL session caching
on the server side (i.e. mod_tls), cache timeouts, and
session renegotiations.
mod_tls uses OpenSSL's "internal" session cache,
which is an in-memory caching of SSL session IDs. And by default, OpenSSL's
internal session cache has a cache timeout of 5 minutes; after that amount
of time in the internal session cache, a cached SSL session ID is considered
stale and is available for reuse.
mod_tls won't find it in
the OpenSSL internal session cache, and will think that your FTPS client is
not reusing the SSL session ID as is required, and fail the transfer.
TLSSessionCache directive was modified to allow a configuration such as:
TLSSessionCache internal: 1800
(Unfortunately, the ':' after "internal" is necessary.) This configures
mod_tls such that the OpenSSL internal session cache uses
a cache timeout of 1800 seconds (30 minutes), rather than the default of 300
seconds (5 minutes).
TLSRequired off
then it is up to the FTPS client whether both control and data connections
will be protected via SSL/TLS. Other TLSRequired settings
can be used to specify specific combinations: data connections only,
control connections only, authentication plus data data connections only,
etc. The TLSRequired
documentation has the
details.
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.
http://www.runestig.com/osp.html#NOTE1
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".
mod_tls module was
enhanced to support implicit FTPS via the UseImplicitSSL
TLSOption.
Answer: Prior to ProFTPD 1.2.10rc2, 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.
mod_tls module was modified to allow
such per-user TLS requirements. To do this, the AllowPerUser
parameter of the TLSOptions directive is used. For example,
the following example mod_tls configuration allows non-SSL
anonymous sessions, but requires SSL/TLS for all other sessions:
<IfModule mod_tls.c>
TLSEngine on
TLSRSACertificateFile ...
TLSCACertificateFile ...
TLSOptions AllowPerUser
TLSRequired on
<Anonymous ~ftp>
User ftp
Group ftp
UserAlias anonymous ftp
RequireValidShell off
# Note how TLSRequired is set to off here in the <Anonymous> context
TLSRequired off
</Anonymous>
</IfModule>
The modification also allows mod_ifsession-based conditions, so
that one can have settings like:
<IfGroup trusted>
TLSRequired off
</IfGroup>
However, there is a risk involved in using the AllowPerUser
option: it causes mod_tls not to enforce TLSRequired
until after the potentially sensitive USER and PASS commands have
been sent by the client. This allows clients, even when
TLSRequired on or TLSRequired ctrl are in effect,
to send the USER and PASS commands unencrypted. Depending on your
site's security needs, the ability to require SSL/TLS on a per-user basis
may or may not be worth the ability to require SSL/TLS for the USER and PASS
commands.
proftpd.conf:
TLSRequired on # or "TLSRequired auth", or "TLSRequired auth+data"
TLSOptions AllowPerUser
I get the following error when I try to start proftpd:
cannot enforce both 'TLSRequired auth' and 'TLSOptions AllowPerUser' at the same time
Answer: The reason this error occurs is because
you have a configuration which is impossible to support. The
TLSRequired setting (e.g. "on", "auth", or "auth+data")
requires that SSL/TLS be in use during authentication. But in order to
support the TLSOption AllowPerUser setting, the
mod_tls cannot require that SSL/TLS be in use during
authentication, since it does not know the user until after
authentication has completed. The requested configuration cannot be supported,
and thus the server will refuse to start.
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.
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.
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.
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.
CCC FTP command (Clear Command Channel). The CCC command makes an encrypted control channel
revert back to an unencrypted channel. This helps to solve data connection
problems in situations where network equipment (such as firewalls, routers,
NAT) peek at the control channel in order to open ports. By sending the
CCC command and unecrypting the control channel, the network
equipment can once again peek at the commands (i.e. PORT
and EPRT) in the control channel. Since the CCC command must
come after the client has logged in, the USER and
PASS commands on the control channel will still be protected by
SSL/TLS.
mod_tls module to allow use of
the CCC command by clients, the following must appear in your
proftpd.conf:
TLSRequired auth+data
See the TLSRequired description for more details.
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).
Answer: You have most likely configured
mod_tls to require SSL/TLS protection for data transfers as
well as control commands, by using:
TLSRequired on
However, if your FTPS client does not expect to handle encrypted data
transfers (and directory listings count as data transfers, as they are
sent over a data channel), you may see your client appear to hang, waiting
for data it can read. Make sure your client is prepared to handle the
security requirements you have configured on the server.
TLS for any data
transfers (which include directory listings):
client did not reuse SSL session, rejecting data connection (see the NoSessionReuseRequired TLSOptions parameter
This message appears because an additional security restriction that was
added in ProFTPD 1.3.3rc1. The TLSOptions documentation for this "NoSessionReuseRequired" option
describes the situation in more detail.
TLSLog on occasion:
PROT: unwilling to accept security parameter (C), declining
The PROT FTP command is used to set the protection level to
be used for data transfers. Some clients send a PROT command
with a security parameter of C, meaning "Clear",
which effectively tells the server not to protect data transfers. The
mod_tls module will refuse the C security parameter
if, like above, there is "TLSRequired on" in your
proftpd.conf. This case also indicates a disagreement between
the client's security expectations and the security policy you have configured
on the server.
425 Unable to build data connection: Operation not permitted
The TLSLog contains:
client did not reuse SSL session, rejecting data connection (see the NoSessionReuseRequired TLSOptions parameter
but I do not want to use that option, and would like to rely on the
additional security protection provided by requring SSL session reuse.
And my FTPS client is correctly reusing SSL session IDs (as earlier data
transfers were working properly). So why is my data transfer failing after
the upload of a very large file?
Answer: The answer involves SSL session caching
on the server side (i.e. mod_tls), cache timeouts, and
session renegotiations.
mod_tls uses OpenSSL's "internal" session cache,
which is an in-memory caching of SSL session IDs. And by default, OpenSSL's
internal session cache has a cache timeout of 5 minutes; after that amount
of time in the internal session cache, a cached SSL session ID is considered
stale and is available for reuse.
mod_tls won't find it in
the OpenSSL internal session cache, and will think that your FTPS client is
not reusing the SSL session ID as is required, and fail the transfer.
TLSSessionCache directive was modified to allow a configuration such as:
TLSSessionCache internal: 1800
(Unfortunately, the ':' after "internal" is necessary.) This configures
mod_tls such that the OpenSSL internal session cache uses
a cache timeout of 1800 seconds (30 minutes), rather than the default of 300
seconds (5 minutes).
TLSRequired off
then it is up to the FTPS client whether both control and data connections
will be protected via SSL/TLS. Other TLSRequired settings
can be used to specify specific combinations: data connections only,
control connections only, authentication plus data data connections only,
etc. The TLSRequired
documentation has the
details.
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.
http://www.runestig.com/osp.html#NOTE1
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".