Securing your NetScaler vServer with an A+ Rating

Share Button

When you are publishing your webservers to the internet you have to take special care for the security of your data and that of your users. This can be done on multiple levels but a good starting point is the front door, being your NetScaler (Unified) Gateway or Load balancing virtual servers.

In this article i will explain what you can do to protect your front door en why you should do so.

First lets see what happens when we don’t secure our webservers and allow (unencrypted) HTTP access to our servers whilst requesting user credentials for authentication to a particular resource:


 

As you can see, the username and password is captures in cleartext by a packet sniffer like WireShark. This is a clear example where encryption of user data is a must!

This can be resolved by binding a certificate to your virtual server, for more info see my previous article: Free SSL Certificates with Let’s Encrypt and NetScaler.

Once a certificate has been assigned to your virtual server all traffic will be encrypted. This means that each new connection will go through the next steps before application or authentication data is being exchanged:

1. After the initial “three way” TCP handshake (Syn > Syn, Ack > Ack), the client sends a Client Hello to the server. This client hello contains the highest supported SSL / TLS version of the client and the order of preferred Ciphers by the client.

 

2. Next the Server sends a Server Hello in which it agrees on the highest SSL / TLS version and picks the highest supported Cipher Suite by both Server and Client.

 

3. Next the Server sends a Server Hello Done message and shows the certificate. This is a good way to check if your certificate chain is correct in case you are experiencing issues.

 

4. Now the client will first send a Client Key Exchange message which include the pre-master key, followed by a Change Cipher Spec in which it announces that the next message will be the first Encrypted Handshake Message based on the agreed protocols in the client and server hello messages.

 

5. Finally the Server will do the same by sending a Change Cipher Spec and Encrypted Handshake Message

 

With this final message the TLS Handshake is complete and all future messages will be encrypted.
For more details about the TLS Protocol see: RFC5246

After we have bound the certificate to the virtual server it’s a good time to do a check the current security level. This can be accomplished with the use of SSL Labs which can do extensive testing on protocols, cipher suites and compatibility with the most common web applications.

SSL Labs gave the server a C rating with the default configuration and provides recommendations to improve this rating.


 

As of such let’s start with: This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C.

“The POODLE attack is a man-in-the-middle exploit which takes advantage of Internet and a client’s software security fallback to SSL 3.0. If attackers successfully exploit this vulnerability, on average, they only need to make 256 SSL 3.0 requests to reveal one byte of encrypted messages”

This is resolved by disabling the SSL version 3 protocol and enabling TLS. Now you might be wondering which TLS version you should be using, well it all depends on your environment. Most browsers support TLS 1.2 which is the preferred version, i would even advice to disable all other versions unless you really need them. If you are unsure you can visit SSL Labs from a client in your environment: SSL Labs View my Client

This not only shows the supported TLS versions but also which cipher suites are supported in preferred order for that browser:

 

Note: This is the information from that particular browser, another browser might give different results on the same machine.

To disable SSL v3 and add support for TLS we go to the virtual server on the NetScaler:
Traffic Management > Load Balancing > Virtual Servers

Edit virtual server

 

Edit SSL Parameters

 

Disable SSLv3 and Enable TLS v1.2, if needed also enable support for TLS v1.1 or even TLS v.1.0

 

Next, if we check our security level once more, we should receive an A- rating

 

Now we focus on the next announcement: The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-

Perfect Forward Secrecy is a protocol that prevents data, which has been encrypted by the server private key, can be decrypted once the private key has been compromised. It does so by creating unique session keys that are not being shared between client and server”

You might notice that SSL Labs called it Forward Secrecy where i quoted Perfect Forward Secrecy. The difference is that Perfect Forward Secrecy encrypt each session with a newly generated (ephemeral) key to give it an additional security layer. The implementation is based on the Diffie-Hellman protocol with Elliptic Curves and ephemeral keys, or ECDHE in short.

Now the implementation requires a couple of things:

  • Create a Diffie-Hellman (DH) key
  • Create a Secure Cipher Group where the ECDHE ciphers are at the top of the list (preffered)
  • Bind the DH key and Cipher Group to the virtual server

 

So let’s start by creating the DH key:
Traffic Management > SSL > Create Diffie-Hellman (DH) key

 

Choose a filename, set the DH bit size and select Create

 

Next we are going to created a secure cipher group:

Traffic Management > SSL > Cipher Groups > ADD

 

Give the Cipher Group a name and add the following ciphers in this order:

TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
TLS1.2-ECDHE-RSA-AES-256-SHA384
TLS1.2-ECDHE-RSA-AES-128-SHA256
TLS1-ECDHE-RSA-AES256-SHA
TLS1-ECDHE-RSA-AES128-SHA
TLS1.2-DHE-RSA-AES256-GCM-SHA384
TLS1.2-DHE-RSA-AES128-GCM-SHA256
TLS1.2-DHE-RSA-AES-256-SHA256
TLS1.2-DHE-RSA-AES-128-SHA256
TLS1-DHE-RSA-AES-256-CBC-SHA
TLS1-DHE-RSA-AES-128-CBC-SHA

Note: The order is important for Perfect Forward Secrecy to work, which means ECDHE ciphers first, you can also skip the TLS1 Ciphers if you do not need them (TLS 1.2 only).

 

 

Now that the DH-key and Cipher Group has been created we can bind them to our virtual server:

Traffic Management > Load Balancing > Virtual Servers

Edit virtual server

 

Edit SSL Ciphers, remove the Default group and add SECURE-CIPHER

 

Next go to SSL Parameters, fill out as seen below and select the DH-Key you created earlier

 

Now is a good time to check our security settings again, this time we receive an A rating

 

 

Now that we have implemented all the best practises we get an A rating.

However there is one final step needed to get an A+ rating and that is the implementation of:
HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections and never via the insecure HTTP protocol.”

This implementation can be accomplished by creating a NetScaler rewrite Action:
AppExpert > Rewrite > Rewrite Actions > ADD

 

Next we create a NetScaler rewrite policy and bind the HSTS Action to it:
AppExpert > Rewrite > Rewrite Policy > ADD

 

Finally bind it to your virtual server:
Traffic Management > Load Balancing > Virtual Servers

Edit virtual server


 

Select Policies and select Policy: Rewrite with Type: Response

 

Select the Policy: HSTS_Policy and press BIND

 

Now if you are doing your final test on SSL Labs you will find that you have been awarded with an A+ rating

 

 

 

 

Share Button

Martijn van Willigen

Martijn van Willigen works a Technical Consultant at Detron. With a focus on Citrix NetScaler, XenApp, XenDesktop, XenMobile, ShareFile, Cloudplatform, XenServer, VMware ESX, RES Software and Cisco.

Leave a Reply

Your email address will not be published. Required fields are marked *