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?
