0

I was going to post this on a different SE site, but I found that explicitly stating --tlsv1.1 to curl fixed the problem, for now. My question now relates to security.


A vendor switched to FTPS (not SSH FTP) recently. I've added --ssl and --ssl-reqd to the command and I get aborted transfers when I upload a file. I'm running this on Ubuntu 18 server. This is the command I'm using.

curl \
-v \
-u ${FTPUSER}:${FTPPASS} \
--upload-file "$FileToUpload" \
--ssl \
--ssl-reqd \
ftp://${FTPHOST}/

The -v output claims the SSL cert from the server is okay. During the verbose output for download, there are many duplicate messages on screen, reading

* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
} [$integer bytes data]

before finally finishing with

* We are completely uploaded and fine
* Remembering we are in dir ""
...
< 450 Transfer aborted. Link to file server lost
* server did not report OK, got 450
* Connection #0 to host $FTPHOST left intact
curl: (18) server did not report OK, got 450

The test file $FileToUpload is 10 MB; I generated it from "/dev/urandom" using dd. Using WinSCP on my Win 10 workstation I can get a directory listing. The file size is different each time, between 7 and 9 MB. The vendor's automated process also removes the file from the server quickly (or they chmod it so I can't see it), so it's difficult to download it to verify with a checksum. I can upload the file to the server with WinSCP on my Win 10 workstation without issue. Right after, if/when I can download it, I use

# Download
curl \
-v \
-u ${FTPUSER}:${FTPPASS} \
--ssl \
--ssl-reqd \
-O \
ftp://${FTPHOST}/${FileToUpload##*/}

and list it with

# Listing
curl \
-v \
-u ${FTPUSER}:${FTPPASS} \
-l \
--ssl \
--ssl-reqd \
ftp://${FTPHOST}/

Both of those finish with

< 226 Transfer complete
* Connection #0 to host $FTPHOST left intact

I looked at a packet capture taken on my workstation while uploading the same file and nothing really stands out that would indicate my curl options are wrong.

I've also tried this on an Ubuntu 18 server from a different network and have the same results.

##############################
# Here's where the original  #
# post would've ended before #
#     I found a/the fix.     #
##############################

I added --tlsv1.1 and it uploads successfully each time, with the message

< 226 Transfer complete
* Connection #0 to host $FTPHOST left intact

Only that argument makes the upload work. If I substitute that with any of the other TLS options -1, --tlsv1, --tlsv1.0, --tlsv1.2, --tlsv1.3, I'm back to the 450 error. The original verbose output showed curl and $FTPHOST negotiated with tlsv1.3. A combined packet capture specifying the working option --tlsv1.1 and not illustrate TLSv1.1 and TLSv1.3 being negotiated, respectively.

https://$FTPHOST:443 is open, but a browser returns "SSL_ERROR_RX_RECORD_TOO_LONG".

curl -kv https://$FTPHOST/ shows possible errors:

* error:1408F10B:SSL routines:ssl3_get_record:wrong version number
* stopped the pause stream!
* Closing connection 0
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

and openssl s_client -connect ${FTPHOST}:${PORT} -showcerts ($PORT is in [21,80,443]) shows

CONNECTED(00000005)
140224622215616:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:332:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 322 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Should I contact the vendor and see if they can fix their end to use TLSv1.2 or TLSv1.3? This seems like a server-side misconfiguration.

The question is, am I sacrificing any security pegging this script to use TLSv1.1?

4
  • 1
    Yes, TLS 1.1 is not ok. It has not been allowed for PCI DSS, Chrome is dropping it, etc. Tell them to upgrade to TLS 1.2 at least. Can you run ssllabs.com/ssltest on their server? But the code for FTPS can be very different from code on port 443.
    – Z.T.
    Commented Mar 29, 2020 at 8:58
  • 1
    It's not that they do not support TLS 1.2/1.3 – They do. But it does not work. – First make sure you have the latest version of curl, as there were some TLS 1.3-specific issues. – Though I have seen the problem you have even when using the latest version of curl against ProFTPD server with TLS 1.3. I have reported the problem to the ProFTPD author already (for investigation, as this might be curl problem as well). – TLS 1.2 works (for me). Commented Mar 29, 2020 at 10:48
  • 1
    Note that a similar problem happens even with WinSCP, but WinSCP does not use TLS 1.3 unless you explicitly configure it to do so. Commented Mar 29, 2020 at 10:52
  • @MartinPrikryl, <sarcasm>Don't besmirch WinSCP. Who even are you?</sarcasm> :) I set the TLS settings for min and max version to be 1.3 and transfers still worked on the Win 10 machine. I expected it to fail in the same manner and was surprised when it didn't.
    – user208145
    Commented Mar 29, 2020 at 22:05

0

You must log in to answer this question.

Browse other questions tagged .