Bug 1432054

Summary:	secure ftp stopped working with default TLS settings in the new vsftpd package
Product:	Red Hat Enterprise Linux 7	Reporter:	Alexei Seleznyov <aseleznyov>
Component:	vsftpd	Assignee:	Zdenek Dohnal <zdohnal>
Status:	CLOSED ERRATA	QA Contact:	Hynek Bucek <hbucek>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.3	CC:	hbucek, thozza
Target Milestone:	rc	Keywords:	Patch, Regression
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	vsftpd-3.0.2-22.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-01 12:42:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alexei Seleznyov 2017-03-14 12:26:35 UTC

Description of problem:
Default settings for TLS support in vsftpd have been changed since RHEL 7.2, and secure ftp connection stopped working.

Version-Release number of selected component (if applicable):
vsftpd-3.0.2-21.el7

How reproducible:
yes

Steps to Reproduce:
1. install vsftpd, lftp
2. generate key/cert for vsftpd
# openssl genrsa -out /etc/vsftpd/vsftpd.pem 2048 -batch; openssl req -new -x509 -key /etc/vsftpd/vsftpd.pem -out /etc/vsftpd/vsftpd.pem -keyout /etc/vsftpd/vsftpd.pem -days 365 -batch
3. enable and enforce ssl in vsftpd
# cat >> /etc/vsftpd/vsftpd.conf
rsa_cert_file=/etc/vsftpd/vsftpd.pem
ssl_enable=YES
allow_anon_ssl=YES
force_anon_logins_ssl=YES
force_anon_data_ssl=YES

4. start vsftpd
# systemctl start vsftpd

5. create sample script for lftp (doing just login and list files)
# cat > lftp_script
set ssl:verify-certificate false
open ::1
user ftp joe@
ls

6. run the lftp script
# lftp -f lftp_script

Actual results:
with vsftpd-3.0.2-11.el7 - works:
# lftp -f lftp_script
drwxr-xr-x    2 0        0            4096 Mar 31  2016 pub

with vsftpd-3.0.2-21.el7 - does not work:
# lftp -f lftp_script 
ls: Login failed: 530 Anonymous sessions must use encryption.


Expected results:
secure ftp must work with both vsftpd packages.

Additional info:
1. It seems strange to me that FEATURES command's response does not contain AUTH TLS when ssl_tlsv1_2=YES and ssl_tlsv1=NO
2. This scenario starts working with vsftpd-3.0.2-21.el7 too, after enabling tlsv1 as in:
# echo "ssl_tlsv1=YES" >> /etc/vsftpd/vsftpd.conf
# systemctl restart vsftpd

check:
# lftp -f lftp_script
drwxr-xr-x    2 0        0            4096 Nov 05 19:43 pub

Comment 2 Martin Sehnoutka 2017-03-14 14:26:49 UTC

Hello, thank you for your report. This is indeed a bug coming from the last update.

I can reproduce it easily:
# cat >> vsftpd.conf << EOF
> rsa_cert_file=/etc/vsftpd/cert.pem
> rsa_private_key_file=/etc/vsftpd/key.pem
> ssl_enable=YES
> allow_anon_ssl=YES
> force_anon_logins_ssl=YES
> force_anon_data_ssl=YES
> EOF
# systemctl restart vsftpd
# echo "FEAT" | nc localhost 21
220 (vsFTPd 3.0.2)
211-Features:
 EPRT
 EPSV
 MDTM
 PASV
 PBSZ
 PROT
 REST STREAM
 SIZE
 TVFS
 UTF8
211 End

It can also be fixed fairly easily with this patch:
diff --git a/features.c b/features.c
index 1212980..d024366 100644
--- a/features.c
+++ b/features.c
@@ -22,7 +22,7 @@ handle_feat(struct vsf_session* p_sess)
     {
       vsf_cmdio_write_raw(p_sess, " AUTH SSL\r\n");
     }
-    if (tunable_tlsv1)
+    if (tunable_tlsv1 || tunable_tlsv1_1 || tunable_tlsv1_2)
     {
       vsf_cmdio_write_raw(p_sess, " AUTH TLS\r\n");
     }

and the behavior is as expected. 
a) from netcat:
# echo "FEAT" | nc localhost 21
220 (vsFTPd 3.0.2)
211-Features:
 AUTH TLS
 EPRT
 EPSV
 MDTM
 PASV
 PBSZ
 PROT
 REST STREAM
 SIZE
 TVFS
 UTF8
211 End

b) from user perspective:
user@rhel-7 ~ » cat lftp_script                                                                                    
set ssl:verify-certificate false
open localhost
user ftp ftp
ls

user@rhel-7 ~ » lftp -f lftp_script
drwxr-xr-x    2 0        0               6 Jun 23  2016 pub
user@rhel-7 ~ »

Comment 8 errata-xmlrpc 2017-08-01 12:42:28 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2196