Ftps auth tls

Hello, I am trying to get Opus 10.x to connect to an FTPs server (using AUTH TLS). This is the debug log. Can anyone help me understand what's going on? I am able to connect from the same network using a different FTP client (Core FTP LE).

Thanks in advance

Initialising SSL BIO...
Opening Connection some.ftphost.com:21
220 Welcome to xxxxxxxxxxxxxxxxxx
234 Proceed with negotiation.
Establishing SSL Ctrl Connection
SSL_connect: 0
SSL_unk:NONE cb in UNKWN before/connect initialization
SSL_connect: 4096
SSL_connect:NONE UNKWN before/connect initialization
SSL_connect:NONE UNKWN before/connect initialization
SSL_connect: 4096
SSL_connect:NONE 3WCH_A SSLv3 write client hello A
SSL_connect:NONE 3WCH_A SSLv3 write client hello A
SSL_connect: 4096
SSL_connect:NONE error in 3RSH_A SSLv3 read server hello A
SSL_connect: 4096
SSL_connect:NONE error in 3RSH_A SSLv3 read server hello A
SSL_connect: 16384
SSL_connect: 4096
SSL_connect:NONE failed in 3RSH_A SSLv3 read server hello A
SSL_connect error 1
TLS/SSL connection to server failed!
Connection closed
** Cannot establish SSL Connection.

What I notice when comparing Core FTP LE with Opus is that Core FTP LE prompts me to accept the remote ssl certificate while Opus never prompts me to do that.

If you try to connect to this test server, does it work:

Connection: Secure TLS Explicit (AUTH TLS)
Host address: ftp.secureftp-test.com
Port: 21
User name: test
Password: test


Thanks. Yes, I am able to connect to ftp.secureftp-test.com via Secure TLS Explicit (AUTH TLS).

Below is what they say about the connection details.

Server Name: some.ftphost.com
Inbound port: 21
Passive allowed: Yes, port 12000 to 12100
Authentication: AUTH TLS and AUTH SSL
Listings and transfers: SSL (PROT P)


Thanks; that probably rules out things like the firewall (assuming both servers are on the Internet, not an Intranet or VPN or similar).

It's possible the server is using a type of SSL which Opus and/or its SSL library do not support. There are lots of different types/modes of SSL and the server might be configured to use a more unusual one without being able to fallback on anything else. That's just a guess though as it's hard to be sure without access to the server to try things out.

The server is on the Internet. I had already ruled out a firewall/network issue by connecting with another FTP client from the same network. Maybe a log from a connection via that client would help illuminate the situation. I have no access to the server outside of this FTP account so trying things is limited to the connection settings. I'll look in their doc again to see if they say anything about the type of ssl. What I recall off hand is that the say to use OpenSSL, if that helps.

(Firewalls can grant different programs different permissions, FWIW.)

True, but our corporate firewall doesn't work that way. It doesn't know what program is communicating, only what ports and addressees are being used. I'll check the server documentation today and post what I find about ssl.


This is what they have to say about their SFTP server configuration:

Our implementation of FTPS is fully compliant with IETF STD9 (RFC4217) with the exception noted in section 2.2.2.
2.2.1 What RFC4217 does not allow. Implicit SSL protection of the FTP session.
There is a port (990), registered with the IANA, for secure FTP using ssl (FTP-TLSPORT). This approach can be likened to the [RFC-2818] approach for https, in that the SSL negotiation happens upon connection (for the control and all data connections). This approach is not favored by the IETF and should not be used for new FTP-TLS implementations. While somehost.sftp.com does allow control connections to port 990 the connection semantics adhere to RFC4217 not RFC2818; it does not allow Implicit SSL protection over port 990. Protection using the 'AUTH SSL' command.
The parameter on the AUTH command is 'SSL' and not 'TLS' and, once the control connection is secured, the state of the data connection is implicitly secure. This approach is in direct disagreement with [RFC-2228] which requires the PROT command to be issued. somehost.sftp.com will allow SSL authentication until client and server packages make the transition to support TLS.

I'm not an expert in FTPS, so maybe that's a common or defacto configuration, but it sounds like they're saying it follows the standard except where it doesn't, i.e. it doesn't follow the standard?

The team member who knows most about FTPS is away at the moment so we might be able to give a better answer when they return.


That's exactly what I thought, "Huh?". The entire document was confusing, in a way. I'll wait to hear back when your sFTP guy is available. Thanks for your help.


Is the "FTPS" guy available now?




Apart from Bronchitis, he's now available:)

Email me privately (direct) on the issue please.