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, seeConfigure 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 

• 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 . 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 (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, seeDTLS 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, seeECDSA 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.

• 所有SHA-2签名证书(SHA256 SHA384,沙512) 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. This means that your historical SSL communication was secure earlier but they are no longer secure as 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. This is where configuring Perfect Forward Secrecy (PFS) comes to the rescue.

How does PFS help?

Perfect Forward Secrecy (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 and hence 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 will not be able to arrive at the session key because 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 but this 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 toTraffic Management > SSL > Tools.

   b. ClickCreate 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 toConfiguration > Traffic Management > Virtual Servers.

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

   c. ClickEdit, clickSSL Parameters, and clickEnable DH Param.

   

3. Bind the DHE ciphers to the virtual server.

   a. Navigate toConfiguration > Traffic Management > Virtual Servers.

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

   c. UnderAdvanced Settings, click plus icon next toSSL Ciphersand select the DHE cipher groups and clickOKto 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 toConfiguration > Traffic Management > Load Balancing > Virtual Servers.

   b. Select the SSL virtual server which you want to edit, clickECC Curveand clickAdd Binding.

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

   

   

2. Bind the ECDHE ciphers to the virtual server.

   a. Navigate toConfiguration > Traffic Management > Virtual Serversand select the virtual server on which you want to enable DH.

   b. ClickEdit > SSL Ciphersand select the ECDHE cipher groups and clickBind.

   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 toSystem > Profiles > SSL Profilesand 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 toConfiguration > Traffic Management > Virtual Serversand select the virtual server.

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

   c. ClickOKand clickDone.

   

Configure PFS using SSL using the CLI

At the command prompt, type:

1. Bind ECC curves to the SSL profile.

   bind sslprofile  -eccCurveName  

2. Bind the ECDHE cipher group.

   bind sslprofile  cipherName  

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

   set sslprofile  cipherName  cipherPriority  

4. Bind the SSL profile to the virtual server.

   set SSL vserver  sslProfile