cURL / Mailing Lists / curl-users / Single Mail


Re: Problems with FTPS through HTTP proxy (long)

From: Zero Uno <>
Date: Wed, 14 Jan 2015 01:27:56 +0100

Hi all,
for the record, I now also tried with the just released 7.40, installing
the provided RH6 packages, but the result is exactly the same.

To sum it up: when doing FTPS transfers through a Blue Coat ProxySG HTTP
proxy, curl cannot establish a secure data connection, and it puts into the
data stream also the HTTP proxy response string.

This happens with 7.39 and 7.40 on RedHat 6.3.
I'm told that the problem is not present on curl 7.26 in Debian 7.1.

Any info is welcome.

2015-01-07 12:28 GMT+01:00 Zero Uno <>:
> Hello,
> does anyone have any clue about this topic I asked some time ago?
> I'm still stuck at the same point...
> The only new element I have is that the connection appears to work
> properly, both using encrypted and non-encrypted data connection, when
> using a different curl version: 7.26 on Debian 7.1 (Wheezy).
> I also tried looking at the build options used for that Debian package and
> building my curl 7.39 on RedHat using the same options, but I get the same
> results.
> Thank you.
> ---------- Forwarded message ----------
> From: Zero Uno <>
> Date: 2014-12-11 14:59 GMT+01:00
> Subject: Problems with FTPS through HTTP proxy (long)
> To:
> Hi,
> I need to use curl to transfer files using FTPS (explicit, on port 21)
> through a HTTP proxy, but I'm having a hard time doing it.
> The HTTP proxy is Blue Coat ProxySG, while I do not know the FTP server
> used (might be vsftpd). The FTP server certificate is self-signed.
> This is the output of curl --version, on the client machine which is RHEL
> 6.3:
> curl 7.39.0 (x86_64-unknown-linux-gnu) libcurl/7.39.0 OpenSSL/1.0.1e
>> zlib/1.2.3 c-ares/1.9.1 libidn/1.18 libssh2/1.4.2
>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
>> pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
>> Features: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL
>> libz Metalink
> The first problem is that I cannot use an encrypted DATA connection.
> If I try this:
> curl -v -k --ftp-ssl-reqd --proxy <proxyaddress:port> --proxytunnel ftp://
>> <user:pw>@<ftpserver>//filepath
> ...I get this error:
> curl: (35) error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
> Note that the error only appears when curl tries to open the DATA
> connection. The encrypted login is fine.
> I get the same error when trying the "-1" option, and also if using
> --ftp-ssl instead of --ftp-ssl-reqd.
> I tried using "-3":
> curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert
>> handshake failure
> Using "-2":
> curl: (35) Unknown SSL protocol error in connection to <ftpserver>:21
> Thinking about a self-signed server certificate issue, I also tried
> passing the server certificate to curl with --cacert and removing the -k
> option, but the result is the same.
> Also please note that Filezilla instead, as far as I can understand from
> its log, can successfully transfer the file using FTPS over an encrypted
> data channel from the same FTP server through the same proxy. I do not see
> any options in Filezilla to only encrypt the login connection.
> Now... I can successfully connect using the --ftp-ssl-control to only
> encrypt the login and use non-encrypted data transfers. But then a new
> problem creeps in: when the data transfer is initiated, the HTTP proxy
> sends a string:
> HTTP/1.1 200 Connection established
> This string is inserted INTO THE DOWNLOADED FILE!
> So, if for example curl was expecting an XML file of 1500 bytes, the saved
> file will be a corrupt XML because it will begin with that HTTP string
> _and_ it will be truncated before the transfer is complete! I suppose it is
> truncated because some of the expected 1500 bytes are taken up by the extra
> string and the transfer is terminated anyway when the expected number of
> bytes has been reached.
> Maybe this would not happen if the data transfer was encrypted.
> So... any ideas about this problem? Do you think it is libcurl's fault, or
> is the proxy behaving bad with that string?
> Why cannot curl use SSL for data?
> Why does it insert the string into the file?
> Thank you for any help!
> --
> 01

List admin:
Received on 2015-01-14