I started getting a bit confused about security of SSL during the last some month. First of all there was Mr. Edward Snowden. He told us about continuous massive attacks against SSL going on. NSA seems to be able to continuously trace our sessions. Next issue was Heartbleed (CVE-2014-0160). SSL renegotiation seemed to be a big issue. The last one is just a POODLE (CVE 2014-3566) (but never underestimate a really big Poodle)

Can we still trust SSL?

To be honest, I don’t know.

SSL/TLS is a pretty easy and flexible protocol suit. It works fine for near to all environments. What’s wrong about SSL? Well, it’s pretty flexible. Think of SSL version 1. There are even protocol suites like unencrypted! Security? forget about it! This is mainly the reason why SSL never made it to a RFC. Instead the IETF created their own standard, called TLS (RFC 2712). “This document and the TLS protocol itself are based on the SSL 3.0 Protocol Specification as published by Netscape. The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough …” (RFC 5246).

So can we trust SSL/TLS? I don’t know, but what else could I trust?

There are some things I’d like to avoid.

Heartbleed

Netscaler had never been vulnerable to Heartbleed. So that’s done!

√

POODLE

NetScaler is  – like any  appliance supporting SSL V3 – vulnerable. But why do we need to support SSL V3? All major browsers announced to discontinue support for SSL V3 soon. Let’s be the first one to do it. That’s also what Citrix suggests to do. But really turn it off. Don’t let you fool about “Mitigating Factors”. Things that make an attack more complicated don’t make it less likely. They just make it a more expensive. That’s all (Hacking is all about money). If you want to do it using the command line follow the guidelines by Citrix. If you want to do it using the GUI follow mine …

So select the SSL Server, click SSL Settings, click SSL Parameters and deselect SSL V3. That’s all!
√

SSL renegotiation

Netscaler supports all types SSL renegotiation. Unfortunately it tends to use the worst. Not a good habit, but we can break this habit easily …

GUI

Locate SSL on the left side. Select advanced ssl settings

In CTX 123680 they advice us to change to all. At least we need to change to NONSECURE, better FRONTEND_CLIENT, but all would be best.

Commandline interface

It’s pretty easy and fast to do using command-line interface:

set ssl parameter denySSLReneg ALL

parameters would be: ALL, FRONTEND_CLIENTSERVER, NONSECURE, FRONTEND_CLIENT, NO. No is default and should get changed.
Problem existed but is now solved √

So, let’s give it a try!

we connect to a SSL test site. I use Quality’s SSL test.

B sounds not too bad, and in fact, it is not. There are several reasons to stay with B. But why not A? Because of protocol support. Let’s dig a bit deeper.

Why are protocol suites an issue?

Next Problem: Cypher suites

Did you ever see a NetScaler using 256 Bit AES encryption with ICA? Oh. But why? No AES encryption on a NetScaler? No 256 Bit encryption?

Of course a NetScaler may do 256 Bit encryption. But it simply does not. All RFCs say a server should select the best possible method. A NetScaler refuses to do so. Why? Because the predefinitions are like that. Predefinitions, where? What?

here we are. We select the Default group and look into it: It’s a shame! Why? To safe CPU. It’s that simple: in security there is always a gap between usability, costs and security. The more secure, the more costs, the less usable. Citrix saves resources and at the same time guarantees to allow all devices to connect.

So what can we do?

The best answer a consultant can give is always: “It depends“. Period. The best question a costumer can ask is “on what?” That’s the point where a consultant runs into troubles and starts hating his costumer. Let’s give it a try.

There are so many devices out there. Current devices, supporting TLS v1.2, and outdated ones supporting SSL v2 only. It mainly depends on devices you want to support, and resources you can provide. Ah! Nearly forgot to mention: on the NetScaler model you use! NetScaler Model? Yes, sir.

Understanding Cyphers

Typically a cypher group’s name would be like this:

SSL3-RC4-MD5

What does it mean?

So, this one, for example, uses SSL version 3 (it also exists in TLS standard). It won’t be compatible to SSL v2. The communication will be done using 128 Bit RC4 encryption, Message Authentication Code will be MD5. In addition the key itself is exchanged using RSA encryption.

