In the recent Citrix announcement of XenApp and XenDesktop 7.6 the security features “FIPS Compliance” and “Common Criteria” were prominently featured.  This post describes one of the major building blocks to these achievements: enabling TLS/SSL support in XenApp and XenDesktop, all the way from endpoint Receiver, through the Gateway and onto the hosted session or workstation.

The need for FIPS compliance in the Federal market has been around for a long time.  What’s new is that it is becoming a topic of interest in commercial spaces.   Customers in banking, credit card processors and medical industries have all expressed interest in securing traffic inside their data center.  The SSL to VDA feature of XenApp and XenDesktop 7.6 assists with this goal.

FIPS Compliance – Had that for a long time

Citrix support for FIPS Compliance isn’t new.  Here is a link to a long list of Citrix FIPS configuration documents for everything from MetaFrame XP FR3 through XenApp 6.5 and XenDesktop 5.6.

What is “new” is that the VDA on XenApp and XenDesktop 7.6 can now natively speak TLS/AES and FIPS, without the use of network level security like IPsec and without the use of separate application components like SSL Relay.

See the green circle in the below graphic showing TLS/443 securing the internal data center communication.  This is the focus of this feature.

FIPS 140-2 network architecture, Citrix XenApp and XenDesktop 7.6

Outside – Nothing is new

Outside, everything has been SSL/TLS for a long time.  In the diagram above, observe that the StoreFront (or Web Interface) traffic is HTTPS and the ICA traffic from Citrix Receiver to the Gateway are all secured by TLS.   Outside, things have used FIPS approved algorithms (normally TLS/AES) for a long time.  With the excitement about SSL to VDA support in this release, it is worth noting that not a single line of code was changed in the Citrix Receivers to enable the function; the receivers have been speaking the right security language for a long time.  This also means that it is not necessary to upgrade Receivers to take advantage of the SSL to VDA in 7.6; there may be other good reasons for upgrading the receivers, but getting TLS isn’t one of them, the receivers already know how to do it.

Inside – Things are new

Inside, FIPS support in XenDesktop and XenApp has historically required additional work such as deployment of IPsec on the internal network or the use of separate application level components like Citrix SSL Relay.  The new thing in 7.6 is that FIPS TLS/AES to/from ICA conversion happens natively inside the VDA without the need for additional components and configuration.

Introduction complete, now we can get onto the meat of this post

SSL Relay goes away

In XenApp 6.x and way back in Presentation Server, a feature named “SSL Relay” was used to relay SSL to ICA, and ICA to SSL.  The SSL Relay application (.exe) was loaded on the XenApp servers and would listen for incoming chatter on SSL port (443) and upon receipt, decrypt and retransmit to localhost:1494/2598 where the ICA code would receive it.  This works and courtesy of the SSL Relay application, it was never historically necessary to teach the ICA stack itself to speak TLS.

Ring transitions are bad

A ring transition is when code passes the boundary from user mode to kernel mode or back the other way.  On Intel/Windows computers this is an expensive operation.  Since SSL Relay is a user space executable, when encrypted network traffic comes in on the network, the Microsoft TCP stack receives the data (in kernel mode) and passes it up to user space for processing (ring transition).   The SSL Relay process receives the packet, decrypts and relays the packet to the ICA code at localhost:1494/2598.  This is the local machine, so it’s close.  But, the transmission is via the TCP stack, which is in the kernel, so the system transitions back to kernel space (ring transition).  The TCP stack receives the packet and passes it on to the ICA stack – which is also in the kernel (at least that one was close by) and finally the data can be inspected for doing ICA stuff.  I’ve lost on the count of the number of ring transitions, but there are “many”.  This series of steps happens for every packet!  There are millions of packets! Even at 3GHz, this adds up.

SSL in the VDA

A superior solution skips the ring transitions.  The packets arrive kernel mode, are handed to the VDA in kernel mode, where the VDA does the decrypt/encrypt and hands the packet to the ICA stack, also in kernel mode.  Ring transition count = 0.  The “SSL to VDA” feature in the 7.6 release provides this capability.

