Optional Support for Legacy Insecure Ciphers

For compatibility with older, insecure clients, we also offer a configuration setting for Files.com to enable legacy insecure ciphers for your site.

These are often used to maintain compatibility with older outdated apps, such as on-premise file transfer apps.

In many cases, you may be stuck supporting these because they are maintained by a client or vendor.

Whenever a cipher becomes vulnerable or compromised we remove it from the modern (default) option and designate it to only work with this legacy cipher option.

When using these settings, Files.com enables legacy TLS v1.0 and legacy TLS v1.1 for FTPS and HTTPS, as well as legacy ciphers for FTPS, HTTPS, and SFTP.

We strongly recommend not using these settings which enable insecure ciphers. Use of known insecure and weak ciphers is dangerous because an uninformed user of your site might think that they are using secure encryption when they are actually using encryption that is broken.

Use of these settings will make your site ineligible for our HIPAA BAA program and most likely other compliance initiatives.

You should treat all connections to your site as if they are fully insecure if you use these options.

For example, the Payment Card Industry (PCI) Security Standards Council has mandated that anyone subject to PCI rules must upgrade to TLS 1.2 by July 1, 2018. Other compliance regimes have instituted similar mandates.

The best way to avoid the need for these settings is to ask all your clients, vendors, or counterparties to upgrade to the latest version of any app they are using.

Better yet would be if you introduced your clients or vendors to us! We'd be happy to have our Sales team reach out and help them upgrade to Files.com on their end, so they can take advantage of all the security offered by the Files.com platform.

Another course of action is to have users try to switch between FTPS (FTP with TLS encryption) and SFTP. In many programs, this will cause the client to use a completely different process for encryption, and it may be the case that their app is more secure in the other mode.

With the insecure ciphers setting enabled, the following additional cipher suites are supported for HTTPS, in addition to also enabling TLS v1.0 and TLS v1.1. All cipher suites listed on the main Ciphers page continue to be supported.

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096)

The primary change is the addition of CBC cipher modes.

With the insecure ciphers setting enabled, the following additional cipher suites are supported for FTPS, in addition to also enabling TLS v1.0 and TLS v1.1. All cipher suites listed on the main Ciphers page continue to be supported.

TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 4096)

The primary change is the addition of 3DES_EDE_CBC ciphers.

Additionally, with insecure ciphers enabled, the following security algorithms are enabled for SFTP. The following list is a complete list, not a list of the changes vs. secure mode.

The Insecure Ciphers setting on Files.com offers three settings allowing you to choose between maximizing security and maximizing compatibility.

These options are to (1) use only secure ciphers everywhere, (2) enable insecure ciphers for SFTP only, and (3) enable insecure ciphers for SFTP, FTPS, and HTTPS.

Beyond the 3 options provided, it is not possible to pick and choose certain ciphers to enable and disable. We are open to paid custom development to build custom configurations for certain customers, however, this would require an Enterprise contract. Please contact us to learn more.

While we strongly recommend not allowing any insecure ciphers, if your organization requires them, then we advise using this setting to limit insecure ciphers to SFTP connections only.

The Insecure Ciphers setting on Files.com is a sitewide-level configuration, so it is not technically possible to allow different ciphers for different users.

Within most SSL protocols, including TLS and SSH protocol, the cipher negotiation between the client and server happens prior to authentication, so the server would have no way of knowing which user it is negotiating with in order to offer different ciphers.

Allowing weak Diffie Hellman parameters for SFTP enables support for legacy or broken SSH and MFT clients that incorrectly implement Diffie Hellman ciphers using parameters that are too weak.

If you need to support wide compatibility with SFTP clients, enable this option and we will allow weak Diffie Hellman parameters within otherwise-secure ciphers.

Like other SFTP servers, Files.com adheres to RFC4253, section 7.1 when negotiating with SFTP clients to decide which ciphers to use.

Simply put, the SFTP client will send the list of ciphers it supports in order of preference, and the server will choose the first cipher on the list that it also supports. Hence, the choice is biased towards the client's preferences.

A well-written, properly-configured, and up-to-date client will prefer secure ciphers to insecure ciphers.

Unfortunately, many of the SFTP and FTP clients (and even web browsers) that we see actually connecting to Files.com are not necessarily well-written, properly-configured, or up-to-date.

Therefore we encourage our customers to assume the worst when deciding to allow insecure ciphers: assume they’ll be used.