NetScaler Ciphers and the ROBOT Attack

Here we are again with another Vulnerability related to the SSL/TLS Ecosystem called the ROBOT Attack ( and that usually means the NetScaler is also affected or you need to change some part of your SSL/TLS Configuration.

Besides updating your NetScaler Firmware to one of the latest Builds (see CTX230238 for fixed Builds) you need to remove all Ciphers starting with TLS_RSA from your Cipher List. Below is a Cipher List where all the Ciphers with RSA Encryption are removed to prevent the ROBOT Attack.

You could alternatively also use the Modern Compatibility Cipher List:

Important Note: Only Citrix Receivers for Windows starting with Version 4.7 or higher can connect to your published Desktops/Applications after applying the new Cipher List. This is because ECDHE Cipher Support was first implemented with Receiver 4.7 and we have removed all the other supported Ciphers starting with TLS_RSA_*.

You can see a List of supported Ciphers for the Citrix Receiver starting with Version 4.7 below:

Update #1: I had to learn the hard way that the Citrix iOS Receiver 7.4 can't work with the posted Cipher Lists because the iOS Receiver only supports Ciphers starting with TLS_RSA_*.

Hopefully Citrix will soon release a new Version with additional Cipher Support.

Update #2: The Problem with the Citrix iOS Receiver has been fixed in the 7.5 Version. You can now use the new Cipher List with the latest iOS and Android Receivers.


As always test your updated Configuration with the SSLLabs Test or use the Comodo SSL Analyzer.

Feedback and Comments is as always very welcome.

NetScaler Cipher Lists - 2017 Edition with ChaCha20 Support

Citrix did release a new NetScaler Release/Firmware in December 2017 with Support for a subset of the ChaCha20 Ciphers, so that means I had to update my Cipher Lists. The NetScaler Firmware starting to support ChaCha20 is 12.0-56.20 and this time the ChaCha20 Ciphers are only supported on VPX Appliances. Let's hope that Citrix will add MPX Support and the Rest of the ChaCha20 Ciphers in a subsequent NetScaler Release.

So here are the updated Cipher Groups:

  • Modern Compatibility:
  • Intermediate Compatibility:

Currently the Intermediate Cipher Group is still vulnerable to the ROBOT Attack because of the Ciphers starting with TLS_RSA. I suggest using the Modern Compatibility Cipher Group to remediate against the ROBOT Attack.

OCSP Stapling and NetScaler 11.1+

Starting with NetScaler 11.1 Build 51.21 the NetScaler now supports OCSP Stapling. Yay!

For more in-depth Information about OCSP Stapling and why you should enable it I recommend reading Scott Helme's Blogpost about OCSP.

But let's get started on how to configure the NetScaler to enable OCSP Stapling (the GUI way).


  • NetScaler 11.1  Build 51.21 or later
  • Outbound Firewall Rule to allow the NetScaler Subnet IP (SNIP) to communicate with the External OCSP Responder on Port 80 (HTTP).
  • Existing SSL/TLS Certificate with embedded OCSP Extension (AIA Extension)
  • Working DNS Resolution on NetScaler for "external" URLs


First thing is we need to enable the OCSP Stapling Feature on the SSL Profile in case you are using SSL Profiles or the SSL Default Profiles to configure your SSL/TLS Settings. Otherwise you have to enable the OCSP Stapling Feature in the SSL Parameters for every vServer.

You can find it in the GUI under System -> Profiles -> SSL Profile:

2018-01-10 13_10_56.png

You can choose to create a new SSL Profile (FrontEnd) or edit one of the existing ones, for example the ns_default_ssl_profile_frontend Profile. In my example I'm editing the ns_default_ssl_profile_frontend Profile and enabled the OCSP Stapling checkmark and afterwards saved the Configuration.

2018-01-09 12_47_45.png

Next Step is to create a new OCSP Responder. After upgrading to the latest NetScaler Build you will notice that there are one (or more) OCSP Responders automatically generated with the INTERNAL_ Prefix when checking under Traffic Management -> SSL -> OCSP Responder.

2018-01-09 12_50_17.png

These are generated automatically for every OCSP URI found in the Certificates currently imported into the NetScaler. In my Example I'm using a Certificate from RapidSSL (GeoTrust) which is owned by Symantec and hence the * OCSP URI.

You can check the OCSP URL by looking at your Certificate under the AIA Extension.

2018-01-10 12_19_36.png

You can't edit the auto-created INTERNAL_ OCSP Responders so I opted to "duplicate" the INTERNAL_ OCSP Responders and create new ones where I configured some specific Settings.

2018-01-09 12_50_41.png

I disabled the "Nonce" Checkmark and checked the "Trust Responses" Option.

After saving your new OCSP Responder we need to bind it to the CA Intermediate Certificate (not the SSL/TLS Certificate) which issued your SSL/TLS Certificate. Navigate to Traffic Management -> SSL -> Certificates -> CA Certificates and bind the newly created OCSP Responder to the Intermediate CA Certificate.

2018-01-09 12_51_36.png
2018-01-09 12_51_51.png

Last Step to configure is to bind the SSL Profile with enabled OCSP Stapling to your vServer. Or enable the OCSP Stapling Option under SSL Parameters if you are not using SSL Profiles / SSL Default Profiles.

2018-01-09 12_52_33.png

Check your Configuration

Last Step is to check if OCSP Stapling is working as intended. You can use SSLLabs, Comodo SSL Analyzer or OpenSSL CLI to check it. 

Comodo CA SSL Analyzer:

2018-01-09 12_55_17.png
2018-01-09 12_57_10.png

OpenSSL: (Command: openssl s_client -connect -tlsextdebug -status)


If none of the Test Tools are reporting the successful OCSP Stapling Support make sure to check that the NetScaler can reach the OCSP Responder on Port 80 (via HTTP) through a possible Firewall. The Traffic should originate from the Subnet IP Adress (SNIP) or NetScaler IP (NSIP).

Also make sure that the NetScaler can resolve the OCSP URI and that the DNS Resolution is working. As most (if not all) Public CAs are using a Content Deliver Network (CDN) for their OCSP Responders configuring a OCSP Responder with a IP is not recommended because the IPs on CDNs might change quite often.

From the NetScaler BSD Shell (not the NetScaler CLI) you can run the following Command which could indicate where the Problem lies: nsconmsg -d stats | grep ocsp

The Counter ssl_err_ocsp_http_callout_failed for example could indicate a Problem reaching the OCSP Responder because of Firewall Problems.

Blogpost Changelog:

#1 - 09.01.2017 - Initial Draft
#2 - 13.01.2017 - added Troubleshooting Command for OCSP Counters

NetScaler Cipher Lists - 2016 Edition with ECC/ECDSA

The new NetScaler 11.1 Release (starting with Build 47.14) brings Support for ECC/ECDSA Ciphers, unfortunately only on MPX Appliances with a N3 SSL Accelerator Chip for now.

Next on my Wish List would be ECC/ECDSA Support on VPX/CPX, OCSP Stapling and ChaCha20-Poly1305 Support.

The new updated Cipher Lists are grouped into a Modern and a Intermediate Cipher List Group based on the Recommendations from the Mozilla Wiki. If you want to use the Intermediate Cipher List don't forget to create a 2048bit DH Parameter and bind it to your vServer (or your SSL Profile).

  • Mozilla Modern:
Oldest Supported Clients: Firefox 27, Chrome 30, IE 11 on Windows 7, Edge, Opera 17, Safari 9, Android 5.0, Java 8
TLS Versions: TLS1.2 only

  • Mozilla Intermediate:
Oldest Supported Clients: Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1, Windows XP IE8, Android 2.3, Java 7
TLS Versions: TLS1.0, TLS1.1 TLS1.2

After the Break are the Cipher Lists from my older Blogposts for Reference if you are running an older Version:

Cipher List for MPX/SDX and VPX (starting with Build 11.0-65.31) Appliances:

Legacy Cipher List for MPX/SDX and VPX (starting with Build 11.0-65.31) Appliances:

Cipher List for VPX starting from Build 10.5-57.7 up to 11.0-64.34:

Legacy Cipher List for VPX Builds starting from Build 10.5-57.7 up to 11.0-64.34:

Perfect Forward Secrecy and NetScaler MPX Revisited

My last Blogpost regarding Perfect Forward Secrecy on NetScaler got a lot of Comments and in the meantime Citrix released a new NetScaler Firmware Versions ( which now enables us to use ECDHE Ciphers even on "low end" NetScaler MPX Models like the MPX 5500.

With the new Firmware it's now possible to enable PFS for all modern Clients/Browser and receive an A+ in the SSLLabs Test.

Okay, let's start:

First step is to create a new Cipher Group where we will bind all the new Ciphers we want and need.

Unfortunately changing the Order via the NetScaler GUI is not very user-friendly (Hey Citrix, please enable us to easily change the Cipher Order) so I resorted to the Command Line. Below are the commands to create a new Cipher Group called "THEN-High" and bind the Ciphers in a preferred Order (I'm open for Discussions on the Order and Ciphers if you disagree or got a better Order):

Important: Make sure to order the Ciphers in the preferred order (thanks again to David Chivers for pointing this out) or you may not get Forward Secrecy to work on some Clients/Browser.

Cipher List for MPX/SDX and VPX (starting with Build 11.0-65.31) Appliances:

Legacy Cipher List for MPX/SDX and VPX (starting with Build 11.0-65.31) Appliances (includes Support for WinXP, Java and Android 2.x):

Cipher List for VPX starting with Build 10.5-57.7 up to 11.0-64.34:

Legacy Cipher List for VPX Builds starting with Build 10.5-57.7 up to 11.0-64.34 (includes Support for WinXP, Java and Android 2.x):

Since NetScaler 11 Citrix now seems to enforce compatible Ciphers on the VPX Platform.

All SHA2 and GCM Cipher Suites are not (yet?) supported on the VPX. Since NetScaler Build 11.0-65.31 the VPX now supports all AES-GCM/SHA2 Ciphers. Hooray!

And thats what it looks like in the GUI:

Don't forget to create a Diffie Hellmann Key (2048bit Keysize recommended) and configure it under the SSL Parameters on the vServer (or use the new SSL Profiles Feature). You can find a detailed How-To in my old Blogpost here.

The next Step is to bind the newly created Cipher Group to the vServer. When I did this via the GUI my Cipher Order wasn't honored (Bug? Anyone else?) so again I needed to use the Command Line:

bind ssl vserver <vServerName> -cipherName THEN-High

(Update: With the 10.5-57.7 NetScaler Build this Bug has been fixed by Citrix! You can now use the GUI to bind the Cipher Group.)

Don't forget to bind ECC Curves on the vServer or you won't be able to use the newer ECDHE Ciphers. I recommend binding the Curves P_256, P_384 and P_521.

bind ssl vserver <vServerName> -eccCurveName P_256 P_384 P_521

Let's take a look in the GUI (note the correct Cipher Order):

After configuring everything correctly you should check it using the SSLLabs Test. Here is my Result with the latest Firmware and the described Settings:

(Update: With the 10.5-57.7 NetScaler Build you can now get the A+ Rating in the SSLLabs Test because Citrix added TLS_FALLBACK_SCSV Support)

As always feel free to leave a Comment.


#1 - 19.05.2015 - Cipher Reordering Bug has been fixed by Citrix with the 10.5-57.7 NetScaler Build
#2 - 19.05.2015 - Note regarding TLS_FALLBACK_SCSV Support in the 10.5-57.7 NetScaler Build
#3 - 22.05.2015 - Added specific Cipher List for NetScaler VPX with the 10.5-57.7 NetScaler Build
#4 - 21.06.2015 - Added Note regarding binding ECC Curves.
#5 - 30.06.2015 - Updated MPX/SDX Cipher List with some new Ciphers for broader Client Support.
#6 - 01.07.2015 - Changed VPX Cipher Suite for NetScaler 11 regarding the support of SHA2 and GCM Cipher Suites
#7 - 10.09.2015 - Added MPX/SDX Cipher List without DHE Ciphers (Logjam)
#8 - 02.03.2016 - Added 2 new Ciphers for the VPX Platform Cipher Group
#9 - 04.03.2016 - moved Code to GitHub Gists for Versioning and Change Tracking
#10 - 22.03.2016 - Since NetScaler 11.0-65.31 the VPX now supports all AES-GCM/SHA2 Ciphers. Hooray!