The security settings page allows the administrator to configure all aspects of Cerberus FTP Server SSL/TLS and SSH security.
The Security > General page of the Server Manager
General
| Enable SSL/TLS | This must be enabled to allow secure access to the server. NOTE: A certificate and private key must be available before TLS/SSL encryption is available. |
| Enable FIPS 140-2 | Enable the FIPS 140-2 certified encryption module for Cerberus FTP Server. Selecting this option enables encryption using only FIPS 140-2 certified algorithms. Only available in the Professional and Enterprise edition. |
Server Key Pair
Digital Certificate Support
Cerberus FTP Server supports RSA, DSA, and Elliptical Curve (EC) keys. Support for elliptical curve ciphers with FTPS and HTTPS is available with Cerberus FTP Server 6.0 and higher.
There are generally two options for obtaining a digital certificate (with private key):
- You can generate your self-signed certificate using the Cerberus Create Cert button.
- You can obtain a certificate from a recognized certificate authority (CA)
Which option is more appropriate depends upon your goals. If you just want to make sure that client and server connections are securely encrypted, then a self-signed certificate is all you need. Self-signed certificates have the benefit of being easily created through Cerberus and are completely free.
If your goal is to make sure that your clients can verify that the server they are connecting to is legitimate and ensure that clients do not see any warning messages about being “unable to verify the server”, then you will need to use a certificate signed by a trusted CA. You will have to contact one of the recognized CAs (such as Comodo, Thawte, Verisign, and GoDaddy) and request a server certificate. Take a look at our help page on generating Certificate Signing Requests for more information about using a CA-signed certificate.
A note about secure connections: Cerberus supports FTPS, FTPES, SFTP, and HTTPS encryption. To establish a secure connection you must connect to the server with a client that supports one of those secure methods. For secure FTPES, FTPS, or SFTP, this will require a dedicated FTP client, not a web browser. No web browsers natively support any type of secure FTP.
We have documentation available that walks you step-by-step through the process of using a self-signed certificate or importing a certificate from a third-party certificate authority.
| Certificate Path | The full path to your public certificate. The public certificate is exchanged with the client during TLS/SSL encryption and is examined by the client to verify the server. Supported key types include RSA, DSA, and Elliptical Curve keys. |
| Private Key Path |
This is the server’s private key. The private key is used to encrypt messages to the client. The client can use the server’s public key to decrypt messages encrypted with the server’s private key. The private key is not sent to the client. If your public and private key are in the same file then set this path to be the same as the Public Certificate. NOTE: The public and private key can be in the same file. If your public and private key are in the same file then set this path to the same path as your Public Certificate path. Cerberus understands both DER and PEM-encoded certificate formats. |
| Needs Key Password | Check this option if the digital certificate is encrypted. Enter the key password used to decrypt your digital certificate. |
| CA Certificate Path | A file containing a PEM-encoded list of Certificate Authorities with which to verify client certificates against. Cerberus FTP Server will also use this file to load and send the entire certificate chain for the server certificate when a client connects. Many CAs call this a CA bundle file. |
| Create Self Signed Cert | Cerberus will generate a Self-Signed Certificate that will allow encrypted connections. |
| Verify | Cerberus will attempt to verify that the certificate at the Public and Private key paths is recognized and readable with the given password. To view Certificate Information press the update button. |
SSH Server Key Pair
Before Cerberus FTP Server Version 12, a change or renewal of the SSL Server Key Pair would generate a new SSH Server Key Pair, requiring SFTP clients to reach the host key to connect. As of Cerberus FTP Server 12, Cerberus will create a permanent SSH Server Key Pair based on the first SSL certificate added to Cerberus. Future renewals or changes to the SSL Certificate Server Key Pair will not affect or change the SSH Server Key Pair, avoiding having to recache a new host key. If you do require a change to the host key and you are using Cerberus 12 or above, please reach out to Cerberus Support at support@cerberusftp.com for assistance.
Advanced TLS Security Settings
As of Cerberus FTP Server, the TLS 1.2 and below and TLS 1.3 sections have information dropdowns. Click the blue icon to the right of Cipher Strings and Cipher Suites for a description of the format, defaults, and options for each string.
Advanced TLS tab of the Security page
As of Cerberus FTP Server 12.11, click Refresh Cipher List in the Testing section to see an updated list of cipher suites that will be activated by the enabled protocols and requested cipher strings. As you make changes to the various selections, just click refresh to see what the cipher list will contain.
Security Profiles
These are common security settings. Selecting a security profile from the dropdown list will immediately modify the server’s security settings to match that profile.
Server Cipher Preference
During the SSL/TLS session negotiation, the connecting client sends an ordered list of cipher suites to the server. The first suite on the list is the one most preferred by the client. Normally, the server honors the client's preference by selecting the suite most preferred by the client among the list of suites that both the client and server support.
If this option is selected, the server selects the suite that the server itself most prefers among those that both the client and server support. This can be used to, for example, enforce that the strongest cipher that both the server and client support be used for the connection.
Prioritize ChaCha20-Poly1305 Ciphers
Administrators with users transferring files from older mobile phones without built-in AES support can select the checkbox 'Prioritize ChaCha20-Poly1305 Ciphers'. This option will allow configurations with 'Use Server Cipher Preference' also enabled to use ChaCha20-Poly1305 when a device offers it at a higher client preference due to power and speed concerns. NOTE: ChaCha20-Poly1305 is not available in FIPS mode.
Cipher Strings for TLS v1.2 and below
| SSL v3.0 |
The SSL v3.0 protocol is considered obsolete and insecure. All clients should be restricted to TLS (preferably 1.2 or higher). The SSL v3.0 option has been available for rare situations where a legacy device or service can only use that protocol, and the network is tightly controlled and segmented. Enabling these options will prompt a server warning that your configuration is insecure. SSL v3.0 should be disabled. |
| TLS v1.0 |
TLS v1.0 was released as the first version of the TLS protocol in 1999 and published as IETF RFC 2246. Although usage of TLS v1.0 is fairly common, TLS v1.0 is very similar to SSL v3.0 and requires workarounds in both the client and server to work securely for all cipher suites. TLS v1.0 is also unable to use modern cipher suites that offer greater security and efficiency. For maximum security, we recommend disabling TLS v1.0. |
| TLS v1.1 |
TLS v1.1 is the second version of TLS and was released in 2006. TLS v1.1 fixes some security problems in TLS v1.0, such as removing the need for many of the workarounds built into clients and servers. Furthermore, many deployed clients and servers of TLS v1.0 do not implement these workarounds, so TLS v1.1 is a good improvement over TLS v1.0 and is considered more secure. More information about the TLS v1.1 protocol can be found in IETF RFC 4346. For maximum security, we recommend disabling TLS v1.1. |
| TLS v1.2 |
TLS v1.2 is the minimum most secure version of TLS available in Cerberus FTP Server. TLS v1.2 is considered the minimum version of TLS to support highly secure traffic. TLS v1.2 is defined in IETF RFC 5246. As of Cerberus FTP Server 12.11, we introduce new capabilities for TLS 1.2 including ARIA and ChaCha20-Poly1305 cipher suites. It is OK to have TLS v1.2 activated if you want to support older clients, but we recommend moving to TLS v1.3 after updating to Cerberus 12.11. |
Cipher Strings for TLS v1.3
| SSL v3.0 |
TLS v1.3 is the most secure version of TLS available in Cerberus FTP Server. TLS 1.3 is now a protocol option for TLS-based transfers, including FTP/S, HTTPS, and SOAP. TLS 1.3 will be automatically enabled for transfers and SOAP. At this time, TLS 1.3 supports five cipher suites:
The last two require an ECDSA certificate and are not widely supported and therefore are not enabled by default. Although each configuration will be unique, in our testing, we have found OpenSSL 3.0 has a faster connection setup time resulting in lots of smaller transfers being faster overall than with 1.0.2. For maximum security, we recommend enabling TLS v1.3. |
Upgrade Notes
As of Cerberus 12.11, Cerberus uses OpenSSL v3.0.7 or above. Some security changes were made in OpenSSL 3 which will impact clients still enabling TLS 1.0 and TLS 1.1; these now only work at security level 0 except when RSA key exchange without SHA1 is used which Cerberus does not support. In addition, X509 certificates signed using SHA1 will no longer be trusted without setting the security level to 0.
Cerberus currently achieves similar goals as the security level using the Security Profiles dropdown. To maintain compatibility with previous versions of Cerberus, we automatically set the security level to zero. Administrators can override this by adding @SECLEVEL=x to the Cipher Strings where x can be 0 to 5.
Level 1 is OpenSSL’s default requiring at least 80 bits of security;
Level 2 requires 112 bits;
Level 3 requires 128 bits,
Level 4 requires 192 bits;
Level 5 requires 256 bits of security.
For new installs, TLS 1.0 and 1.1 will be disabled by default.
SSL/TLS Ciphers
The ciphers that Cerberus uses during secure connection negotiation for TLS/SSL can be controlled through a text string. The Test button will list the ciphers available with the given string.
An example string:
EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!CAMELLIA
The string follows the same cipher string format as the OpenSSL ciphers string
2FA (Duo Security Auth API)
2FA tab on the Security page of the Server Manager
Enable DUO 2FA Integration
Duo combines modern two-factor authentication with advanced endpoint security solutions to protect users from account takeovers and data breaches.
Use this section to integrate the HTTP/S web client with DUO Security's 2-factor authentication API. Enabling this integration will replace the default HOTP-based one-time password system with DUO's implementation.
You may review our Enabling Two-Factor Authentication document for the steps to enable this feature.
Server Verification
| Verify Remote Host Certificates | Turning Server Verification off is global, overriding all other settings throughout Cerberus. Turning verification off is the less secure option and is only provided as a temporary fail-safe, such as a certificate issue causing a critical service outage. |
| Max Verify Depth |
This determines how many issuer certificates Cerberus will follow when verifying. Administrators may increase this value if remote hosts have long certificate chains. |
| Additional Trusted Certificates |
Administrators may provide a path to a PEM file containing additional certificates that Cerberus should trust when verifying remote servers. Use this option when Cerberus should trust certificates that cannot or should not be imported to the operating system certificate store. |
Client Certificate Verification
About Certificate Authorities
You only need to worry about setting up and validating against a certificate authority if you (the server) want to authenticate the certificates coming from your FTPS and HTTPS clients. If you are not concerned with verifying your FTPS and HTTPS clients using certificates, then you can safely ignore all of the certificate authority configuration information. Just select the No verification setting (the default).
Note: Client certificate verification is completely separate from SSH SFTP public key authentication. SSH SFTP public key authentication is configured on a per-user basis.
Cerberus FTP Server can be configured to require FTPS and HTTPS clients to verify themselves using digital certificates. When given a CA file, Cerberus will verify that the client certificate is signed and valid for the given certificate authorities. Cerberus will also make sure the certificate hasn’t been revoked if a CRL is specified.
This feature is only available in Cerberus FTP Server Professional and Enterprise edition and currently only applies to FTPS, FTPES, and HTTPS connections.
| No Verification | This is the default option. Cerberus will not require nor will it verify digital certificates |
| Verify Certificate | Cerberus will attempt to verify that the certificate presented by the client is signed and valid. It will compare the certificate against the certificate authorities present in the CA Certificates File. Any FTPS or HTTPS connection attempts without a valid certificate will be denied when this option is selected. |
| CRL File | A file containing a PEM or DER-encoded list of key serial numbers that have been revoked. Note, the CRL must have been signed by the CA certificate. |
Comments
0 comments
Article is closed for comments.