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 ssl_cipher_list
and ssh_cipher_list
configurations. The special keyword secure
contains all the algorithms that we currently consider secure.
From version 3.32.0, the default secure
ssl_cipher_list
configuration was updated to HIGH:!PSK:!RSP:!eNULL:!aNULL:!RC4:!MD5:!DES:!3DES:!aDH:!kDH:!DSS
where 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 !
mark.
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>
_.
In the 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>
_.
In the ssl_allowed_methods
option for the associate service, add the value tlsv1.2
to use TLS v1.2.
Ensure that 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.1
and/or 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 here </documentation/sftpplus/latest/configuration/ftp-service.html>
_.
You can use openssl s-client
, a diagnostic tool.
Connect via 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.
Run 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
Run 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
Using --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.