Hi, we just discovered tht we cannot connect with TLS to our Ubuntu 16.04 server running pure-ftpd-mysql-1.0.36-3.2build1. We normally use FileZilla as client and I suspected it is the TLS 1.3 vs 1.2 problem described elsewhere, but I just verified that it does not work also when using WinSCP. When I check the TSL stack with "testssl -t ftp x.x.x.x:21", things look good, I see TLS1.2 and a quite typical SSL setup. But in the WinSCP log I only see > 2019-10-22 13:09:38.416 AUTH TLS < 2019-10-22 13:09:38.432 234 AUTH TLS OK. . 2019-10-22 13:09:53.196 Zeit abgelaufen (Kontrollverbindung) . 2019-10-22 13:09:53.196 Verbindung fehlgeschlagen. and in the syslog of the server I see Oct 22 13:19:22 xxx pure-ftpd: ([email protected]) [INFO] New connection from 82.100.215.250 Oct 22 13:19:22 xxx pure-ftpd: ([email protected]) [DEBUG] Command [auth] [TLS] Oct 22 13:19:37 xxx pure-ftpd: ([email protected]) [WARNING] Sorry, cleartext sessions are not accepted on this server.#012Please reconnect using SSL/TLS security mechanisms. We have the command line /usr/sbin/pure-ftpd-mysql-virtualchroot -l mysql:/etc/pure-ftpd/db/mysql.conf -l pam -u 1000 -S d.e.f.g,21 -O clf:/var/log/pure-ftpd/transfer.log -D -Y 1 -E -z -H -A -p 64000:64766 -J ALL:!aNULL:!SSLv3 -b -8 UTF-8 -d -B So TLS is not mandatory and we should accept lots of ciphers. Sadly, it is difficult to say what is going wrong here as the server logs do not tell much. When looking at the data stream with TCPDUMP, nothing sensible happens after " FTP: 234 AUTH TLS OK", as if the two sides would not agree on who does the next step. I know pure-ftpd is outside the scope of ispconfig itself - but I many people seem to have various problems with pure-ftpd and TLS lately, so I thought I might ask if this rings a bell with someone. Any hints?
Did this work previously? Are you using passive FTP, and are the ports open in firewall for passive port range?
Yes, it worked previously but not sure until when - we ourselves use SFTP for server access, and as the unencrypted variant works, people may not have complained. As for passive FTP, as it works unencrypted, it cannot be the problem or am I overseeing something? Also, the timeout or whatever it is happens in the initial phase, via the control channel, before a PASV command is even issued.
The TLS problems that shown up lateley were either related to the ftp client FileZilla which has chosen to enforce TLS 1.3 even if the ftp server did not support it yet (latest pure-ftpd versions support it, but not all distributions ship that version already) or there were passive port problems. But you issue seems to be different from that and I did not have it seen yet. The pure-ftpd config line looks fine, -Y 1 means tls and no-tls are allowed. https://download.pureftpd.org/pub/pure-ftpd/doc/README.TLS Maybe try for a test to set it to 0 ?
Hm, setting TLS to 0 will just give me unencrypted connections anyway!? But I did that with the expected result: I can only connect unencrypted then. (Well, so nothing changes ). But now things are getting very strange: I compiled my own pure-ftpd with ./configure --localstatedir=/var --sysconfdir=/etc --with-extauth --with-pam --with-virtualhosts --with-virtualchroot --with-mysql --with-tls (debian 18.04 with all required devel packages installed) and I then get a pure-ftpd that says "AUTH TLS" as reply to FEAT, but if you connect to it using TLS it goes into a never-ending packet loop e.g. with WinSCP, although with, when verified with testssl the TLS connection looks fine. So the next thing I will do is try to get support for pure-ftpd to get a compiled version working in the first place.
