by Thorsten Rood, CTP
Great times to come for security nerds, and even the less enthusiastic ones will really appreciate what is going on with NetScaler firmware evolution in these days!
Over a long period of time, we were living in kind of an upper-and-lower-class society amongst us NetScaler customers. While it was always said and pretended the only major functionality difference between a pure software-centric (NetScaler VPX) and a hardware platform customer (NetScaler MPX, NetScaler SDX) would be a throughput difference based on the available licensing models, hypervisor performance constraints on CPU and network exposure, the real truth behind it was fairly different. Customers that chose to run VPX payloads for their dev and staging areas quickly learned that configuration files moved either from or to their hardware-based NetScaler instances worked a little different when comparing the available and applied security settings. Those under us had chosen to be on an early-adopted pure SDN-play (software defined networking) without any proprietary vendor hardware involved (VPX only and everywhere) or that simply selected VPX-series running on their own existing DMZ-attached hypervisor asset because of budget limits (such as a wider range of SMB customers, especially the Gateway owners) did not suffer the difference in between platforms, but more obviously learned they could be “left behind” and treated as a second class citizen.
What is this damn guy talking about? Seriously, I’m talking about “SSL” as a transport and security mechanism for your Gateway services, Web publishing, VPN, ActiveSync-connectivity or the whole XenMobile family services as not just a pure question of whom to select for buying the annual SSL certificate, it’s about actually managing and configuring SSL functionality on the protocol level itself. Looks like a niche discipline? It doesn’t, at least depending on the customer industry or geo space you’re working with on a daily basis. By chance and also unfortunately there is a very robust, public and widely-trusted auditing service available to get a very handy attestation about your edge services and this is provided by Qualys with their SSL server test routine (https://www.ssllabs.com/ssltest/index.html). Like back in your days at school, earn your grade. Easy to read, hard to fight against and requires a certain expertise to deal with it. Some nice blogs out there showcased how to gain an “A” on hardware (which unfortunately is not the ultimate best result) but whatever you tried, you ended up with a “B” on NetScaler VPX, which has now even been demoted to a “C” level the last week as Qualys treats the world now much differently.
This hassle is now finally over. Within my Synergy sessions on both Gateway and XenMobile I disclosed the upcoming new firmware 10.5.57.x which we had a review on in an early stage and it is now shipping as maintenance release 10.5.57.7.nc for all eligible NetScaler and NetScaler Gateway customers – just go to your Citrix download portal as you typically would and grab the file. With that release, you now can achieve A+, regardless of the underlying hardware platform (VPX running on your own hypervisor, MPX, SDX). And yes, you don’t even have to wait for NetScaler 11 to benefit from this feature!
So please welcome TLS1.2 with TLS_FALLBACK-protection available on all NetScaler products now! Citrix is now committed to delivering the same security baseline with all release vehicles and this is really great news. A huge thank you to all on the NetScaler team who made this a shipping feature and also a paradigm for the future!
(screenshot is taken from our production systems attestation, VPX 10.5.57.7.nc running on XenServer 6.5 SP1)
You’ll notice the scoring is not at 100% for the individual items, but for a fairly simple reason: you don’t wanna break your existing Receivers and browsers that still are living out there in the field, and to remain on A+ you don’t have to be harder on settings as reality requires you to run as a compromise solution.
The main recipe is this:
set ssl vserver yourVServerNameHere -tls1 ENABLED
set ssl vserver yourVServerNameHere -tls11 DISABLED
set ssl vserver yourVServerNameHere -tls12 ENABLED
set ssl vserver yourVServerNameHere -ssl2 DISABLED
set ssl vserver yourVServerNameHere -ssl3 DISABLED
unbind ssl vserver yourVServerNameHere -cipherName ALL
bind ssl vserver yourVServerNameHere -cipherName TLS1-ECDHE-RSA-AES256-SHA
bind ssl vserver yourVServerNameHere -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384
bind ssl vserver yourVServerNameHere -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256
bind ssl vserver yourVServerNameHere -cipherName TLS1-AES-256-CBC-SHA
The TLS1-AES-256-CBC-SHA is needed to support older SOCKS-clients such as Receivers prior to 4.2.100 on Windows and several others outside Windows OSes and the well-loved WorxMail in STA-mode (which is also a SOCKS client). Of course this might change very quickly and become outdated as Citrix moves forward with TLS1.2 support in all products in the course of time.
A small notice: the CGM-ciphers actually don’t work yet on VPX in software (on VPX inside of a SDX with SSL chips assigned for sure) although you can configure them. This is gonna be solved in a future maintenance release, and, as of today, this is not the end of the world.
So now you have something to work on in your existing environments. And for the consultants: rethink your templates!
If you now discover some of your other (public) services don’t earn A+ themselves, think about making NetScaler a reverse proxy with full SSL intercept for those to get the same security baseline across all of your SSL edge services…
Have fun!
Thorsten
