21st September 2020

Scoring an A+ at SSLlabs.com with Citrix Access Gateway in 2020

Make your Citrix Netscaler / Access Gateway a safer place

Overview

First of all, I’m not a Citrix product expert, I’m just an IT Security Engineer. This blog article is talking about how you can score an A+ rating on SSL Labs with your Citrix Access Gateway. The way to gain the A+ rating on SSL Labs has been explained in different articles on the internet. For the company I work for, I’ve created a Security Paper with all of the changes required to gain the A+ rating and my idea was to share this document online with the community.

I will walk you through all of the changes I have made on the Citrix Access Gateway to get the A+ rating. In each section, I will do a short explanation of the changes. I will show you how the changes can be made via the CLI and then via the GUI. Do you have any improvements for this paper, let me know!

Firmware

Make sure that you’re Access Gateway is running on the latest firmware. At the time of writing, the Citrix Access Gateway is running on firmware version NS12.1 56.22.nc.

Encryption protocols

Make sure that you enable TLSv1.2 and TLSv1.3. You can disable TLSv.1.0 and TLSv1.1. SSLv3 [RFC6101] is an obsolete and insecure protocol, you should already have disabled SSLv3 since there is a known vulnerability known as the POODLE. I regularly come across Netscalers and Access Gateways where SSLv3 is still enabled.

CLI

To disable the TLS/SSL-version described as above and enable TLSv1.2 and TLSv1.3.

set ssl vserver Name_of_NetScaler_vServer -ssl3 DISABLED -tls1 DISABLED -tls11 DISABLED -tls12 ENABLED -tlsS13 ENABLED

GUI

Go to Citrix Gateway –> Virtual Servers and select the virtual server and click on ‘Edit’, navigate to SSL Parameters and make sure that only TLSv12 and TLSv13 are selected.

Citrix Access Gateway TLSv12 and TLSv13
Enable TLSv1.2 and TLSv1.3

Custom Cipher Groups

The predefined DEFAULT Cipher Group which is enabled by default contains legacy ciphers that have to be considered as insecure. To ensure that the Access Gateway is not using weak ciphers you have to create a custom defined cipher group.

My recommendation is to note the creation date of the cipher group in the name of the cipher group. By adding the creation date to the name of the cipher group, it’s handy for later use. You know when the group was created and when new ciphers become available from a later date, that you need to add them to the cipher group.

NOTE: It’s important to add the ECDHE ciphers at the top of the group, this is necessary for the configuration of Perfect Forward Secrecy with ECDHE. See the ‘Perfect Forward Secrecy’ section for more information.

add ssl cipher SecureCiphers_20200610
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-ECDSA-AES256-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-ECDSA-AES128-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-ECDSA-CHACHA20-POLY1305
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-DHE-RSA-AES-256-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-DHE-RSA-AES-128-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-DHE-RSA-AES128-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-DHE-RSA-CHACHA20-POLY1305
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-AES256-GCM-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-AES-128-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-AES-256-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-AES128-GCM-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.3-AES256-GCM-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.3-CHACHA20-POLY1305-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.3-AES128-GCM-SHA256

GUI

Go to Traffic Managenet –> SSL –> Cipher Groups and click on ‘Add’ to create a cipher group, give this cipher group an name and add the secure ciphers to this group.

Citrix Access Gateway Cipher Groups
Add new Cipher Group

To bind this cipher group to an existing virtual server go to the Configuration tab and click on Citrix Gateway –> Virtual Servers. Modify the virtual server and click on the edit pencil near SSL Ciphers, make sure that you have removed the DEFAULT cipher group and add the newly created cipher group, in this example, called: SecureCiphers_20200610.

Citrix Access Gateway Qualsys A+ SSL Ciphers
Cipher Group

SSL Renegotiation

What’s the purpose of SSL/TLS Renegotiation? The SSL renegotiation process is the new SSL handshake process over an established SSL connection. The SSL renegotiation process can establish another secure SSL session because the renegotiation messages, including the types of ciphers and encryption keys, are encrypted and then sent over to the existing SSL connection.

The Access Gateway does not request the client to renegotiate SSL connection. However, if the client or the back end server initiates a renegotiation process, the appliance supports the process. If you are looking for a more in-depth explanation about SSL Renegotiation, I recommend to watch this Youtube video:

F5 DevCentral: Whiteboard Wednesday: SSL Renegotiation

CLI

set ssl parameter -denySSLReneg NONSECURE

GUI

Go to Traffic Management –> SSL and click on Change advanced SSL settings. In the following screen change the Deny SSL Renegotiation to NONSECURE.

Citrix Access Gateway Qualsys A+ Rating SSL Renegotiation
SSL Renegotiation

Perfect Forward Secrecy

The Perfect Forward Secrecy is a security measure that reduces the risk of being compromised by creating a unique session key for each transaction. If you want to take a closer look at the Perfect Forward Secrecy process, I recommend you to watch this Youtube video:

F5 DevCentral: Perfect Forward Secrecy

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

ECDHE

