Timeout when performing FTP file list operation using Windows schannel to provide TLS

[bobmitchell1956]

I did this

curl -v --ftp-ssl -m 20 -u"neveis_read_only:ZK8K3w6RZLrcQgmC8j5CWBX" "ftp://lio.bun.am:21/"

I expected the following

The file list
-rw------- 1 1004 1005 1855798 Jul 31 2018 composer.phar
followed by the command completing.

Instead of the command completing, it just sits there until the timeout expires.
I have attached the log from executing this command using curl -v. The server (vsftpd) is
curl.txt

available for you to reproduce the issue.

curl/libcurl version

curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
Release-Date: [unreleased]
Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL

Note that the same issue occurs with our own code linked against libcurl 7.65.3, using schannel to provide TLS.

operating system

Windows 10 Pro Version 1903 OS build 18362.778

[bagder]

Note that you've now exposed username and password to the world in this issue and that log file.

Does this happen against other FTPS servers too, you know? If you try to download a single file from this server, does it repro the problem (ie is this problem LIST-specific)?

[jay]

I can reproduce this with Windows 10 but I don't have a development environment there. Windows 7 I can't reproduce because the handshake fails with SEC_E_ILLEGAL_MESSAGE. curl w/ OpenSSL seems to work fine.

With OpenSSL there's a close_notify sent by the server, followed by a close_notify immediately sent by the client. With Schannel there's a close_notify sent by the server, then a hang for the timeout period, then a close_notify sent by the client. Perhaps the server is waiting for a reply to the close_notify?

We don't have a way to decrypt Schannel in Wireshark, and even if we did Wireshark doesn't decrypt SSL upgraded FTP connnections, so it may be more complicated than this.

[bobmitchell1956]

If I change the command to curl --ftp-ssl -m30 -u"neveis_read_only:ZK8K3w6RZLrcQgmC8j5CWBX" --output bob.file "ftp://lio.bun.am:21/composer.phar” the file is downloaded and then the command pends until the timeout occurs, so it is not LIST-specific. By the way, the username and password have been intentionally exposed - it provides limited read-only access. And as Jay noted in his email, this is schannel specific - the commands work fine for example on macOS using: curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport) LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2 Release-Date: 2019-03-27 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets Thanks, Bob Bob Mitchell Principal Engineer Tel: 01728 603011 | Email: bob.mitchell@omnis.net <mailto:bob.mitchell@omnis.net> Omnis Software Ltd | www.omnis.net Carlton Park House, Carlton Park Estate, Saxmundham IP17 2NL

…

On 23 Apr 2020, at 07:07, Daniel Stenberg ***@***.***> wrote: Note that you've now exposed username and password to the world in that log file. Does this happen against other FTPS servers too, you know? If you try to download a single file from this server, does it repro the problem (ie is this problem LIST-specific)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5284 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH6MNAFRBIUP4CB322FRMCTRN7LLTANCNFSM4MOX35NQ>.

[jay]

Unfortunately I don't have a way to debug this. I've labeled it "help wanted" but if nothing happens in several months it's going to go stale and be closed.