0

Trying to connect from client2 using the following string works:

client2@client2 curl -v --ssl -u 'user:password' ftp://www.example.com:21
* Rebuilt URL to: ftp://www.example.com:21/
*   Trying 192.168.177.186...
* Connected to www.example.com (192.168.177.186) port 21 (#0)
< 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
< 220-You are user number 1 of 50 allowed.
< 220-Local time is now 09:16. Server port: 21.
< 220-This is a private system - No anonymous login
< 220-IPv6 connections are also welcome on this server.
< 220 You will be disconnected after 15 minutes of inactivity.
> AUTH SSL
< 500 This security scheme is not implemented
> AUTH TLS
< 234 AUTH TLS OK.
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
*        server certificate verification OK
.
.
.
* Connect data stream passively
* ftp_perform ends with SECONDARY: 0
< 229 Extended Passive mode OK (|||35104|)
* Connecting to 192.168.177.186 (192.168.177.186) port 35104
* Connected to www.example.com (192.168.177.186) port 21 (#0)
> TYPE A
< 200 TYPE is now ASCII
* Remembering we are in dir ""
< 226-Options: -a -l 
< 226 6 matches total
* Connection #0 to host www.example.com left intact

Trying to connect from client1 doesn't:

client1@client1:~> curl -v --ssl -u 'user:pass' ftp://www.example.com:21
* About to connect() to www.example.com port 21 (#0)
*   Trying 192.168.177.186...
* connected
* Connected to www.example.com (192.168.177.186) port 21 (#0)
< 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
< 220-You are user number 1 of 50 allowed.
< 220-Local time is now 09:15. Server port: 21.
< 220-This is a private system - No anonymous login
< 220-IPv6 connections are also welcome on this server.
< 220 You will be disconnected after 15 minutes of inactivity.
> AUTH SSL
< 500 This security scheme is not implemented
> AUTH TLS
< 234 AUTH TLS OK.
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to www.example.com:21
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to www.example.com:21

What could be the cause?

2

On the successful connection client2 uses TLS 1.2, indicating that both ends support it:

> AUTH SSL
< 500 This security scheme is not implemented
> AUTH TLS
< 234 AUTH TLS OK.
...
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384

With the failing connection, client1 seems to be attempting to use the known-broken SSLv3:

* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to www.example.com:21

My guess would be that the SSL library that curl uses on client1 (OpenSSL? GnuTLS? Something else?) is just too old to support TLS1.2 and/or the encryption algorithms accepted by the server. It attempts to fall back all the way to SSLv3-era encryption algorithms, and the server is rejecting all the encryption protocols/algorithms offered by the client as being too weak or broken.

Since you left the hostname unsanitized on the bottom line of the client2 output, I submitted the site URL to https://www.ssllabs.com/ssltest/ and it looks like the server requires TLS 1.1 at minimum.

To fix client1, you should find out which SSL/TLS library is used curl on that host (ldd $(which curl) might be helpful there) and make sure that library is as up to date as possible.

But if client1 is using an outdated Linux distribution that no longer has active security support, there might not be a new enough updated SSL/TLS library package available. At that point, you might have to look for an updated version of curl + the respective SSL/TLS library in some third-party repository, or to compile your own.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.