Which ciphers to use on a Citrix ADC /NetScaler?

SSL on Citrix NetScaler ADCRecently I found myself in a discussion with an other Citrix architect about number of ciphers needed. I had added as little as fife ciphers to a cipher group. He thought, this is not enough.

Why should we have many ciphers into a cipher group?

To be honest, I don’t understand. It may look flexible, feature-rich and mighty. Customers may get impressed, that’s cool.

Why I avoid putting many ciphers into a cipher group?

Through out the last years we have seen many flaws in ciphers. I remember suggesting CBC ciphers to my customers, as they seemed to be state of the art. Today, CBC is not considered to be secure any more. Before suggesting CBC I suggested RC4, as they are of little cost in terms of CPU, but RC4 turned out to be rather insecure. The more different cipher suites you add, the more likely any of them turns out to be insecure in some days, month or years.

So in my point of view, the fewer ciphers we add, the less likely a problem will occur.

Which ciphers to add

The metrics provided by Citrix

Citrix metrics (number of SSL transactions per second) are based on non- ECDHE ciphers. ECDHE will lower the number of SSL tps dramatically. However it does not affect the through put.

Transactions per second

Establishing an SSL connection is a huge overhead. Creating sessions turns out to be the bottle-neck in many deployments, both, virtual and physical ones, while SSL throughput is relatively harmless.

The reason for this is, SSL/TLS uses asymmetric encryption during session initialization. Asymmetric encryption (private / public key encryption) is used to transfer the SSL session key from client to server. The burden is huge even though it’s just a small amount of data.

The number of SSL transactions per second is mainly limited by the CPU. CPUs differ greatly in their ability to perform SSL transactions. Intel puts a lot of effort into developing CPUs that can do this well. Therefore, newer CPUs are usually dramatically better than old ones, but problem still occur.

SSL throughput

SSL throughput is also related to the CPU, but to the license as well: It night get limited by the license.

Transferring data is done, using a symmetric encryption. Waste of CPU cycles depends on encryption algorithm and key-strength (128 or 256 bit).

Web servers versus Citrix Gateway

There is a big difference between web servers and gateways: While a single user usually creates 6 to 18 TCP connections to a web-server, a gateway user will just create a single connection to each XenApp/XenDesktop (Virtual Apps and Desktops) server. At the same time, an average gateway user will use his connection for several hours, while a web site user will usually leave the server after some minutes. Because of this, the number of SSL transactions per second on web-servers will be way higher than on a gateway server, if SSL throughput on both servers is the same.


Currently (May 2020), both of them are considered to be secure.

AES (Advanced Encryption Standard) had been in use since 2000, and I didn’t hear any concerns about it. We can use AES with 128, 192 oder 256 Bit keys, US laws allow keys from 192 Bit for governmental use. Citrix ADC (NetScaler) allows 128 and 256 bit.

While AES is considered to be secure, it is rather costly in terms of CPU.

CHACHA is based on Salsa20, invented by Bernstein in 2006. It’s an European development. Bernstein had been motivated by American attempts to limit global availability of encryption. Very soon it turned out to be less CPU intensive on most CPUs (also true for x86 CPUs). Same as AES, CHACHA is currently considered to be secure.

The more economical use of the CPU has made CHACHA the encryption method that Google chose as the successor to RC4.

A downside of CHACHA is limited availability on client side. We can’t go with CHACHA alone.

Encryption strength?

I am a clear fan of 128 Bit in environments with low security needs. Why? 256 is not needed to score an A+ and SSL throughput goes up to four times compared to 256 Bit throughput. Sure, we always go up as far as any possible, but what’s the point of doing so? Just because we can? We are children no more!

My choice, my personal APlus Ciphers

I usually create a cipher group and bind following cipher groups into it:

  • TLS1.2-ECDHE-RSA-CHACHA20-POLY130 (used for most clients)
  • TLS1.2-ECDHE-RSA-AES256-GCM-SHA384 (old versions of Edge, Safari and iOS)
  • TLS1.2-DHE-RSA-AES256-GCM-SHA384 (some Android devices, MS Internet Explorer, outdated Edge, Open SSL and Java versions )
  • TLS1.2-ECDHE-RSA-AES128-GCM-SHA256 (as fall-back if 256 Bit is unavailable, or 256 Bit is not needed or allowed)
  • TLS1.2-DHE-RSA-AES128-GCM-SHA256 (as fall-back if 256 Bit is unavailable, or 256 Bit is not needed or allowed)

Scoring an A+ on SSL labs with Citrix NetScaler ADCKeep in mind: The order of ciphers is relevant. Put the ones you want users to use in front.

add ssl cipher APlus_Ciphers
bind ssl cipher APlus_Ciphers -cipherName TLS1.2-ECDHE-RSA-CHACHA20-POLY130 -cipherPriority 16
bind ssl cipher APlus_Ciphers -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384 -cipherPriority 32
bind ssl cipher APlus_Ciphers -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384 -cipherPriority 48
bind ssl cipher APlus_Ciphers -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256 -cipherPriority 64
bind ssl cipher APlus_Ciphers -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256 -cipherPriority 80

Scoring the A-Plus on Citrix ADC in some mouse clicks

Nowadays, all customers want to score an A+ on SSL-labs. In most cases, it does not make sense, however customers always are right.

I don’t use SSL- settings any more, instead I use SSL profiles.

Creating the Diffie Hellman Key (optional)

The first step is an optional one and the most time consuming: The diffie hellman key. It’s described in CTX213335.

Creating a Diffie Hellman key for Citrix ADC / NetScaler
create ssl dhParam 1024-key -gen 2 1024

You may score an A+ without using a DH key. Parameters: Key-size: 512, 1024, 2048. While 512 bit keys can get generated within milliseconds, 1024 bit take seconds and 2048 minutes to complete.

The SSL profile

Instead of repeating settings with all SSL vServers, you should use SSL profiles. SSL profiles are templates, applied to a specific SSL vServer.

There are built in profiles, but you may create profiles on your own. My profiles usually are copies of default profiles, containing following parameters:

Deny SSL renegotiotion: NONSECURE (allow both, client and server, to do renegotiation attempts encrypted only (see renegotiation attack)).

SSL v3, TLS 1.0, TLS 1.1: Disable outdated SSL/TLS versions.

dhFile: The name of the DH key (see above, optional), together with DH param (on/off) and DH Refresh count (0, 500 and more).

HSTS: Hypertext Strict Transport Security makes the difference between A and A+. It’s a request to the browser to request this site via SSL only. This gets stored in Browser at least for Max Age seconds. SSL labs demands 31536000 seconds (1 year) at least.

SNI: Server Name Indication is used, if you need to bind more than a single certificate to a vServer. Don’t forget to bind certificates using the SNI option! SNI is not compatible with all operating systems (but with all current ones)

Citrix NetScaler ADC SSL profiles for an A+ on SSL lab

add ssl profile ssl_profile_frontend_A-Plus -dhCount 1000 -dh ENABLED -dhFile "/nsconfig/ssl/1024-DH" -sessReuse ENABLED -sessTimeout 120 -tls1 DISABLED -tls11 DISABLED -SNIEnable DISABLED -ocspStapling ENABLED -denySSLReneg NONSECURE -encryptTriggerPktCount 10 -dropReqWithNoHostHeader YES -sslTriggerTimeout 10 -HSTS ENABLED -maxage 157680000 -IncludeSubdomains YES

Like always, I would be happy to hear about your concerns. Nobody is perfect, not even me 🙂

2 thoughts on “Which ciphers to use on a Citrix ADC /NetScaler?

Leave a Reply

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