Optional Support for Legacy Insecure Ciphers for SFTP
Files.com supports modern, secure SFTP encryption algorithms by default, requiring all inbound SFTP connections to use only secure ciphers. Enabling insecure SFTP ciphers allows clients to negotiate legacy algorithms with known weaknesses.
The setting applies sitewide. You cannot limit it to specific users or ciphers. We do not recommend enabling it. Use it only when a business-critical client cannot negotiate modern ciphers and cannot be upgraded.
Why to Avoid This Setting
Known insecure and weak ciphers are dangerous because users can mistakenly assume the connection is strongly encrypted. Enabling this setting allows SFTP sessions to negotiate cryptographically weak or deprecated algorithms, which reduces the security posture of your Files.com site and makes it ineligible for the Files.com HIPAA Business Associate Agreement (BAA) program.
The best path to avoid this setting is to ask clients, vendors, or counterparties to upgrade to the latest version of any app they are using. Another option is to switch those connections to FTPS (FTP with TLS encryption) instead of SFTP. In many systems, TLS-based security is stronger than SFTP-based security, and cipher policies can be managed more tightly.
If your organization operates in a regulated environment, you must evaluate the compliance implications before enabling this setting.
When You Would Use This Setting
Enable legacy cipher support when a third-party SFTP client fails to connect because it only supports deprecated SSH encryption algorithms. This is common with older embedded systems, legacy enterprise software, and outdated integration tools. Upgrading the client is the preferred and safer solution; enable this setting only when that is not possible.
Determining Which Ciphers Are Being Used
Before enabling legacy cipher support, determine which encryption algorithms your clients are currently negotiating. Files.com provides reporting that shows which ciphers are being used by SFTP connections to your site. The report identifies clients already using modern secure algorithms and isolates those that rely on legacy ciphers. In many cases, only a small number of outdated systems require legacy support.
How Cipher Negotiation Works
SFTP uses the SSH protocol. Files.com follows RFC4253, section 7.1 when negotiating SFTP algorithms. During the initial handshake, the client and server negotiate encryption algorithms before user authentication occurs. At that stage, the server does not know which user is connecting. As a result, cipher restrictions apply sitewide, policies cannot be enforced per user, and the server selects the strongest mutually supported algorithm.
Even when legacy support is enabled, Files.com prioritizes modern secure algorithms if the client supports them. Weaker algorithms are used only when the client does not offer stronger alternatives.
Algorithms Enabled by This Setting
When legacy cipher support is enabled, the following algorithms become available for negotiation. The list includes both modern secure algorithms and legacy algorithms that are considered weak or deprecated.
| Type | Algorithms |
|---|---|
| Key Exchange |
|
| Server Host Key Algorithms |
|
| Encryption |
|
| MAC |
|
Some of the algorithms in this list are widely considered insecure by modern cryptographic standards. Enabling this setting allows clients to request those algorithms during negotiation.
No Per-User or Per-Cipher Controls
Cipher policies cannot be restricted to individual users or specific folders. Because encryption negotiation occurs before authentication, the same policy applies to all SFTP connections to the site. If you require strict cryptographic controls with no support for legacy algorithms, leave this setting disabled.
Allow Weak Diffie-Hellman Parameters for SFTP
Files.com provides a separate setting named Allow Weak Diffie-Hellman Parameters for SFTP. This setting expands compatibility by permitting weaker Diffie-Hellman key exchange parameters that some legacy clients require. It also reduces cryptographic strength and applies sitewide. Enable it only when a required client cannot connect without it. If you need broad client compatibility for migration purposes but want stronger encryption controls, use FTPS (FTP over TLS) instead, where cipher policies can be managed more tightly.
Recommended Approach
If you must enable legacy cipher support, document the reason and disable the setting as soon as the legacy client is replaced. The preferred long-term configuration is to leave legacy cipher support disabled and require modern secure SFTP algorithms for all connections.