Good morning list,

I'm using curl to upload files to a FTPS server with implicit SSL. It works great for tens of thousands of files
but recently I got a little number of damaged files on the target FTPS server (Microsoft FTP Service).

The files in question have additional "garbage" bytes at the end of the file. It looks like binary or a unicode
potpourri. The files are all UTF-16LE encoded CSV files and looking at the hexdump they look rather normal.
When I delete some random characters from the files, and upload again the files can be ok or still have the
same issue. The garbage is different in each file but the same for every retry to upload the file.

One of the files causing trouble:
http://cl.ly/2L2L1D0E2p1L <http://cl.ly/2L2L1D0E2p1L>

Curl command used for upload:
curl --ftp-create-dirs -vv -k -T $file 'ftps://xxx:xxx_at_xxx.xxx/test1.csv'

What I found out using curl -vv that the connection was using this cipher suite

* SSL connection using ECDHE-RSA-AES256-SHA384

and after messing around with all involved SSL/TLS parameters I was able to upload the file without
any garbage when I force using cipher suite DES-CBC3-SHA. That works for now but it's unknown if
that was the only cause.

Debug output uploading using ECDHE-RSA-AES256-SHA384
http://pastebin.com/Wm87Bn5J <http://pastebin.com/Wm87Bn5J>

The file has the exact same size (7080 bytes) as reported from curl's upload progress, so the additional
bytes are not there before the upload(?)

I don't have access to the FTPS server itself (beside the FTP access) and installed a VSFTPD on another
machine with support for the ECDHE cipher suites and uploaded the file - and there was no garbage
whatsoever. I've checked that the garbage is indeed on the server and doesn't happen during download.

curl version used:
curl 7.26.0 (x86_64-pc-linux-gnu) libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: Debug GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP

Most recent package of
Linux proxy1 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u1 x86_64 GNU/Linux

I have no idea about Windows FTPS/SSL/TLS integration and for me it looks like incompatibilities between
TLS ciphers on linux and that windows server TLS ciphers but I really have _no_ plan of TLS/SSL ciphers
and if that's even related to the error.

Does anyone have a little hint for me, what I could look into?
Is it even curl related?
Is that behavior known elsewhere?

Thanks
Boris

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-10-29