latest update: May 5^th 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.

AES or CHACHA?

Currently (May 2021), 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. From the perspective of Citrix ADC appliances, AES is perfectly supported with all more or less current hardware versions.

CHACHA is based on Salsa20, invented by Bernstein in 2006. It’s a European development. Because of this, CHACHA is not available on FIPS appliances.
Bernstein had been motivated by American attempts to limit the global availability of encryption. Very soon it turned out to be less CPU intensive on most CPUs (also true for x86 CPUs). The more economical use of the CPU has made CHACHA the encryption method that Google chose as the successor to RC4.

Same as AES, CHACHA is currently considered to be secure. A downside of CHACHA is limited availability on the client-side. Because of this, we can’t go with CHACHA alone. To make things worse, CHACHA is not supported on all MPX/SDX versions with all kind of firmware. It requires firmware release 13 or above (see here).

To make things even worse, 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 or clientless access.

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 possible, but what’s the point of doing so? Just because we can? We are children no more!

Please, don’t misunderstand! Security always has to make sense. If you are in need to use 256 Bit for technical or political reasons (even if it’s just, because one of the necktie men says), you have to do it. But if you don’t feel pressure, consider going with 128 Bit. But if you run your Citrix ADC (NetScaler) a VPX and feel, CPU is a concern, try to be able to go with 128 Bit, sometimes a real admin has to be strong and fight.

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, however, I have written about TLS 1.3 as well.

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

It’s not all about cyphers, it’s also about the order of cyphers. The more up they are, the more likely they get used by a client. They get bound to the cypher-group, just like policies get bound, and similar to policies, they have binding priorities.

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)

Keep 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 the 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:

TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
TLS1-DHE-RSA-AES-256-CBC-SHA
TLS1-DHE-RSA-AES-128-CBC-SHA

As 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 only 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 (being a consultant is like being one of these girls in dark streets: We do, what customers want us to do, as long as customers pay enough).

I never use SSL- settings anymore, instead, I am always using SSL profiles. This leads to consistent, streamlined, environments. With SSL version 1.2 and below, you may mix profiles and a more conventional approach (I would consider this to be a bad style), with TLS 1.3 it’s an either-or. Go with profiles!

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 to and if you’re using Google’s Chrome browser, Google knows everything).

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”. And “because I can”. I have both, knowledge and CPU power to encrypt, so I encrypt.

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 horribly unreasonable demand and shop somewhere else. PCI-DSS would not even consider, allowing you to cash their customer’s credit cards. But websites like this one here? I would not spend extra money on better CPUs to be “more secure”. Security needs to have a purpose, it must not be an end in itself.

 

---

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.

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)

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 🙂