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 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.
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 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.
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)
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)
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)
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 🙂