How Do I Configure Perfect Forward Secrecy (PFS) on NetScaler?

How Do I Configure Perfect Forward Secrecy (PFS) on NetScaler?

book

Article ID: CTX205282

calendar_today

Updated On:

Description

This article describes how to configure PFS on NetScaler.

Use Case

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

Introduction to the problem being solved by Perfect Forward Secrecy (PFS)

A 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.
User-added image

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 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 future, he will be able to get hold of pre-master secret using which he can arrive at the session key. This session key can now be used by the attacker to decrypt all the SSL conversations. This means that your historical SSL communication may have been secure at that time but they are no longer 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) solves this problem 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 server key should 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.
User-added image

Explanation with example

Assume we are using DHE for attaining PFS. The DH algorithm ensures that even though a hacker gets hold of server’s private key, he will not be able to arrive at the session key because the session key as well as 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 Ephemeral Diffie-Hellman key exchange which creates new temporary keys for each SSL session.

The flipside of creating a new key for each session is that it requires some amount of additional computation but this can be overcome by using Elliptic Curve which have smaller key sizes

PFS feature support on NetScaler

PFS can be configured on NetScaler 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).


Instructions

PFS can be obtained by configuring DHE or ECDHE. Both configurations have been explained below.

Configuring DHE

  • Step 1: Generate a DH key

Note: Generating a 2048-bit DH key may take a long time (up to 30 minutes).

On GUI: Go to Traffic Management > SSL > Tools > Create Diffie Helman (DH) Key.

User-added image

User-added image

  • Step 2: Enable DH Param for the SSL virtual server and attach the DH key to the SSL virtual server

  • set ssl vserver <vserverName> -dh <Option> -dhCount <RefreshCountValue> -filepath <string> 

User-added image

The dhCount specifies the number of SSL sessions for which the current key will be used. In this example dhCount 1000 specifies that after every 1000 SSL connections, a new key will be generated.

  • On GUI: Go to Configuration > Traffic Management > Virtual Servers > Select the virtual server on which you want to enable DH > Edit > SSL Parameters > Enable DH Param.

User-added image

User-added image

  • Step3: Bind the DHE ciphers to the virtual server

  • On GUI: Go to Configuration > Traffic Management > Virtual Servers > Select the virtual server on which you want to enable DH > Edit > SSL Ciphers > Select the DHE cipher groups > Bind.

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

User-added image

User-added image

User-added image

Configuring ECDHE

  • Step 1: Bind the ECC curves to the SSL virtual server

  • To bind ECC curves from the CLI you can execute the following command to bind an ECC curve to a vserver:

bind ssl vserver <vServerName> -eccCurveName <eccCurveName>

User-added image

  • From the GUI, Go to Configuration > Traffic Management > Load Balancing > Virtual Servers > Select the SSL vserver which you want to edit > ECC Curve > Add Binding and bind the required ECC curve to the vserver.

User-added image

User-added image

  • Step 2: Bind the ECDHE ciphers to the virtual server

  • On GUI: Go to Configuration > Traffic Management > Virtual Servers > Select the virtual server on which you want to enable DH > Edit > SSL Ciphers > Select the ECDHE cipher groups > Bind.

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

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

User-added image

User-added image

User-added image

 

Note: For each case verify that the NetScaler appliance supports the ciphers you would like to use for the communication. Refer to Ciphers Supported by the NetScaler Appliance for more information.

Configuring PFS using SSL Profile

Note: Option to configure PFS (cipher,ECC) using SSL Profile is introduced from 11.0 64.x release onwards. Ignore the section below if on older versions.
Refer to “What is SSL profile on NetScaler” and “How do I setup SSL profile on NetScaler?” guides for more information on SSL profiles.
To enable PFS using SSL profiles, a similar configuration (as explained in earlier configuration sections in the article) needs to be done but on the SSL profile instead of directly configuring on virtual server.

  • Step 1: Bind the ECC curves and the ECDHE ciphers on the SSL Profile

  • On GUI: Go to System > Profiles > SSL Profiles > Chose the Profile you want to enable PFS on > Bind the ECDHE ciphers.

(ECC curves are already bound by default to all SSL Profiles)

User-added image

  • On CLI:

Bind ECC curves to the SSL Profile using following command:
bind sslprofile <SSLProfileName> -eccCurveName <Name_of_curve>

User-added image

Bind the ECDHE ciphergroup using following command:

bind sslprofile <SSLProfileName> cipherName <ciphergroupName>

Set the priority of ECDHE cipher as 1:
set sslprofile <SSLProfileName> cipherName <ciphergroupName> cipherPriority <positive_integer>

User-added image

  • Step 2: Bind the SSL profile to the virtual server

  • On CLI:

set SSL vserver <vservername> sslProfile <SSLProfileName>

User-added image

  • On GUI: Go to Configuration > Traffic Management > Virtual Servers > Select the virtual server > Edit > SSL Profile.

User-added image

Issue/Introduction

This article describes how to configure PFS on NetScaler.

Additional Information

Citrix Documentation -Ciphers Supported by the NetScaler 10.5 Appliance
Citrix Documentation -Ciphers Supported by the NetScaler 11.0 Appliance
Citrix Documentation -Ciphers Supported by the NetScaler 11.1 Appliance
Citrix Documentation - Configuring ECDHE Ciphers

User-added image