NetScaler SSL Offloading for XenMobile MDM… Finally!

Well over a month ago Citrix released the XenMobile Device Manager SSL Offload Server Patch for NetScaler. And although this has been something we’ve been waiting for, although ‘we’ is probably still a relatively small group, for some reason I haven’t read or heard a thing about it. Perhaps XenMobile isn’t as popular as I thought or people just don’t mind putting their MDM machines in their DMZ’s, I know I would. Whichever the case may be, from now on you can securely place your MDM machine on your internal network without having to worry about potential unsecure connections, SSL only! Although I do highlight the XenMobile MDM server patch, the below is applicable to other sorts of (web) services as well.

The NetScaler and me

During the past few months I covered a large part of the Citrix portfolio, I discussed XenApp, XenDesktop, XenMobile, StoreFront, Provisioning Services and a few more, including several Microsoft related technologies as well. A subject left out of scope is Citrix’s NetScaler, here’s why. I’ve never really been a networking kind of guy, don’t know why to be honest. Sure, I know my VLANs, subnets, tagging etc… but I never really dealt with any (advanced) network device configurations apart from some simple switches and wireless routers. Now it’s not that I’m completely unfamiliar with the NetScaler portfolio, I mean, I know what it’s capable of technically, most of it anyway, I can also highlight some of the differences between physical vs virtual, licensing structures, scale up and out models and I can probably think of at least a dozen use cases on when and why to implement as well, but that’s where it ends. Although that may sound like a lot to some, it isn’t, not really.

SSL Offloading you say?

I decided It’s time for change and since I’m also working on XenMobile at the moment I thought the two would make a good combination. Let’s start by looking at the SSL Offloading feature in general, how does it work and what are some of the benefits. Simply put, SSL (Secure Socket Layer) provides an encryption / authentication (Handshake) mechanism between a client and server system. SSL encryption is based on SSL certificates which can be bought from a trusted Certificate Authority, or CA in short, and without Offloading applied need to be installed on the web server hosting the service. Have a look at this Wikipedia page with regards to CA’s if you’re not familiar with the concept. Note that although their (SSL certificates) primary use is to secure web servers, they can also be used to secure email servers, file transfers, and other data connections.

Delegating tasks

By default, the web server, there can be multiple of course, hosting the certificate handles all decryption and encryption of SSL traffic, potentially burdening the server with extra load. This could, when traffic is heavy, impact performance since decrypting and encrypting network traffic can be a CPU-intensive task, particularly during session initiation a.k.a. the Handshake which also includes the server to client authentication, and vice versa, see the ‘Let’s shake hands’ section below. By implementing SSL Offloading you basically delegate these tasks, of handshaking, decrypting and or encrypting traffic to a third party device, automatically freeing the web server from (extra) load. Note that SSL certificates can also be self generated, on the Citrix NetScaler appliance for example, however, Citrix recommends to buy one from a trusted CA of choice. Use self signed / generated certificates for testing purposes only.

The Offload server patch and its advantages

When the XenMobile Device Manager SSL Offload Server Patch for NetScaler is installed and configured accordingly (certificate needs to be known by the NetScaler as well) NetScaler will handle all decryption, encryption and authentication from then on, freeing your MDM server(s) from certain tasks (the Handshake in particular) enhancing performance. Another advantage, and probably the main one, is that the device responsible for Offloading all SSL traffic, the Citrix NetScaler in our case, can live within our DMZ, the way we like it, and the web server(s) for which SSL traffic is being offloaded can be safely placed on your (more secure) internal network without having to worry about unsafe connections since they’re all being checked, inspected, decrypted and possible encrypted by the NetScaler before finally ending up on the web server.

No more DMZ

This, as off version 8.6.1, is now also true for Citrix XenMobile MDM as well, before Citrix XenMobile version 8.6.1 the MDM server needed to be placed in the DMZ since it had to authenticate, decrypt and encrypt all SSL traffic itself. So next to potential more intensive resource use, this also meant insecure placement. This was basically the only way you could implement it because placing it on your internal network would mean that uninspected and unauthenticated traffic would be able to enter, leaving you with no other options. Below, the way it was before 8.6.1 Due note that I don’t mention any Cluster / HA or +1 scenario’s throughout the article since this is a whole other subject on itself.

A bit more specific

SSL Offloading, as a term, is still a bit generic, lets talk about some of the options we have at our disposal. There are basically two ways (and to all network pro’s out there, correct me if I’m wrong) when it comes to Offloading SSL traffic: SSL Termination and SSL Bridging, at least these are the two most common ones. When terminating SSL traffic all relevant data gets decrypted, inspected and send to the web server. Note that with termination the data send from the NetScaler (DMZ) to the web server (internal network) is unencrypted. Although your internal network might be seen as secure and trusted by most, using SSL Termination can be flagged, as a security risk. I guess this will differ per company. The big advantage is that the data is already decrypted and inspected in the DMZ before reaching the web server, again, freeing up resources and more secure.

When using NetScaler

The above applies to ‘general’ networking and as such is applicable to different kinds of  appliances and web servers. When SSL Termination gets applied on a NetScaler you have two options, one, like above: traffic gets decrypted and send to the web server unencrypted and two: traffic gets decrypted, inspected and re-encrypted before it’s sent to the web server. This is also referred to as end-to-end Termination and is recommended by Citrix. (see the comments section below, thanks Anton!).

