Ciphers available on the Citrix ADC appliances

Your Citrix ADC appliance ships with a predefined set of cipher groups. To use ciphers that are not part of the DEFAULT cipher group, you have to explicitly bind them to an SSL virtual server. You can also create a user-defined cipher group to bind to the SSL virtual server. For more information about creating a user-defined cipher group, see Configure user-defined cipher groups on the ADC appliance.

Notes

RC4 cipher is not included in the default cipher group on the Citrix ADC appliance. However, it is supported in the software on the N3-based appliances. RC4 encryption, including the handshake, is done in software.

Citrix recommends that you do not use this cipher because it is considered insecure and deprecated by RFC 7465.

Use the ‘show hardware’ command to identify whether your appliance has N3 chips.

sh hardware

Platform: NSMPX-22000 16*CPU+24*IX+12*E1K+2*E1K+4*CVM N3 2200100

Manufactured on: 8/19/2013

CPU: 2900MHZ

Host Id: 1006665862

Serial no: ENUK6298FT

Encoded serial no: ENUK6298FT
<!--NeedCopy-->

• To display information about the cipher suites bound by default at the front end (to a virtual server), type: sh cipher DEFAULT
• To display information about the cipher suites bound by default at the back end (to a service), type: sh cipher DEFAULT_BACKEND
• To display information about all the cipher groups (aliases) defined on the appliance, type: sh cipher
• To display information about all the cipher suites that are part of a specific cipher group, type: sh cipher <alias name>. For example, sh cipher ECDHE.

The following links list the cipher suites supported on different Citrix ADC platforms and on external hardware security modules (HSMs):

• Citrix ADC MPX/SDX Intel Lewisburg appliance: Cipher support on a Citrix ADC MPX/SDX Intel Lewisburg SSL chip based appliance
• Citrix ADC MPX/SDX (N3) appliance: Cipher support on a Citrix ADC MPX/SDX (N3) appliance
• Citrix ADC MPX/SDX Intel Coleto appliance: Cipher support on a Citrix ADC MPX/SDX Intel Coleto SSL chip based appliance
• Citrix ADC VPX appliance: Cipher support on a Citrix ADC VPX appliance
• Citrix ADC MPX/SDX 14000 FIPS appliance: Cipher support on a Citrix ADC MPX/SDX 14000 FIPS appliance
• External HSM (Thales/Safenet): Cipher supported on an External HSM (Thales/Safenet)
• Citrix ADC MPX/SDX (N2) appliance: Cipher support on a Citrix ADC MPX/SDX (N2) appliance
• Citrix ADC MPX 9700 FIPS appliance: Cipher support on a Citrix ADC MPX 9700 FIPS with firmware 2.2
• Citrix ADC VPX FIPS and MPX FIPS appliances: Cipher support on Citrix ADC VPX FIPS and MPX FIPS certified appliances

Note:

For DTLS cipher support, see DTLS cipher support on Citrix ADC VPX, MPX, and SDX appliances.

Table1 - Support on virtual server/frontend service/internal service:

Table 2 - Support on backend services:

TLS 1.3 is not supported on the back end.

For the detailed list of ECDSA ciphers supported, see ECDSA Cipher Suites support.

Note

• TLS-Fallback_SCSV cipher suite is supported on all appliances from release 10.5 build 57.x

• HTTP Strict Transport Security (HSTS) support is policy-based.

• All SHA-2 signed-certificates (SHA256, SHA384, SHA512) are supported on the front end of all appliances. In release 11.1 build 54.x and later, these certificates are also supported on the back-end of all appliances. In release 11.0 and earlier, only SHA256 signed-certificates are supported on the back end of all appliances.

• In release 11.1 build 52.x and earlier, the following ciphers are supported only on the front end of the MPX 9700 and MPX/SDX 14000 FIPS appliances:
  • TLS1.2-ECDHE-RSA-AES-256-SHA384
  • TLS1.2-ECDHE-RSA-AES256-GCM-SHA384 From release 11.1 build 53.x, and in release 12.0, these ciphers are also supported on the back end.
• All ChaCha20-Poly1035 ciphers use a TLS pseudo random function (PSF) with the SHA-256 hash function.

Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy ensures protection of current SSL communications even if the session key of a web server is compromised at a later point in time.

Why do you need Perfect Forward Secrecy (PFS)?

An SSL connection is used to secure the data being passed between a client and a server. This connection begins with the SSL handshake that takes place between a client’s browser and the contacted web server. It is during this handshake that the browser and the server exchange certain information to arrive upon a session key which serves as a means to encrypt the data throughout the rest of the communication.

RSA is the most commonly used algorithm for key exchange. The browser uses the server’s public key to encrypt and send across the pre-master secret to a server. This pre-master secret is used to arrive at the session key. The problem in the RSA key exchange approach is that if an attacker manages to get hold of the server’s private key at any point in time in the future, then the attacker gets hold of the pre-master secret using which the session key can be obtained. This session key can now be used by the attacker to decrypt all the SSL conversations. As a result, your historical SSL communication that was secure earlier is no longer secure because the server’s stolen private key can be used to arrive at the session key and thus decrypt any saved historical conversation as well.

