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:

NetScaler and additional HTTP Security Headers

After bringing the SSL/TLS Cipher Suites Setup up to date on our NetScalers it's now time to take a closer look at a few of those HTTP Security Headers (X-Xss-Protection, X-Frame-Options and X-Content-Type-Options) and how to implement them on the NetScaler ADC. For an in depth Explanation what those different Headers really do I will refer you to the excellent Blog from Scott Helme who can explain those Things a lot better than me.

So if you are fronting your Webservers with a NetScaler or you want to enhance the Security of your NetScaler Gateway (formerly also known as Citrix Access Gateway) you might want to implement those HTTP Headers on the NetScaler itself and not directly on your Webservers.

The following Guide and Screenshots were written/taken while using the NetScaler 11.0-63.16.nc Firmware and using the GUI. If you prefer the CLI, all of the needed Commands for adding the 3 Rewrite Rules can be found at the end of the Blogpost.

Enough talk, lets begin:

• We will create a new Rewrite Action for inserting the X-Frame-Options Header in the GUI under AppExpert -> Rewrite -> Actions -> Add.

Next we will choose a Name for the new Rewrite Action and then select "INSERT_HTTP_HEADER" as the Type. Under Header Name we need to put X-Frame-Options and under Expression we will put "SAMEORIGIN" or "DENY" (depending on your Use Case).

In the next Step we need to create the Rewrite Policy itself in the GUI under AppExpert -> Rewrite -> Policies -> Add. Name the Policy accordingly and under Action select the Rewrite Action we created a Step earlier. As Expression you can use TRUE which will force the NetScaler to always insert the HTTP Header as long as the Policy is being hit/used.

Next Step is to bind the newly created Rewrite Policy to the vServer (or NetScaler Gateway) of your choice. In my example I'm binding it to one of our NetScaler Gateways as a new Response Policy.

Important: If you already have existing Rewrite Policies bound to your vServer and you want them all applied make sure only the last Rewrite Policy (with the highest Priority Number) is using END as the Goto Expression or NetScaler will stop applying your Policies as soon as he hits the first Rewrite Policy with an END Goto Expression.

Reminder: NetScaler is going through those Policies from the lowest to the highest Priority Number and depending on the GoTo Expression after starting with the lowest Policy will either continue (Goto Expression: NEXT) with the next higher Policy or just stop going through all of the remaining Policies (Goto Expression: END).

Now it's time to check if we did everything correctly and if all our existing and new Rewrite Policies are still being applied. If your Website (where we bound the new Rewrite Policy) is publicly available you can use the securityheaders.io Site to check if the new HTTP Header is present (note the green X-Frame-Options Badge in the Screenshot). Otherwise you would need to use the "Developer Tools" of your Browser to check if the HTTP Response Headers are being added.

Now we need to repeat the whole Process for the other 2 HTTP Headers (X-Xss-Protection and X-Content-Type-Options). First we create a new Rewrite Action with the X-Xss-Protection Header Name and the Expression Value set to "1; mode=block"

And a new Rewrite Policy for the corresponding Rewrite Action. Again using TRUE as Policy Expression.

And again bind the newly created Policy. Again, pay attention to your Priority and Goto Expression.

And after binding the Policy and saving the running Config make sure the new Policy is working. We should now also see a green Badge with a Checkmark next to the X-Xss-Protection Header in the Test.

And now onto the last HTTP Security Header X-Content-Type-Options. Again create a new Rewrite Action with the Header Name Value of X-Content-Type-Options and the Expression Value set to "nosniff".

And a new Rewrite Policy with TRUE as Expression Value

As always bind your new Rewrite Policy to your vServer. After binding all 3 new Policies to the vServer it looked like this:

Your 3 new Rewrite Actions and their corresponding Rewrite Policies should now all be listed in the GUI.

And again testing with all 3 new Policies bound it should look something like this in the securityheaders.io Test. Implementing Content Security Policy (CSP) on NetScaler is reserved for another Blogpost in the future.

And here are the CLI Commands for creating the 3 Rewrite Actions and Policies if you really hate the GUI or simply enjoy the CLI:

add rewrite action rw_act_insert_XFrame_header insert_http_header X-Frame-Options "\"SAMEORIGIN\""
add rewrite action rw_act_insert_XSS_header insert_http_header X-Xss-Protection "\"1; mode=block\""
add rewrite action rw_act_insert_XContent_header insert_http_header X-Content-Type-Options "\"nosniff\""
add rewrite policy rw_pol_enforce_XFrame TRUE rw_act_insert_XFrame_header
add rewrite policy rw_pol_enforce_XSS TRUE rw_act_insert_XSS_header
add rewrite policy rw_pol_enforce_XContent TRUE rw_act_insert_XContent_header

Thanks again to Scott Helme for writing the great securityheaders.io Site and for providing a lot of Background on those Headers in his Blogposts.

Feel free to leave a Comment with Feedback or Questions, thanks!

Public Key Pinning (HPKP) with NetScaler

I recently decided to implement HTTP Public Key Pinning (HPKP) for some of our external facing Services and our NetScaler Gateway/Access Gateway.

Before we go on I recommend reading through the Wikipedia Article and this Blogpost from Tim Taubert to get a basic understanding of how HPKP works. Tim can also explain it a lot better than I can.

In this Guide I'm assuming you already have some kind of Load balancing vServer or NetScaler Gateway set up and running (including an existing SSL Certificate). So let's start:

In my Example I choose to pin the used Certificate itself and the Intermediate Certificate from RapidSSL where the Certificate itself was issued from. Please make sure you know the consequences when choosing the Certificate Hashes you are going to pin.

