This article describes how to configure PFS on NetScaler.
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.
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.
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.
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.
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 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).
PFS can be obtained by configuring DHE or ECDHE. Both configurations have been explained below.
On GUI: Go to Traffic Management > SSL > Tools > Create Diffie Helman (DH) Key.
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.
Note: Ensure that the DHE ciphers are at the top of the cipher list bound to the virtual server.
bind ssl vserver <vServerName> -eccCurveName <eccCurveName>
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.
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.
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.
(ECC curves are already bound by default to all SSL Profiles)
Bind ECC curves to the SSL Profile using following command:
bind sslprofile <SSLProfileName> -eccCurveName <Name_of_curve>
bind sslprofile <SSLProfileName> cipherName <ciphergroupName>
Set the priority of ECDHE cipher as 1:
set sslprofile <SSLProfileName> cipherName <ciphergroupName> cipherPriority <positive_integer>
set SSL vserver <vservername> sslProfile <SSLProfileName>
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