SSLV3 still supported in version edtFTPjPRO 5.3.0 ?

Question

Hello,

We perfectly understand that SSLv3 shoud no longer be used, under no circumstances, and we always make this clear to our customers. However, it turns out that some of our customers have their own partners that are very stubborn to upgrade (on their own risk).

Our question is: can SSLv3 still be used with 5.3.0, are there some known issues in this library version that prevent client code from using this protocol when connecting to a server ?

For example, suppose we're using a RedHat's own FTP server, configured only with SSLv3, when connecting via the lftp client, the server would send back the following features:

---- Connecting to <host> port 21
<--- 220 (vsFTPd 3.0.2)
---> FEAT
<--- 211-Features:
<---  AUTH SSL
<---  EPRT
<---  EPSV
<---  MDTM
<---  PASV
<---  PBSZ
<---  PROT
<---  REST STREAM
<---  SIZE
<---  TVFS
<---  UTF8
<--- 211 End

The lftp client would treat thsi situation by switching to SSL authentication, rather than TLS:

**** AUTH TLS is not supported, using AUTH SSL instead
---> AUTH SSL
<--- 234 Proceed with negotiation.
---> OPTS UTF8 ON

When we're using edt 5.3.0, to connect, we see however that TLS auth is still in use, even if we have set SSLv3 and cipher suites:

com.enterprisedt.SSLFTPClient] 24 Apr 2019 12:12:38.184 : Disabled all cipher-suites
com.enterprisedt.SSLFTPClient] 24 Apr 2019 12:12:38.184 : Enabling TLS_RSA_WITH_AES_256_CBC_SHA
com.enterprisedt.SSLFTPClient] 24 Apr 2019 12:12:38.184 : Enabling TLS_RSA_WITH_AES_128_CBC_SHA
com.enterprisedt.SSLFTPClient] 24 Apr 2019 12:12:38.184 : Enabling TLS_RSA_WITH_3DES_EDE_CBC_SHA
com.enterprisedt.SSLFTPClient] 24 Apr 2019 12:12:38.200 : Created explicit FTPS client.
com.enterprisedt.SSLFTPClient] 24 Apr 2019 12:12:38.202 : Min SSL/TLS version: SSL 3.0
com.enterprisedt.SSLFTPClient] 24 Apr 2019 12:12:38.203 : Max SSL/TLS version: SSL 3.0
com.enterprisedt.SSLFTPClient] 24 Apr 2019 12:12:38.203 : Connecting to <host>:21
com.enterprisedt.StreamSocketFactory] 24 Apr 2019 12:12:38.204 : Connecting to <host>:21 via standard socket
com.enterprisedt.StreamSocketFactory] 24 Apr 2019 12:12:38.226 : setSoTimeout(3000)
com.enterprisedt.SSLSocket] 24 Apr 2019 12:12:38.228 : Timeout=3000
com.enterprisedt.FTPControlSocket] 24 Apr 2019 12:12:38.233 : 220 (vsFTPd 3.0.2)
com.enterprisedt.SSLFTPControlSocket] 24 Apr 2019 12:12:38.237 : DISABLE_CONTROL_SSL_CLOSURE=false
com.enterprisedt.SSLFTPControlSocket] 24 Apr 2019 12:12:38.237 : DISABLE_CONTROL_WAIT_ON_CLOSE=false
com.enterprisedt.SSLFTPControlSocket] 24 Apr 2019 12:12:38.237 : ALLOW_BASIC_CONSTRAINTS_IN_NON_CA=false
com.enterprisedt.FTPControlSocket] 24 Apr 2019 12:12:38.237 : ---> AUTH TLS
INFO  2019-04-24 12:12:38,249 ConnJobCommand [Thread-53] - ftp command: ---> AUTH TLS
com.enterprisedt.FTPControlSocket] 24 Apr 2019 12:12:38.259 : 234 Proceed with negotiation.
INFO  2019-04-24 12:12:38,273 ConnJobCommand [Thread-53] - ftp reply: 234 Proceed with negotiation.
com.enterprisedt.SSLFTPControlSocket] 24 Apr 2019 12:12:38.273 : Starting SSL handshake on control socket
com.enterprisedt.SSLFTPControlSocket] 24 Apr 2019 12:12:38.294 : Caught: com.enterprisedt.net.puretls.SSLThrewAlertException

We've managed to actually make the client use also "AUTH SSL", but even so, it seems that there are problems deconding serve responses during handshake:

com.enterprisedt.FTPControlSocket] 24 Apr 2019 19:38:43.379 : ---> AUTH SSL
com.enterprisedt.FTPControlSocket] 24 Apr 2019 19:38:43.387 : 234 Proceed with negotiation.
com.enterprisedt.SSLFTPControlSocket] 24 Apr 2019 19:38:43.391 : Starting SSL handshake on control socket
com.enterprisedt.puretls] 24 Apr 2019 19:38:43.871 : Encoding client hello

...

com.enterprisedt.puretls] 24 Apr 2019 19:38:44.142 : Encoding handshake header
...

com.enterprisedt.puretls] 24 Apr 2019 19:38:44.168 : Decoding server hello

...

com.enterprisedt.puretls] 24 Apr 2019 19:38:44.219 : Read Integer size 2value 57
com.enterprisedt.puretls] 24 Apr 2019 19:38:44.224 : Reading a 1byte integer
com.enterprisedt.puretls] 24 Apr 2019 19:38:44.228 : Read byte 0
com.enterprisedt.puretls] 24 Apr 2019 19:38:44.232 : Read Integer size 1value 0
com.enterprisedt.puretls] 24 Apr 2019 19:38:44.247 : Throwing alert Handshake failure

Answer 1

Yes, you can still use SSL 3.0 but as you say it isn't recommended. You'll need to open a support ticket to resolve this particular issue, see enterprisedt.com/support.

Comments

I've found out that even if the server uses SSLv3 only, and the EDT client is only set to SSLv3, in the API it is mandatory to do: testSslFtpClient.disableSSL3(false);