Not much of interest to add beyond the
interesting network isolation support previously discussed. Some minor bugs were fixed. A bunch of compile errors were addressed. There is now support for PAM modules which remap the underlying user account. There is also a new command-line option to pass config file options directly.
What do you think about proftpd implementing a sftp function?
ReplyDeleteSince upgrading to v2.2.0 my TLS/FTP Server no longer works. I'm using xinet.d and have (among others) the following settings in my vsftpd.conf:
ReplyDeleteport_enable=YES
pasv_min_port=60000
pasv_max_port=61000
pasv_addr_resolve=YES
pasv_address=mydyndns.dyndns.org
pasv_promiscuous=YES
require_ssl_reuse=NO
The client just gets disconnected:
Response: 220 Welcome to the FTP service [...]
Command: AUTH TLS
Response: 234 Proceed with negotiation.
Status: Initializing TLS...
Status: Verifying certificate...
Command: USER myuser
Status: TLS/SSL connection established.
Response: 331 Please specify the password.
Command: PASS ********
Response: 230 Login successful.
Command: OPTS UTF8 ON
Response: 200 Always in UTF8 mode.
Command: PBSZ 0
Response: 200 PBSZ set to 0.
Command: PROT P
Response: 200 PROT now Private.
Status: Connected
Status: Retrieving directory listing...
Command: CWD /mnt/disk
Response: 250 Directory successfully changed.
Command: TYPE I
Response: 200 Switching to Binary mode.
Command: PASV
Error: Disconnected from server: ECONNABORTED - Connection aborted
Error: Failed to retrieve directory listing
Anyone else behind NAT who has these problems since upgrading to v2.2.0 ?
There seems to be something up with pasv_address in 2.2.0. I've emailed Chris but not sure if he will see that so posting here as well.
ReplyDeletehttp://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg673507.html
http://marc.info/?l=freebsd-ports&m=125093714401480&w=3
Thanks,
Richard.
same situation...
ReplyDeletebefore it worked, after update no...
any news?
I've been trying to find a place to leave the following information:
ReplyDeleteSince VSFTPD supports client certificates for FTP-S communications (2.0.7) there is this z/OS issue. In the man page of vsftpd.conf the solution is actually disabling client certificate request and verification (set ssl_request_cert to NO).
The z/OS issue is actually caused by the following. The z/OS ftp-s client expects at least one certificate_authority as part of the certificate request made by the server. In the VSFTPD implementation there is no way to give it any. By that VSFTPD is compliant with RFC's for TLS v1.1 and TLS v1.2, which allow a request without a certificate_authority. However there are still versions of z/OS in the field that use TLS v1.0. For TLS v1.0 at least one certificate_authority must be present in the certificate request from the server causing the problem mentioned earlier. And there might be other cases where one want to be able to provide certificate_authorities as part of the request.
There is an easy solution for this, with the following change in the ssl.c file VSFTPD will sent certificate_authorities as part of the certificate request:
ssl.c:125:
if (verify_option)
{
SSL_CTX_set_verify(p_ctx, verify_option, ssl_verify_callback);
if (tunable_ca_certs_file)
{
if (!SSL_CTX_load_verify_locations(p_ctx, tunable_ca_certs_file, NULL))
{
die("SSL: could not load verify file");
}
/*
* Following line will add the CA's inside the file configured with ca_cert_file
* to the certificate_authorities list inside the certificate request sent from the
* VSFTPD server to the client:
*/
SSL_CTX_set_client_CA_list(p_ctx,SSL_load_client_CA_file(tunable_ca_certs_file));
}
}
p_sess->p_ssl_ctx = p_ctx;
ssl_inited = 1;
}
In this case the vsftpd.conf option ca_certs_file is used for keeping the CA's to be sent as part of the certificate request.
To show you the result of this (a curl trace on the client side):
Without this change:
== Info: SSLv3, TLS handshake, Request CERT (13):
<= Recv SSL data, 9 bytes (0x9)
0000: 0d 00 00 05 02 01 02 00 00 .........
With this change:
== Info: SSLv3, TLS handshake, Request CERT (13):
<= Recv SSL data, 98 bytes (0x62)
0000: 0d 00 00 5e 02 01 02 00 59 00 57 30 55 31 0b 30 ...^....Y.W0U1.0
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030: CO NT EN TS RE MO VE D ON PU RP OS E 00 00 00 00
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060: 43 41 CA
Hope you'll consider a change like this inside vsftpd.
@Anybody Mustermann, @anonymous: I'll release a v2.2.1 today which fixes the issue with pasv_address - sorry about that!
ReplyDelete@Hans: thanks, I've put something similar into v2.2.1 -- although requesting a client send a cert is disabled by default in v2.2.0, in favour of SSL session reuse as an authenticator of data sessions.
ReplyDelete