Which cyphers to use on a Citrix ADC /NetScaler?


SSL on Citrix NetScaler ADClatest update: February 4th 2021

Recently I found myself in a discussion with another Citrix architect about the number of cyphers needed. I had added as little as fife cyphers to a cypher group. He thought this is not enough.

Why should we have many cyphers into a cypher 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 cyphers into a cypher group?

Throughout the last years, we have seen many flaws in cyphers. I remember suggesting CBC cyphers to my customers, as they seemed to be state of the art. Today, CBC is not considered to be secure any more, as they tend to be vulnerable to Padding-Oracle attacks. 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 cypher suite families you add, the more likely one of them might turn out to be insecure, some days, month or years later.

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

Which cyphers to add

The metrics provided by Citrix

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

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 the problem still occurs.

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 symmetric encryption. Waste of CPU cycles depends on the encryption algorithm, key-strength (128 or 256 bit) and CPU in use.

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 or 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 a 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. Because of this, we can’t go with CHACHA alone.
Unfortunately, Citrix WorkspaceApp currently (2/21, version 1910) does not support ChaCha cyphers. So no point to add ChaCha cyphers to the gateway, if we want to use any kind of “Citrix Client”. It would make sense if you plan to widely use the HTML client.

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!

TLS 1.2 or TLS 1.3?

During the design phase of TLS 1.3, there had been several goals:

  • lighter.
  • faster.
  • get rid of all outdated functions as they are of no use and potentially exploitable.

So TLS 1.3 can be expected to be both, faster and more secure than TLS 1.2. But currently, there is not a broad base of TLS 1.3 servers and due to this, TLS 1.3 is not that well-tested as TLS 1.2 is. There may still be some non-discovered flaws in it. So from the perspective of security, I would currently stay with TLS 1.2, from the perspective of performance I would tend to TLS 1.3. This blog is about TLS 1.2 on Citrix ADC / NetScaler.

If your decision is TLS 1.3, you may read about it here. Be aware, this is a big step and needs to be well planned.

My choice, my personal APlus Ciphers, for websites

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

  • TLS1.2-ECDHE-RSA-CHACHA20-POLY130 (used for most clients, but does not work with Citrix Workspace app)
  • TLS1.2-ECDHE-RSA-AES256-GCM-SHA384 (old versions of Edge, Safari and iOS and Citrix Workspace app)
  • 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 a fall-back if 256 Bit is unavailable, or 256 Bit is not needed or allowed)
  • TLS1.2-DHE-RSA-AES128-GCM-SHA256 (as a 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 cyphers is relevant. Put the ones you want users to use in front.

add ssl cipher APlus_Ciphers
#does not work with Citrix Workspace app
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

For TLS 1.3 I bind following cyphers as well:

bind ssl cipher APlus_Ciphers -cipherName TLS1.3-CHACHA20-POLY1305-SHA256 -cipherPriority 4
bind ssl cipher APlus_Ciphers -cipherName TLS1.3-AES256-GCM-SHA384 -cipherPriority 8
bind ssl cipher APlus_Ciphers -cipherName TLS1.3-AES128-GCM-SHA256 -cipherPriority 12

These cyphers have to be bound on top of the list, so I use higher priorities (with Citrix ADC / NetScaler 0 is the highest priority possible)

My choice for Citrix Workspace App

Following CTX250104, the workspace App just supports following cyphers:


Oas AES_CBC cyphers are vulnerable to the padding oracle attack, GCM is the only option in highly secure environments. You would have to go with TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 if security is your main concern. However, a padding oracle attack is not that easy to do, rather costly in terms of CPU and skills, so I usually add all three of them.

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, so we, the consultants, have to do what they force us to do.

I never use SSL- settings any more, instead, I am using SSL profiles. There is no way of using SSL settings with TLS 1.3.

When does an A+ not make sense?

We have to do all effort possible to protect our and our customer’s data. That’s true for sure. But what about a website like this one? What do I protect? Sure, the government and some bad guys can’t see, which of my pages you’re currently watching (however, they know the domain you’re currently connected too).

You are very likely currently using 256 Bit Chacha. But is it worthwhile? Would not 128 bit be good enough? Even 64 Bit would be fine?

Let’s be even more provocative: Why does this website need SSL? I have a clear answer: “Because everyone nowadays is using SSL”. “Because I can”. I have both, knowledge and CPU power, so I do.

Please, don’t misunderstand: I would never use your e-shop if you would not use proper encryption. I would consider this to be a horrible imposition. But websites like this one? I would not spend extra money on better CPUs to be “more secure”

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 the following parameters:

Deny SSL renegotiation: NONSECURE (allow both, client and server, to do renegotiation attempts encrypted only (see renegotiation attack). Citrix suggestions of denying renegotiation at all do not make sense to me and SSL-labs does not like it either).

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 demand 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 🙂

About the author

Johannes Norz

Johannes Norz is a Citrix Certified Expert on Networking and a Citrix Technology Advocate.

He frequently works for Citrix international Consulting Services and several education centres round the globe.


Recent Posts

Recent Comments