In this Security Paper, I will only show you the configuration of Perfect Forward Secrecy with ECDHE. My recommendation is to configure ECDHE instead of DHE. ECDHE has better performance that DHE with the use of stronger ciphers. Check the References section for the Citrix document to configure Perfect Forward Secrecy with DHE.

CLI

Bind the four ECC Curves to the SSL Virtual Server.

bind ssl vserver <vServerName> -eccCurveName P_256
bind ssl vserver <vServerName> -eccCurveName P_384
bind ssl vserver <vServerName> -eccCurveName P_224
bind ssl vserver <vServerName> -eccCurveName P_521

GUI

Go to Configuration –> Access Gateway select the server you want to edit and go to the ECC Curve section and click on the ECC Curves.

Citrix Access Gateway Qualsys A+ Rating ECC Curve
ECC Curve

Make sure that these four ECC Curves are binded to this server.

Citrix Access Gateway Qualsys A+ Rating SSL Curve Binding
Four ECC Curves for Perfect Forward Secrecy (FPS)

If you have followed my instruction to add the ECDHE ciphers at the top of the cipher group, the Perfect Forward Secrecy configuration properly.

Check your configuration

If you have followed my instruction to add the ECDHE ciphers at the top of the cipher group, the Perfect Forward Secrecy configuration properly. To check if Perfect Forward Secrecy is working, you can connect to the website. Through the Developers Tools in the Security tab, you can check the connection. Only if you see TLS1.2 with ECDHE (or with DHE), means that Perfect Forward Secrecy is well configured.

Citrix Access Gateway Qualsys A+ Rating Perfect Forward Secrecy
Check the Perfect Forward Secrecy configuration

HTTP Strict Transport Security

The HTTP Strict Transport Security (also known as HTST) is a response header which is telling the clients that they have to use the HTTPS website, instead of HTTP. This web security mechanism is to prevent the Access Gateway against various attacks like man-in-the-middle attacks and cookie hijacking.

First, the Rewrite Action needs to be configured. Go to Configuration –> AppExpert –> Rewrite –> Actions click here on Add. Fill in the required fields.

Name: STS_Header Type: INSERT_HTTP_HEADER Header Name: Strict-Transport-Security Expression: “max-age=157680000”

NOTE: The ‘Expression’ value is in seconds.

Citrix Access Gateway Qualsys A+ Rating HTST Header
HTST Header: Rewrite Action

After the creation of the Rewrite Action the policy needs to be created. Go into the same Rewrite panel to Policies and click on Add. Fill in the required fields.

Name: HSTS_Policy Action: STS_Header (This is the previously created Rewrite Action) Expression: True

Citrix Access Gateway Qualsys A+ Rating HTST Header Policy
HTST Header: Policy

To bind this policy to the Virtual Server, go to Citrix Gateway –> Virtual Servers and select the virtual server. Scroll down to the bottom of the screen at the Response Policies you add the newly created policy HSTS_Policy.

If you want to test if the STS Header is being inserted go to the web portal which is bound to the Virtual Server. Open the Developer Tools –> Network, here you can see that the STS Header is being inserted.

Citrix Access Gateway Qualsys A+ Rating HTTP Strict Transport
STS Header is being inserted

Complete Certificate Chain

To offer a complete certificate chain, you make sure that the Root CA certificate and the Intermediate certificate is also installed on the Citrix Access Gateway. You can bind those certificates to your certificate to get your chain complete. For more information how certificate chains work, I recommend to read this article:

To make your certificate chain complete, you have to download the certificate bundle (Linux) from your certificate provider. In the Access Gateway go to Traffic Management –> SSL –> Certificates –> Server Certificates and click on Install.

Select the certificate bundle you have received from your certificate authority and click on Install.

Citrix Access Gateway Qualsys A+ Rating Complete Certificate Chain
Install Certificate Bundle (Linux)

After the installation, select your certificate and in the action button click on Link.

Citrix Access Gateway Qualsys A+ Rating Complete Certificate Chain
Certificate Linking

Select the just installed certificate bundle and click on OK.

Citrix Access Gateway Qualsys A+ Rating Complete Certificate Chain
Linking the certificate

The Certificate Chain is now complete.

DNS CAA

A Certificate Authority Authorization (CAA) record, is a DNS-record which is designed to give domain owners an extra layer of security. The CAA record controls which Certificate Authority has the authorization to issue certificates of that domain. This prevents the issuance of a certificate by an unauthorized CA. On this website you can generate your own CAA record:

Fill in your domain (example: gitbook.com) click on Auto-Generate Policy. The following DNS CAA record needs to be added to the DNS server of, in this example gibook.com.

Name            Type    Value
gitbook.com.    CAA     0 issue "digicert.com"
                        0 issue "godaddy.com"
                        0 issue "pki.goog"
                        0 issue "letsencrypt.org"

References

T13nn3s

I'm a cyber security enthusiast! I love my work, I love writing scripts and doing research and pen testing. Big fan of Hack The Box and I learn new things every day to make the internet safer. I blog because I love to summarize my thoughts and share them with you.

View all posts by T13nn3s →

Leave a Reply

Your email address will not be published. Required fields are marked *