Details of attacks on DES (Data Encryption Standard) and Triple DES, Birthday attacks on 64-bit block ciphers were released with the CVE ID of CVE-2016-2183. Read
more about the CVE details here <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2183>_).
DES and Triple DES ciphers, used in TLS and SSH protocols and in subsequent relation also used in file transfer products, have a birthday bound of approximately four billion blocks. This makes it easier for remote attackers to obtain cleartext data via a birthday attack against a long-duration encrypted session, as demonstrated by an HTTPS session using Triple DES in CBC mode. This attack is otherwise known as the “SWEET32” attack.
If your SFTPPlus configuration is vulnerable to these attacks, you will need to ensure that you are on the latest SFTPPlus MFT version 3.xx.xx series and use the following custom configurations outlined below.
From SFTPPlus version 3.31.0, you can use the
secure cipher option for the
ssh_cipher_list configurations. The special keyword
secure contains all the algorithms that we currently consider secure.
From version 3.32.0, the default
ssl_cipher_list configuration was updated to
HIGH is defined by upstream OpenSSL.
In this way, when updating the OpenSSL library, you will automatically get an update in the list of secure ciphers without the need to update SFTPPlus.
SFTPPlus relies on OS crypto for the SSL/TLS portion. There is no need to run this configuration if your operating system has already deprecated the use of DES/3DES.
To check if your OpenSSL has DES and 3DES ciphers enabled, check the output of
openssl ciphers -v 'DES:3DES'
If DES/3DES are still available in OpenSSL, disable them for SFTPPlus by ensuring that the
ssl_cipher_list configuration for the service has the value
:!DES:!3DES: added in the list. This will exclude the use of DES and Triple DES as indicated by the
For more details about this configuration, please refer to
the ssl cipher list configuration option here </documentation/sftpplus/latest/configuration/ftp-service.html#ssl-cipher-list>_.
ssh_cipher_list configuration for the service, add the value
:!DES:!3DES: to exclude the use of DES and Triple DES. There is no need to run this configuration if your operating system has already deprecated the use of DES/3DES.
More details about this configuration
for the ssh cipher list here </documentation/sftpplus/latest/configuration/ssh-service.html#ssh-cipher-list>_.
ssl_allowed_methods option for the associate service, add the value
tlsv1.2 to use TLS v1.2.
tlsv1.2 is the only value in
ssl_allowed_methods so that this component will use TLS v1.2 during the secure communication handshake.
DES ciphers are used in TLS 1.0 and TLS 1.1, but they are not available in TLS 1.2 as noted in
RFC 5469 <https://tools.ietf.org/html/rfc5469>_.
In the event that you still require communication with services still utilizing TLS 1.1 and/or TLS 1.0, you may add
tlsv1.0 providing that the DES and Triple-DES ciphers are excluded in the first instance.
More details about this configuration are available in our documentation
You can use
openssl s-client, a diagnostic tool.
openssl s_client -cipher 3DES -connect site:port to check that 3DES is disabled.
To check the TLS version, the output will also reveal which TLS version is being used::
SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1519733544 Timeout : 300 (sec) Verify return code: 0 (ok)
If you wish to use
curl instead, there are two tests that you can run once these options are saved in your development lab.
curl with the excluded ciphers
DES-CBC3-SHA and check that you cannot complete the operation.
curl -v --ftp-ssl -k ftp://user@domain:port --ciphers DES-CBC3-SHA
curl with the allowed TLS version and check that you are able to complete the operation.
curl -v --ftp-ssl -k ftp://user@domain:port --tlsv1.2
--tlsv1.0 should fail the operation.
SFTPPlus configurations can also be confirmed via the log. For this issue, it should be done more as a supplementary step rather than as a sole point of confirmation of your configuration changes.
From the client-shell::
| SFTPPlus (3.30.0) file transfer client shell | > connect | 20140 2018-02-04 10:23:03 uuid Process 0.0.0.0:0 Connecting resource "ftpse". | 10102 2018-02-04 10:23:03 uuid user localhost:10021 Location ftpse connected to the FTP server. | 10106 2018-02-04 10:23:03 uuid user localhost:10021 Connection to FTP/FTPS was authenticated for location ftpse. Protected using TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384. Server certificate: (4) C=UK/O=ACME/CN=myserver.
From the server-side log::
| 10067 2018-02-04 10:23:03 Process Unknown 127.0.0.1:55555 Client initiating authentication as "user".Command protected using TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384. Client certificate: (2) C=GB/O=ACME/CN=myclient
The logs above indicate that
TLSv1.2 was used alongside the list of ciphers
ECDHE-RSA-AES256-GCM-SHA384. Please note that just because TLSv1.2 is used, it does not indicate that other TLS versions are disabled.