First off we need to generate the SHA256 Hashes for the Certificates we want to "pin". I choose to do it via the OpenSSL Interface in the NetScaler GUI but you could also choose to do the same via the NetScaler Shell CLI.

Just copy and paste the following Command into the Command Window and let OpenSSL do its magic. Copy or write down the created Hash as we will need it later on.

x509 -in /nsconfig/ssl/name-of-your-servercertificate.cer -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

Rinse and repeat for the second Certificate (the Backup Hash) you want to pin. In my case this is the issuing Intermediate Certificate from RapidSSL.

x509 -in /nsconfig/ssl/name-of-your-intermediate.cer -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

Next up we need to create the Rewrite Action and the Rewrite Policy to insert the needed HPKP HTTP Header into the HTTP Responses for our vServers and/or NetScaler Gateways.

First lets create a Rewrite Action. I named mine "insert_HPKP_header":

Name: insert_HPKP_header
Type: INSERT_HTTP_HEADER
Header Name: Public-Key-Pins

Expression: "pin-sha256=\"yourcerthashgoeshere\"; pin-sha256=\"yourbackuphashgoeshere\"; max-age=60; includeSubDomains"

Important: For the max-age I recommend starting with a low Value like 60 seconds during the Implementation Phase because if you somehow fuck up your Hashes you are only locked out for 60 Seconds. After successfully testing your HPKP Headers you should then ramp it up to something like 5184000 seconds.

Next Step is to create the needed Rewrite Policy itself. Mine is called enforce_HPKP and is just using TRUE as Expression.

Now its time to bind the newly created Rewrite Policy onto the vServer and/or the NetScaler Gateway Server. If you have multiple Rewrite Actions with different Priorities bound to the vServer (like in my case) make sure to set the "Goto Expression" Option to NEXT or otherwise only the first Rewrite Action will be applied. 

Last but not least you should check if the Public-Key-Pins Header is added successfully to your HTTP Responses. An easy Way is using the SSLLabs.com Scanner and check the Public Key Pinning Test. If everything is working you can now ramp up the max-age Value to 5184000.

If you don't like the NetScaler GUI you can also use the following CLI Commands to implement it:

add rewrite action insert_HPKP_header insert_http_header Public-Key-Pins q{"pin-sha256=\"yourcerthashgoeshere\"; pin-sha256=\"yourbackuphashgoeshere\"; max-age=60; includeSubDomains"} 
add rewrite policy enforce_HPKP TRUE insert_HPKP_header
bind vpn vserver nameofyourvserver -policy enforce_HPKP -priority 100 -gotoPriorityExpression END -type RESPONSE

Update: Implement HPKP Reporting

HPKP includes a Reporting Functionality for the Clients (Browsers) to send a Report in case of an Error. There is a great and free Service called report-uri.io from Scott Helme you can use to avoid having to set up your own Report Server.

After registering at report-uri.io you are given a unique Report URL you have to add to the HTTP HPKP Header as an additional Parameter. In this Example we would use the Public-Key-Pins-Report-Only Header (instead of the Public-Key-Pins Header) without enforcing HPKP itself. This would be a good first Step to see if your calculated Certificate Hashes in the Header are correct without blocking your Site in case of a wrong Hash.

Name: insert_HPKP_header_reportonly
Type: INSERT_HTTP_HEADER
Header Name: Public-Key-Pins-Report-Only

Expression: "pin-sha256=\"yourcerthashgoeshere\"; pin-sha256=\"yourbackuphashgoeshere\"; max-age=60; includeSubDomains; report-uri=\"https://report-uri.io/report/667d4f42bdc27b357863fefdd41574a4\""

The CLI Command for creating the would be

add rewrite action insert_HPKP_header_reportonly insert_http_header Public-Key-Pins-Report-Only q{"pin-sha256=\"yourcerthashgoeshere\"; pin-sha256=\"yourbackuphashgoeshere\"; max-age=2592000; includeSubDomains; report-uri=\"https://report-uri.io/report/667d4f42bdc27b357863fefdd41574a4\""}
add rewrite policy enable_HPKP_Reporting TRUE insert_HPKP_header_reportonly
bind vpn vserver nameofyourvserver -policy enable_HPKP_Reporting -priority 100 -gotoPriorityExpression END -type RESPONSE 

 As always Feedback and Comments are greatly appreciated.

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 (10.5-53.9.nc) 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.

Changelog:

#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!

NetScaler Gateway: Internal Server Error 43531

After upgrading a HA Pair of NetScalers from 10.1 to the latest 10.5 Build (10.5-52.11 to be exact) I stumbled upon a critical Error when trying to access the Receiver for Web Site.

After authenticating successfully I would be presented with an Http/1.1 Internal Server Error 43531

After some Troubleshooting I could narrow it down to a specific Setting in my Session Policies for the NetScaler Gateway. If you used my previous Blogpost on how to configure the NetScaler Gateway for Storefront Remote Access you might also run into the same Problem.

The following Setting was working with the NetScaler 10.1 Builds:

After upgrading to the 10.5 NetScaler Build you need to edit your "Receiver for Web" Session Policy and move the Storefront URL from the "Home Page" Field under Client Experience to the "Web Interface Address" Field under Published Applications. You also need to enable "ICA Proxy" and set it to ON. Below are two Screenshots with the corrected Session Policy Settings:

I'm not sure if this is intended or just a Bug in the Code. Feel free to let me know in the Comments if you encountered the same Problem when upgrading from 10.1 to 10.5.