Bridging

SSL Bridging is similar to Termination, as described above, with one additional step added. The SSL encrypted data enters the offload appliance, next the sessions get’s authenticated and the data decrypted, inspected etc… till finally it gets encrypted again and send through to the web server on your internal network. Although this is the more secure way of handling things it could potentially slow down operations when traffic is heavy since the web server still needs to decrypt / encrypt the data. Never the less, it’s the recommended way of implementing SSL Offloading if at all possible. With NetScaler, and thus MDM, things work a bit different.

When using NetScaler

Just like before, the above applies to ‘general’ networking and therefore applies to all other appliances, services and web servers. NetScalers works with so called virtual servers, which also applies when setting up, but is not limited to, SSL Bridging. When configuring a NetScaler SSL Bridge (virtual server) data remains encrypted, isn’t inspected and is directly send through to the web server without any pre-authentication or whatsoever, no certificates needed. Try to avoid this setup whenever possible. Also see:

http://blogs.citrix.com/2013/03/12/fronting-xenmobile-mdm-with-netscaler/

Other considerations

As mentioned with MDM, till now, Offloading wasn’t an option at all and all data needed to be decrypted and encrypted on the web server anyway, and although with implementing SSL end-to-end Termination on a NetScaler, this hasn’t changed, at least now the MDM server can reside on your internal network instead of your DMZ. When traffic increases you could always consider to implement ‘normal’ Termination, add more web servers or offload your web server in another way, perhaps SSL acceleration might do the trick, will be discussed shortly. The amount of data that needs to be processed influences the type of offloading you implement. Of course your internal network needs to be seen as secure and treated as such with regards to NetScaler SSL Termination. With either termination or bridging in place the architecture will look something like this:

SSL Acceleration

As mentioned, SSL cryptography can be a very CPU intensive task. Because of this, over the years, engineers have been developing several techniques trying to relieve the web server from this task improving overall performance, with Terminating and Bridging probably being the best known. Asymmetric cryptography in particular (public key), which is used during the SSL Handshake to initiate the secure connection, as opposed to symmetric encryption, is the most resource intensive of the two. SSL (hardware) Acceleration was one of the first methods used to address this issue.

It consists of a physical PCI / SCSI card that you plug into your system. It’s equipped with a co-processor that handles part of the SSL (Asymmetric cryptography) processing freeing up resources on the web server. Data processing still takes place on the web server so it’s not the same as the SSL Offloading options mentioned earlier but it does increase performance. One of the main differences between SSL Acceleration and complete Offloading is that Acceleration is applied to just one server at a time and Termination and or Bridging can be applied to multiple web servers simultaneously. At least you have options, take your pick.

Let’s shake hands!

SSL primarily uses symmetric encryption, which consists of single shared key used for both encryption and decryption, when exchanging data between client and server systems. I say ‘primarily’ because during the SSL Handshake (initiating the connection and authenticating the server) asymmetric public key (consists of a key pair) encryption is used during the first phase. Symmetric encryption is considered less secure than asymmetric encryption, however, it’s much faster and thus far less resource intensive when it comes to encrypting and decrypting data, a trade off between the two you could say.

Asymmetric

Although, once the connection is established, SSL traffic is symmetrically encrypted, SSL connections are still prone to performance degradation and overall slowness because of the Handshake process involved. As mentioned, during this phase asymmetric public key encryption is used (much more resource intensive), the server needs to be authenticated, as well as the client when two-way authentication is applied, impacting overall performance significantly. This is where SSL Offloading and Acceleration come into play and do their magic. Just to clarify, here’s a general overview on the SSL Handshake process, got this from http://publib.boulder.ibm.com

Conclusion

Depending on your internal network, is it seen and treated as secure, security demands in general and the amount of data (or number of requests) that needs to be processed, all or a combination of the above methods might offer a solution. Implementing SSL Offloading is always going to be a trade off between speed and security. If we look at Citrix XenMobile in particular SSL Offloading wasn’t possible before december 2013, so even with end-to-end Termination configured, still burdening the web server with the extra load of SSL decryption and encryption, it’s a step forward from DMZ implementations.

To round things up, have a look at this Blog from Citrix:

http://blogs.citrix.com/2013/12/09/xenmobile-how-does-it-scale/

It will give you some great insights with regards to XenMobile sizing and Cluster / HA set ups. It will also provide you with a hyperlink to the XenMobile reference architecture. As you’ll notice, your environment will need to be pretty substantial before MDM will cave in when it comes to the number of mobile devices connection up to your MDM server and exchanging information.

Bas van Kaam ©

Reference materials used: Citrix.com, Microsoft.com, IBM.com, Windowssecurity.com and the Citrix E-Docs website.

Join [displaycount list=”Bas van Kaam”] other subscribers !

[optinform]

Bas van Kaam

Field CTO EMEA by day, author by night @ Nerdio

Father of three, EMEA Field CTO @ Nerdio, Author of the book Van de Basis tot aan Meester in de Cloud, Co-author of the book Project Byte-Sized and Yuthor of the book: Inside Citrix – The FlexCast Management Architecture, over 500 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast­­­­­­­­: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant and initiator of the AVD User group Community world wide.