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 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 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.
Unfortunately, Citrix WorkspaceApp currently (12/20) does not support ChaCha cyphers.
A downside of CHACHA is limited availability on client-side. Because of this, we can’t go with CHACHA alone.
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:
- 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
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)
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)
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)
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 🙂