Message Authentication Code (often referred as MAC) ensures that the data has not been modified during transmission. It sounds like a simple check sum method, but if you spend some time thinking about security you’ll find out it is an important piece in the puzzle.

Key exchange?

The most challenging thing in symmetric encryption is finding key that both, sender and receiver, can have in common. There are many different ways to do so. The easiest way will be to use pre-shared keys. However pre-shared keys is no option here, as client and server won’t know each other in most cases. Pre-shared keys are static and an attacker will find plenty of time to guess the key, so you must not consider them to be safe after some time.

The simplest method would be to to find a key, encrypt it with the server’s public key, and send it to the server. Only the owner of the public key is able to decrypt the secret. It’s a rather simple method, widely used in SSL and TLS. It’s called RSA.

An other methode would be Diffie–Hellman key exchange. It is based on random numbers used by client and server. To make it short: server and client exchange packets including their encrypted random numbers. There will be less packets (equal to equations in mathematics) than secrets, so an attacker won’t be able to do the maths, but as both sides know their own random numbers they both will be able to “guess” the hole secret. Diffie-Hellman is used with HDX (ICA) encryption. And it might also get used in SSL, however it is costly (many packets, much waste of CPU).

A complete list of methods supported by NetScaler can be found at edocs.citrix.com

Which method is the best?

• pre-shared keys are no option for SSL, so no option for our NetScaler too.
• RSA is simple and fast, and highly secure. As long as the secret key is not stolen. You must be aware of this: I would be able to trace your entire conversation in real time if I can steal your secret key. WireShark for example (and we using it) benefits from this (see ctx116557). We all know there are many – rather skill-full – people out there trying to hack our systems. So we can’t guarantee the integrity of our secret keys. This is a strong draw back. On the other hand, RSA it is fast and simple.
• Diffie-Hellman is a huge burden for a system handling many SSL connections. On the other side it is a big challenge for an attacker, no matter if it’s a governmental or a criminal one (if there is any difference). Owning the private key would simple be not enough. The only possible attack for an unauthorized owner of a secret key would be to fake all of the server or to create a proxy server (man in the middle). This would be a big effort for people tracing a big share of internet traffic. That’s why most experts suggest to go with Diffie-Hellman.

So I would tend to go with Diffie-Hellman too. But.

But NetScaler VPX don’t support Diffie-Hellman! I could not believe it at first, but this is true. It’s only supported on NetScalers containing hardware acceleration cards (MPX, SDX).

Suggestions

The default algorithm is not sufficient. In most cases NetScaler will tend to use low security SSL v3 methods. Things get better if you change to TLS v3 only. This would allow near to all current devices to connect, however some elder devices won’t be able to do so. The TLS v3 only selection, however, also contains many 128 Bit methods. 128 Bit encryption is not any longer strong enough for a really secure environment.

Avoid using anonymous DHE (ADHE).

If you own a hardware NetScaler I’d strongly suggest to create your own collection containing just methods starting with ECDHE, DHE or EDH (all using Diffie-Hellman). You could also remove all 128 Bit encryption methods, however this will prevent Java based devices as well as devices using old versions of Internetexplorer from connecting.

My favourite methods are:

TLS1-ECDHE-RSA-AES256-SHA
TLS1-DHE-RSA-AES-256-CBC-SHA

On VPX:
TLS_RSA_WITH_AES_256_CBC_SHA

NetScaler VPX does not support TLS v1.1 and above. That’s why the rating of a well secured website will look like that

most devices would be supported using TLS_RSA_WITH_AES_256_CBC_SHA. This brought Cipher Strength to 100%.

How bad is this B- rating?

It depends. I am not afraid of governmental hackers. This server won’t be of interest to them. It does not contain valluable content like Twitter, Facebook or Google servers do. I use strong ciphers, and this is good for the privacy.

There is something I can do to keep the private key safe: I could use a really strong password for the key- file. And I do. Citrix supports rather long passwords containing random numbers, so use strong passwords. This will help to mitigate the risk of stolen private keys.

I would suggest to change to a MPX box if you can’t go with this rating

what else?

I would strongly appreciate comments on and reflections to my article. I might easily have made mistakes or technical changes may have made my blog obsolete. Thanks! Special thanks to Hendrik Klinge: He pointed out a bad mistake!