The need is to be able to protect the past SSL communication even if the server’s private key has been compromised. Configuring Perfect Forward Secrecy (PFS) helps address this issue.

How does PFS help?

PFS protects the past SSL communication by having the client and server agree upon a new key for each session and keeping the computation of this session key a secret. It works on the basis that compromise of a server key must not result in compromise of the session key. Session key is derived separately at both ends and is never transferred over the wire. The session keys are also destroyed once the communication is complete. These facts ensure that even if someone gets access to the server’s private key, they would not be able to arrive at the session key. Therefore, they would not be able to decrypt the past data.

Explanation with example

Assume that we are using DHE for attaining PFS. The DH algorithm ensures that even though a hacker gets hold of the server’s private key, the hacker cannot arrive at the session key. The reason is that the session key and the random numbers (used to arrive at the session key) are kept secret at both ends and never exchanged over the wire. PFS can be achieved by using the Ephemeral Diffie-Hellman key exchange which creates new temporary keys for each SSL session.

The flip side of creating a key for each session is that it requires extra computation. However, this issue can be overcome by using the Elliptic Curve which has smaller key sizes.

Configure PFS on Citrix ADC appliance

PFS can be configured on a Citrix ADC by configuring DHE or ECDHE ciphers. These ciphers ensure that the secret session key created is not shared on the wire (DH algorithm) and that the session key remains alive only for a short time (Ephemeral). Both the configurations are explained in the following sections.

Note: Using ECDHE ciphers instead of DHE makes the communication more secure with smaller key sizes.

Configure DHE by using the GUI

1. Generate a DH key.

   a. Navigate to Traffic Management > SSL > Tools.

   b. Click Create Diffie Helman (DH) Key.

   Note: Generating a 2048-bit DH key can take up to 30 minutes.

   

   

2. Enable DH Param for the SSL virtual server and attach the DH key to the SSL virtual server.

   a. Navigate to Configuration > Traffic Management > Virtual Servers.

   b. Select the virtual server on which you want to enable DH.

   c. Click Edit, click SSL Parameters, and click Enable DH Param.

   

3. Bind the DHE ciphers to the virtual server.

   a. Navigate to Configuration > Traffic Management > Virtual Servers.

   b. Select the virtual server on which you want to enable DH and click the pencil icon to edit.

   c. Under Advanced Settings, click the plus icon next to SSL Ciphers and select the DHE cipher groups and click OK to bind.

   Note: Ensure that the DHE ciphers are at the top of the cipher list bound to the virtual server.

   

   

   

Configure ECDHE by using the GUI

1. Bind the ECC curves to the SSL virtual server.

   a. Navigate to Configuration > Traffic Management > Load Balancing > Virtual Servers.

   b. Select the SSL virtual server which you want to edit, click ECC Curve and click Add Binding.

   c. Bind the required ECC curve to the virtual server.

   

   

2. Bind the ECDHE ciphers to the virtual server.

   a. Navigate to Configuration > Traffic Management > Virtual Servers and select the virtual server on which you want to enable DH.

   b. Click Edit > SSL Ciphers and select the ECDHE cipher groups and click Bind.

   Note: Ensure that the ECDHE ciphers are at the top of the cipher list bound to the virtual server.

   

   

   

Note: For each case verify that the Citrix ADC appliance supports the ciphers you would like to use for the communication.

Configure PFS using an SSL profile

Note: Option to configure PFS (cipher or ECC) using an SSL profile is introduced from 11.0 64.x release onwards. Ignore the following section if on older versions.

To enable PFS using an SSL profile, a similar configuration (as explained in earlier configuration sections) needs to be done but on the SSL profile instead of directly configuring on a virtual server.

Configure PFS using an SSL profile by using the GUI

1. Bind the ECC curves and the ECDHE ciphers on the SSL profile.

   Note: ECC curves are already bound by default to all the SSL profiles.

   a. Navigate to System > Profiles > SSL Profiles and choose the profile you want to enable PFS on.

   b. Bind the ECDHE ciphers.

   

2. Bind the SSL profile to the virtual server.

   a. Go to Configuration > Traffic Management > Virtual Servers and select the virtual server.

   b. Click the pencil icon to edit the SSL profile.

   c. Click OK and click Done.

   

Configure PFS using SSL using the CLI

At the command prompt, type:

1. Bind ECC curves to the SSL profile.

   bind sslprofile <SSLProfileName> -eccCurveName <Name_of_curve>
   <!--NeedCopy-->
   

2. Bind the ECDHE cipher group.

   bind sslprofile <SSLProfileName> cipherName <ciphergroupName>
   <!--NeedCopy-->
   

3. Set the priority of the ECDHE cipher as 1.

   set sslprofile <SSLProfileName> cipherName <ciphergroupName> cipherPriority <positive_integer>
   <!--NeedCopy-->
   

4. Bind the SSL profile to the virtual server.

   set SSL vserver <vservername> sslProfile <SSLProfileName>
   <!--NeedCopy-->