Skip to main content

Ciphers

Ciphers, also known as cipher suitesExternal LinkThis link leads to an external website and will open in a new tab, are the encryption technology used under the hood when data moves to and from Files.com over SSL/TLS. Files.com follows industry best practices for choosing secure encryption technologies, and balances that against long-term compatibility for customer applications.

Files.com offers secure modern encryption by default, and also allows customers to optionally enable legacy (old) ciphers. The legacy setting lets outdated clients, systems, and devices connect via older ciphers and protocols that are known to be insecure.

When you enable legacy insecure ciphers, we recommend updating those connections to more secure ones. To phase out insecure ciphers on legacy connections, you can run pre-defined reports to determine which ciphers are being used. The reports give you current and historical information about how each of your users' connections are affected.

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

A Note About the Term SSL / TLS

TLS is the modern standard that replaces SSL. When either term appears without a specific version number (such as TLSv1.3), our documentation and website use TLS and SSL interchangeably.

Default Secure Ciphers

By default, Files.com uses TLS v1.3 for HTTP connections and TLS v1.2 for FTP. TLS v1.2 is also supported for HTTP and is configured to provide the same level of security as TLS v1.3.

Our SSL configuration holds an A+ Rating from the Qualys SSL graderExternal LinkThis link leads to an external website and will open in a new tab.

HTTPS

Files.com supports the following TLS v1.3 cipher suites for HTTPS:

TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519)
TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519)
TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519)

Files.com supports the following TLS v1.2 cipher suites for HTTPS:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096)
TLS_DHE_RSA_WITH_AES_256_CCM_8 (dh 4096)
TLS_DHE_RSA_WITH_AES_256_CCM (dh 4096)

FTPS

Files.com supports the following TLS v1.2 cipher suites for FTPS:

TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048)
TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048)
TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) 

A Note About CBC Ciphers

Files.com currently supports both CBC (Cipher Block Chaining) and GCM (Galois/Counter Mode) ciphers for FTPS connections. CBC ciphers remain common but have known design flaws. TLS v1.2 reduces many of these risks, but security experts no longer consider CBC ciphers fully secure.

GCM ciphers offer stronger security and performance, and are the preferred choice. Many FTPS clients do not yet support GCM, particularly those used in automated and legacy-managed file transfer (MFT) workflows. As of 2025, nearly half of Files.com customers running automated FTPS workflows still rely on CBC ciphers to connect to their counterparties.

Files.com plans to phase out CBC ciphers from the default secure FTPS mode. After the change, customers who need CBC ciphers must opt in to our optional support for legacy (less secure) cipher modes.

We're carefully monitoring industry trends and client compatibility. BoxExternal LinkThis link leads to an external website and will open in a new tab removed CBC cipher support for FTP in early 2025. Files.com supports more automation-heavy workflows, including on-premise and legacy MFT environments, and those use cases require a slower transition. We expect to make this change in 2026 or 2027, depending on how quickly FTPS clients adopt GCM support.

SFTP

SFTP does not use TLS or SSL. It implements its own encryption standards and cipher naming.

By default, Files.com supports the following security algorithms for SFTP:

TypeAlgorithms
Key Exchange

curve25519-sha256

curve25519-sha256@libssh.org

curve448-sha512

diffie-hellman-group-exchange-sha256

diffie-hellman-group18-sha512

diffie-hellman-group17-sha512

diffie-hellman-group16-sha512

diffie-hellman-group15-sha512

diffie-hellman-group14-sha256

Server Host Key Algorithms

ssh-rsa

rsa-sha2-256

rsa-sha2-512

Encryption

chacha20-poly1305@openssh.com

aes128-ctr (a.k.a. AES-128 SDCTR [AES-NI accelerated])

aes192-ctr (a.k.a. AES-192 SDCTR [AES-NI accelerated])

aes256-ctr (a.k.a. AES-256 SDCTR [AES-NI accelerated])

aes128-gcm@openssh.com

aes256-gcm@openssh.com

MAC

hmac-sha2-256

hmac-sha2-512

hmac-sha1

hmac-sha2-512-etm@openssh.com

hmac-sha2-256-etm@openssh.com

hmac-sha1-etm@openssh.com

A Note About HMAC-SHA1

Files.com supports hmac-sha1 and hmac-sha1-etm@openssh.com as MAC algorithms for backward compatibility with older SFTP clients. Vulnerability scanners commonly flag these because they pattern-match on the string "SHA1" without distinguishing the cryptographic context. The flag is a compliance or policy observation, not a demonstration of an exploitable weakness.

The attacks that led to SHA-1's deprecation are collision attacks. The SHAttered collision in 2017 and the chosen-prefix collision in 2020 allow an adversary to find two different inputs that hash to the same value, which breaks digital certificates and signatures. HMAC-SHA1 does not rely on collision resistance. HMAC is a keyed message authentication construction whose security reduces to the underlying hash function behaving as a pseudorandom function, a substantially weaker assumption that collision attacks do not affect. There is no known practical attack against HMAC-SHA1 — this is the consensus position of the cryptographic community, not a Files.com opinion. NIST SP 800-131AExternal LinkThis link leads to an external website and will open in a new tab deprecated SHA-1 for digital signature generation but explicitly continued to permit it in HMAC, key derivation, and random number generation, because those uses do not depend on collision resistance.

The SSH MAC also operates within an already-encrypted channel with ephemeral per-session keys. An attacker would need to break HMAC-SHA1 within the lifetime of a single session's key material. There is no offline, accumulate-and-attack-later vector as there is with a long-lived SHA-1 certificate.

Files.com prefers stronger MAC algorithms: hmac-sha2-256, hmac-sha2-512, their Encrypt-then-MAC variants, and AEAD ciphers such as aes128-gcm@openssh.com and chacha20-poly1305@openssh.com that incorporate authentication without a separate MAC. SSH negotiates the strongest algorithm both sides support, so a modern client connecting to Files.com will not use HMAC-SHA1. HMAC-SHA1 is only reached when a client is too old to offer anything stronger. In that case, it remains a cryptographically sound choice. Dropping it would leave you unable to connect until you replace software your vendor may no longer support.