Add a GDPR Footer to the NetScaler Login Page

One of the latest requests I got was to add a GDPR Footer to our NetScaler Login Pages. The Requirement was to display a Link to our Imprint and to our Privacy Policy on the bottom of the Login Page to comply(?) with the new GDRP Requirements.

This can also be used to display other Links or Information. You could for example put a Link to your Helpdesk Portal or to a Self Service Password Reset Site on there.

Implementation:

We start by creating a new Rewrite Action. I decided to name mine rw_act_then_insert_gdpr_footer

Next Step is to configure the needed Expression and Settings for the Rewrite Action. Make sure to edit the HTML Code incuded in the Expression with your needed URLs and Descriptions to your Imprint and/or Privacy Policy (in case of our example).

NetScaler Rewrite Action in the NetScaler GUI

  • Name: rw_act_then_insert_gdpr_footer
     
  • Type: INSERT_BEFORE_ALL
     
  • Expression to choose Target Location: HTTP.RES.BODY(120000).SET_TEXT_MODE(IGNORECASE)
     
  • Expression: "var login_footer=$(\"<br><div style='text-align:center;color:white;font-size:15px;'><a target='_blank' style='color:white;text-decoration:underline' href='https://www.example.com/imprint'>Imprint</a>"+"  |  "+"<a target='_blank' style='color:white;text-decoration:underline' href='https://www.example.com/privacy'>Privacy Policy</a><br></div>\").appendTo(logonbox_container);"
     
  • Pattern: box_view.prepare_view()

When done this should look something like this:

Completed Rewrite Action in the NetScaler GUI

Now it's time to configure the Rewrite Policy. According to my Naming Scheme I've choosen to go with rw_pol_then_insert_gdpr_footer

  • Name: rw_pol_then_insert_gdpr_footer
     
  • Action: rw_act_then_insert_gdpr_footer
     
  • Expression: HTTP.REQ.URL.CONTAINS("gateway_login_view.js")

The final Rewrite Policy should look like this:

Last Step is to bind the newly created Footer to the NetScaler Gateway vServer where we want to display the Links. In my case I have a lot of rewrite Policies so make sure you set your GoTo Expression to Next. This is how my Rewrite Policy Bindings on the NetScaler Gateway vServer looks like.

And this is the Result when done correctly

Note:

This Rewrite Policy only works with the Classic, Greenbubble and X1 Theme. The newer RfWebUI Theme is not supported.

Code:

If you don't want to use the GUI you can also use the following NetScaler CLI Commands to create the required Rewrite Policy and Rewrite Action.

add rewrite action rw_act_then_insert_gdpr_footer insert_before_all "HTTP.RES.BODY(120000).SET_TEXT_MODE(IGNORECASE)" q{"var login_footer=$(\"<br><div style='text-align:center;color:white;font-size:15px;'><a target='_blank' style='color:white;text-decoration:underline' href='https://www.example.com/imprint'>Imprint</a>"+"  |  "+"<a target='_blank' style='color:white;text-decoration:underline' href='https://www.example.com/privacy'>Privacy Policy</a><br></div>\").appendTo(logonbox_container);"} -pattern "box_view.prepare_view();"

add rewrite policy rw_pol_then_insert_gdpr_footer "HTTP.REQ.URL.CONTAINS(\"gateway_login_view.js\")" rw_act_then_insert_gdpr_footer

Implementing the Expect-Staple Header on NetScaler

Since my old Blogpost regarding the various HTTP Security Headers got a lot of Traffic I decided to write a new Post because since then there are now two more major HTTP Headers worth considering.

The first one is Expect-Staple and the other one is Expect-CT. As with all the other HTTP Security Headers I recommend reading Scott Helme's Blog explaining all the finer Details of those two Headers (Expect-Stapling and Expect-CT).

But this Blogpost is all about the Expect-Staple Header, so let's get cracking.

Requirements:

Before deploying the Header you should have configured OCSP Stapling on the vServer you are going to bind the new Header to or you will get a lot of Reports to your Reporting URL. And speaking of a Report URL you should have a Service where to send those Reports in case the Expect-Staple Header is being triggered. I can recommend report-uri.com if you need one.

Implementation:

Currently there is no enforce Directive for the Expect-Staple Header so you can't break your Site by accidentally deploying a wrong Header Value like you could do with the HPKP Header. The Expect-Staple Header is basically a Report-Only Header (for now).

  • As with all other Headers we start by creating a new Rewrite Action and a Rewrite Policy. Create the Expect-Staple Action as seen in the Screenshot below:
Name: rw_act_insert_Expect-Staple_header
Type: INSERT_HTTP_HEADER
Header Name: Expect-Staple
Expression: "max-age=0; report-uri=https://example.report-uri.com/r/d/staple/reportOnly; includeSubDomains; preload"
  • Next up is the Expect-Staple Rewrite Policy:
Name: rw_pol_enforce_Expect-Staple_Reporting
Action: rw_act_insert_Expect-Staple_header
Expression: TRUE
  • And as a last Step you need to bind the new Rewrite Policy to your NetScaler Gateway/Content Switching vServer or Load Balancing vServer where you want to deploy the new Header.

You can check the correct Implementation with the securityheaders.io Test. It should look something like this:

Congratulations, another Header deployed! Now you should receive Reports (to your Report URI) whenever something went wrong with the OCSP Stapling when someone visits your vServer. If your OCSP Stapling Implementation (in our case the Stapling Implementation of the NetScaler) proves to be staple you can think about requesting a Certificate with the new OCSP Must-Staple Extension but thats reserved for another Blogpost.

Comments and Feedback is as always welcome. I would be especially interested if you are already using the OCSP Stapling Implementation and your Experiences with it.

NetScaler Ciphers and the ROBOT Attack

Here we are again with another Vulnerability related to the SSL/TLS Ecosystem called the ROBOT Attack (robotattack.org) 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:

https://docs.citrix.com/en-us/receiver/windows/4-7/configure/ica-import-icaclient-template-v2.html

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: 

https://docs.citrix.com/en-us/receiver/ios/7/secure-communications.html

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.

Verification:

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

Requirements

  • 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

Configuration

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 *.symcd.com 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 example.com:443 -tlsextdebug -status)

Troubleshooting:

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