Many IT professionals can discuss basic SSL\TLS encryption and even throw around terms like Heartbleed and POODLE. Theory and real-world action are two different things, though, and I find that many of our Citrix ADC customers rely on out-of-box configurations for some of their own critical SSL configurations. This most notably extends to the selection of SSL cipher suites used for client-to-ADC and ADC-to-server communication.
Proper selection and application of cipher suites is important, not only for security of business applications, but also for availability and the overall user experience. In this blog post, I’ll dive into how to properly select cipher suites and how you can control them with Citrix ADC, ensuring your environment is secure and available.
Anatomy of a Cipher Suite
Let’s quickly look at an SSL cipher suite, using a TLS 1.2 cipher suite as an example.
The most important bits for us are going to be the Key Exchange and Bulk Encryption. These denote how initial SSL encryption keys will be exchanged and how data will subsequently be encrypted during the session. The Signature section is less interesting for our discussion (but can still impact performance).
Key Exchanges
- RSA — One of the oldest key exchange methods, it’s is often used for compatibility with older clients and is being phased out.
- DHE — The Diffie-Hellman Exchange allows two parties to generate a shared secret independently, without fear of an eavesdropper.
- ECDHE — This is the Elliptic Curve version of DHE and has the same properties but uses fewer computational resources.
Importantly, DHE and ECDHE provide forward secrecy, which means that even if an eavesdropper obtained secret key information, they would not be able to break the individual session keys used in data sessions they may have previously been recording. With RSA key exchange, if an eavesdropper broke your SSL certificate key, they could potentially unencrypt all historic and future data transmissions. Ack!
Bulk Encryption
- RC4 — This legacy cipher is used for its simplicity and speed but should not be used due to major vulnerabilities.
- DES — This legacy cipher has a short key length and should not be used.
- 3DES — DES run three times for additional security. This is being phased out and should only be used when absolutely needed for compatibility.
- AES — This is the most common modern data cipher used in SSL.
- ChaCha20 — Modern, secure, fast encryption cipher that is gaining in popularity.
Luckily TLS 1.3 standards are a little simpler because they only support ephemeral Diffie-Hellman and only need to list the bulk data encryption cipher and MAC algorithm. An example TLS 1.3 Cipher is TLS_AES_256_GCM_SHA384.
Now that we understand the basics, let’s look at how the cipher suite for an SSL connection is determined.
SSL Handshake Process
During the initial SSL handshake, the client sends a list of ciphers to the server, in order of preference. This is called the clientHello and can be seen easily in a Wireshark trace if you open the first SSL packet sent from client → server and look at the cipher suites section:
In the screenshot above, the client prefers TLS 1.3 cipher suites, then requests TLS 1.2 ECDHE ciphers if TLS 1.3 is not possible.
The most important thing to note, though, is that the SSL server is responsible for deciding which cipher suite is used. This means that clients connecting to Citrix ADC are at the mercy of the machine! This makes it incredibly important to set your ADC cipher suites correctly. If you don’t, you risk putting critical business information in danger.
Citrix ADC and Cipher Suites/Groups
So how do we use this information to ensure our Citrix ADC connections are secure? First, we need to remember the fact that Citrix ADC often operates as both a client and a server for different connection streams. In ADC-speak, this maps to BackEnd and FrontEnd SSL connection-types, respectively.
The preferred way of configuring consistent settings across your ADC is to use SSL Profiles under System > Profile > SSL Profile tabs.
You can add FrontEnd and BackEnd SSL Profiles that your vServers and SNIP can use to provide connections, and connect, to client/services.
From here you can add SSL cipher groups to the SSL Profile on the right hand-side under Advanced Settings.
This is where you should be setting your most secure cipher group to be used as the default for any new vServers created on your ADC. It is important to note that cipher suites listed higher in the list are most preferred. This means that if the client supports the first cipher suite in the list, Citrix ADC will select that.
Let’s look at the default ADC cipher group.
This actually places some TLS 1.0 ciphers at the top of the list, which means they are most preferred if a client supports them. D’oh! That’s why it’s important to review and create your own Profiles/Groups.
Putting it Together
But what does it all mean, Basil? What actually should go in my cipher groups? Let’s break down how this affects your decision making in the real world.
This means that we should always place things like TLS 1.3 cipher suites, or TLS 1.2 cipher suites that use ECDHE exchange, higher.
Sounds simple right? While there are nuances and exceptions to consider, it is a good starting place and ensures security is priority No. 1. Here are some other relevant do’s and don’ts:
Cipher Suite Do’s
- If in doubt, follow the Golden Rule.
- Create custom default cipher groups for FrontEnd and BackEnd connection-types. The default cipher group used by Citrix ADC should not be used without review.
- Create additional custom cipher groups for any service requiring more relaxed or strict security.
- If you’re still not sure what is secure and what isn’t, you can review the latest Windows 10 preferences lists to see what Microsoft thinks is secure.
Cipher Suite Don’ts
- Don’t use SSL3\TLS1\TLS1.1 cipher suites (if at all possible).
- Don’t place insecure cipher suites at the bottom of your default cipher groups for niche scenarios. Use custom cipher groups to include these and only apply them when necessary.
- When placing insecure cipher suites in your Groups, ensure they are at the bottom.
- Don’t use vulnerable bulk encryption ciphers like RC4, DES, or 3DES if at all possible.
Compatibility and Performance
There are only two reasons why you should deviate from the Golden Rule of “always place more secure cipher suites higher in the preference list”: compatibility and performance.
Compatibility
There are situations, mostly with FrontEnd-type connections where your Citrix ADC might be servicing clients with an older OS or applications that require outdated TLS versions or cipher suites. In these cases, it is important to review the business justifications and work with your security teams to determine risk and next steps (yes, I’m a consultant). It is important that all stakeholders understand the risks with insecure cipher suites so you make an informed decision. Do not make this choice in a vacuum and put yourself or your business at risk!
Compatibility is not as big a concern for back-end connections due to the amount of control businesses normally have over server → server communication. There is hardly any reasons to relax on security when server configurations can easily be modified and technology like Citrix ADC connection sharing is used.
Performance
The other major consideration when choosing cipher suites is performance. You definitely don’t want denial of service to the very thing you sought to protect!
Key sizes can play a large role in this. Yes, larger encryption key sizes are more secure, but many are ‘secure enough’ while providing faster performance than their larger key brethren. For example, an RSA key size of 2048 is considered secure but is smaller than 3072 and 4096 key sizes. The two larger key sizes provide additional security that is not needed with today’s (or the near future’s) compute power but will cause additional computation power to be used during SSL connection establishment.
The type of key exchange is also very important. Moving from RSA to ECDHE is great, right? You get perfect forward secrecy and you can reduce the key size overall due to the properties of Elliptic Curve!
While this is true, moving to DHE or ECDHE key exchanges can greatly decrease the overall requests per second that a system like Citrix ADC supports. This is doubly true for older hardware that does not have hardware-assisted Elliptic Curve capabilities like our MPX/SDX 5900/8900/26000 platforms with their Intel Coleto Creek chipsets.
In these cases, you need to be very conscious of your preferred cipher suites (especially front-end) or you might find yourself in a situation where user experience is significantly affected by overloaded ADC compute resources. If you are already pushing the limits of your older hardware, you may want to consider upgrading.
Wrapping Up
Cipher suites and groups are really important when managing an ADC! While the Golden Rule is simple, there are many pieces of data to take into consideration. Working with your management and security to understand requirements and make joint decisions is crucial to protecting your business. As always, if you’re looking for assistance implementing any of the ideas in this blog, I recommend contacting our Citrix Consulting team.