HTTPS in the VDA

The ICA stack speaks multiple layers.  ICA protocol at the core (1494); it is wrapped in the more elaborate CGP protocol (2598), then the websockets HTTP protocol (for HTML5-based Receiver only), and finally by SSL/TLS (443) before transmission over TCP/IP.  Here’s a picture of the network stack.

Citrix ICA/CGP/HTML5/TLS/TCP stack in XenApp and XenDesktop 7.6

Before 7.6, each of these elements was in a separate device driver and the SSL portion was in user-mode.  The driver-stack chain of tdwsk.sys, tdcgp.sys and tdhtml5.sys hand data between each other.    With the addition of TLS to the native mix, complexity was mounting as there would have to be yet another driver in the chain.  Instead, this was all replaced with a single new driver, TDICA.sys, which is responsible for all the protocol transitions including TLS/SSL support.

The key point is that it’s now all in one place, the activity of processing packets, whether encrypted or not encrypted, is done with local function calls. No ring transitions, no movement between drivers.  The end result equals “efficient”.

A side benefit is that the HTML5 driver which is used by clients of the Chrome Receiver gains “session reliability” from the CGP driver.  CGP used to be outside the HTTPS path to ICA, now it is in.

The goal is SECURE, efficient is a bonus

Efficient for TLS/AES traffic is great, but the real goal is secure, and specifically encouraging the usage of FIPS approved algorithms and using validated crypto modules inside the data center.  We also want to make FIPS Compliance “easier” to achieve, to encourage the use of TLS in commercial spaces rather than the historic federal only.

With TLS now implemented in the ICA stack, SSL Relay is no longer used and IPsec is no longer needed.  Whether on old Presentation Server, XenApp 4, 5, or 6 or older versions of XenDesktop, all configurations now have a path inside and outside the data center using FIPS approved algorithms.

Administrator Configuration

SSL/TLS usage outside the data center has long been “standard”.  Administrators have considerable experience setting up web servers (StoreFront, Web Interface), with installing certificates, configuring firewalls and otherwise supporting HTTPS.  Nothing here has changed.

Administrators also have long experience setting up secure access to NetScaler Gateway.  Install a certificate on the gateway, generally from a public CA, Citrix Receivers outside the corporate network can reach out to the gateway and talk SSL/TLS/AES.  Again, nothing here has changed.

The Citrix Receivers have also known how to talk TLS/AES since the beginning of time.  They can talk both to the gateway, and for the internal case, directly to sessions inside the data center and they have known how to do this since at least Presentation Server 4 (2004).  They still do.  This means that embracing TLS inside the data center does not require upgrading Citrix Receivers.

Certificate installation on terminal servers

With XenApp 6.x terminal servers or even going back to Presentation Server, certificates get installed on the terminal servers and clients and gateways connect over SSL/TLS where SSL Relay would be used to convert TLS to ICA for processing by the hosted session.  Here, the quantity of terminal servers is comparatively small (10s, 100s) and installing certificates is normally a one-time job.  With the certificates in place, things talk securely and life is happy.

When the count of terminal servers is larger, it makes IT management and financial sense to utilize a company certificate authority for the issuance of certificates.  Active Directory can also assist.

Certificate installation on VDA workstations

What’s “new” with SSL to VDA expanding the adoption of TLS on the inside is that XenDesktop can have LOTS of “servers”.  A “server” can be a terminal server (XenApp) or a hosted workstation (XenDesktop) and each VDA needs its own certificate for secure TLS based communication.  If the count of workstations is … 10,000, the installation of certificates is a non-trivial problem that requires automation.

In a follow up post, my colleagues will review how to configure XenApp and XenDesktop 7.6 with TLS outside and inside the data center, including descriptions of certificate distribution; configuration of VDAs to use certificates and how to tell the broker to arrange TLS based connections.

Update: 11-Dec-2014: Link to part-2 blog is here, by Andy Cooper.

SSL to VDA – The feature is here, let’s put it to work and secure the world.

Joe Nord