590
605
with a security parameter of <code>C</code>, meaning "Clear",
591
606
which effectively tells the server not to protect data transfers. The
592
607
<code>mod_tls</code> module will refuse the <code>C</code> security parameter
593
if, like above, there is "TLSRequired on" in your
608
if, like above, there is "TLSRequired on" in your
594
609
<code>proftpd.conf</code>. This case also indicates a disagreement between
595
610
the client's security expectations and the security policy you have configured
613
<p><a name="TLSErrorAfterLargeUpload">
614
<font color=red>Question</font>: Using FTPS, after uploading a very large file,
615
my next directory listing fails:
617
425 Unable to build data connection: Operation not permitted
619
The <code>TLSLog</code> contains:
621
client did not reuse SSL session, rejecting data connection (see the NoSessionReuseRequired TLSOptions parameter
623
but I do <i>not</i> want to use that option, and would like to rely on the
624
additional security protection provided by requring SSL session reuse.
625
And my FTPS client is correctly reusing SSL session IDs (as earlier data
626
transfers were working properly). So why is my data transfer failing after
627
the upload of a very large file?<br>
628
<font color=blue>Answer</font>: The answer involves SSL session caching
629
on the server side (<i>i.e.</i> <code>mod_tls</code>), cache timeouts, and
630
session renegotiations.
633
By default, <code>mod_tls</code> uses OpenSSL's "internal" session cache,
634
which is an in-memory caching of SSL session IDs. And by default, OpenSSL's
635
internal session cache has a cache timeout of 5 minutes; after that amount
636
of time in the internal session cache, a cached SSL session ID is considered
637
stale and is available for reuse.
640
This means that 5 minutes or more into an FTPS session, even if your FTPS
641
client reused an SSL session ID, the OpenSSL internal session cache will
642
time out that SSL session ID. The next time your FTPS client goes to reuse
643
that session ID for a data transfer, <code>mod_tls</code> won't find it in
644
the OpenSSL internal session cache, and will think that your FTPS client is
645
not reusing the SSL session ID as is required, and fail the transfer.
648
Fixing this situation requires two parts: <i>a)</i> the ability to change
649
the cache timeout used for the OpenSSL internal session cache, and <i>b)</i>
650
renegotiating the SSL session ID with the FTPS client periodically, to keep
651
the SSL session ID up-to-date in the session cache.
654
The first part, configuring the session cache timeout for the OpenSSL internal
655
session cache, is only possible in ProFTPD 1.3.4rc2 and later (see
656
<a href="http://bugs.proftpd.org/show_bug.cgi?id=3580">Bug#3580</a>). The
657
<a href="../contrib/mod_tls.html#TLSSessionCache"><code>TLSSessionCache</code></a> directive was modified to allow a configuration such as:
659
TLSSessionCache internal: 1800
661
(Unfortunately, the ':' after "internal" <i>is</i> necessary.) This configures
662
<code>mod_tls</code> such that the OpenSSL internal session cache uses
663
a cache timeout of 1800 seconds (30 minutes), rather than the default of 300
667
No matter how long you configure the cache timeout, eventually you will have
668
a session which lasts longer than that timeout. Which brings us to the second
669
part of the solution: renegotiating a new SSL session ID periodically, which
670
keeps it fresh in the session cache. The
671
<a href="../contrib/mod_tls.html#TLSRenegotiate"><code>TLSRenegotiate</code></a>
672
directive is needed for this. For example, the following configuration
673
should address the issue of failed data transfers after very large uploads:
675
TLSRenegotiate ctrl 1500 timeout 300
676
TLSSessionCache internal: 1800
678
This tells <code>mod_tls</code> to request a renegotiation of the SSL session
679
on the control channel every 1500 seconds (25 minutes), and to allow
680
300 seconds (5 minutes) for the client to perform the renegotiation. It also
681
tells <code>mod_tls</code> to cache the SSL session data for 1800 seconds
682
(30 minutes), <i>i.e.</i> longer than the renegotiation time of 1500 seconds.
685
This way, as long as your client supports renegotiations and is updating the
686
SSL session ID properly for data transfers, when a data transfer is requested,
687
the SSL session ID presented by the client should always be fresh and in the
598
690
<p><a name="TLSBuildErrors">
599
691
<font color=red>Question</font>: Why would I see the following errors while attempting to build <code>proftpd</code> with <code>mod_tls</code>?
821
913
- mod_tls/2.2: compiled using OpenSSL version 'OpenSSL 0.9.7i 14 Oct 2005'
822
914
headers, but linked to OpenSSL version 'OpenSSL 0.9.7l 28 Sep 2006' library
824
<font color=blue>Answer</font>: That message is a warning, not an error. It
825
is telling you that the OpenSSL headers on your system don't match the OpenSSL
826
library version. In most cases, this is not a problem. However, there
827
can be inexplicable errors if the difference in header versus library versions
916
What does this mean?<br>
917
<font color=blue>Answer</font>: That is an informational/warning message.
920
Some systems are badly maintained by their admins (and/or by the packages
921
installed on the systems), such that the OpenSSL headers can become quite badly
922
out of sync with the OpenSSL libraries. If this discrepancy becomes bad
923
enough, you can see strange behavior from OpenSSL, ranging from random behavior
924
to segfaults. So <code>mod_tls</code> tries to let the admin know about the
925
system's mismatched OpenSSL header/library versions.
928
Usually a minor OpenSSL version difference like the example above is OK,
929
but it really depends on exactly what changed in OpenSSL, and how.
932
If you see the above message, it is not a <i>requirement</i> that you recompile
933
<code>proftpd</code> against the OpenSSL headers of the same version as the
934
OpenSSL libraries. However, the version discrepancy <em>is</em> a possible
831
938
This header/library version check was added recently, hence why older
908
1015
file configured for the server certificate might also be badly formatted,
909
1016
which would result in the same error.
911
<p><a name="TLSOpenSSLVersionMismatch">
912
<font color=red>Question</font>: When I start <code>proftpd</code>, I
913
see warnings that look like this:
1019
<font color=red>Question</font>: Is there a way to require TLS (FTPS) for
1020
remote clients <b>only</b>, and allow simple FTP (without TLS) for local
1021
clients (<i>i.e.</i> for clients in networks which we will be able to define
1023
<font color=blue>Answer</font>: Yes.
1026
To do this, you would use a combination of
1027
<a href="Classes.html"><code><Class></code></a> sections and
1028
<a href="../contrib/mod_ifsession.html">mod_ifsession</a>'s
1029
<code><IfClass></code>, <i>e.g.</i>:
915
- mod_tls/2.4.1: compiled using OpenSSL version 'OpenSSL 0.9.8n 24 Mar 2010' headers, but linked to OpenSSL version 'OpenSSL 0.9.8q 2 Dec 2010' library
1035
<IfModule mod_tls.c>
1036
# Normal mod_tls configuration here
1038
<IfClass local>
1039
# Don't require FTPS from local clients
1043
<IfClass !local>
1044
# Require FTPS from remote/non-local clients
917
What does this mean?<br>
918
<font color=blue>Answer</font>: That is an informational/warning message.
921
Some systems are badly maintained by their admins (and/or by the packages
922
installed on the systems), such that the OpenSSL headers can become quite badly
923
out of sync with the OpenSSL libraries. If this discrepancy becomes bad
924
enough, you can see strange behavior from OpenSSL, ranging from random behavior
925
to segfaults. So <code>mod_tls</code> tries to let the admin know about the
926
system's mismatched OpenSSL header/library versions.
929
Usually a minor OpenSSL version difference like the example above is OK,
930
but it really depends on exactly what changed in OpenSSL, and how.
933
If you see the above message, it is not a <i>requirement</i> that you recompile
934
<code>proftpd</code> against the OpenSSL headers of the same version as the
935
OpenSSL libraries. However, the version discrepancy <em>is</em> a possible
940
Last Updated: <i>$Date: 2011/03/25 01:24:12 $</i><br>
1053
Last Updated: <i>$Date: 2011/05/11 16:09:24 $</i><br>
added
removed
doc/howto/TLS.html
