ICA encryption with XenApp and XenDesktop comes in 3 flavors: Basic, SecureICA and TLS.
As a user, the remoted graphics look the same no matter how the data is encrypted, so how do you know what crypto is being used? If you are an administrator, the PowerShell CmdLet “GetBrokerSession” shows you information for every session that the broker is managing. When checking systems, I am usually a user and it turns out that this information is also available to mere mortals; this post shows how to get it.
Basic, SecureICA and TLS
A bit of history is needed. In the beginning, there were MODEMs. There wasn’t yet a driving need for ICA session encryption as the traffic was on a phone line, which presumably the bad guys couldn’t intercept. Later, still in caveman time, things were moved to local area networks and especially with hubs being used ahead of switches, “everyone” on the LAN could see the packets fly by; the era of needing ICA encryption was upon us.
“Basic” encryption is a relatively simple XOR-based algorithm that scrambles the data, so it doesn’t show up clearly on a network analyzer. SecureICA came next. This uses Diffie Hellman key exchange between the client and server and a 128-bit RC5 cipher to scramble the data. Though these were surely excellent choices in the time, today neither the key exchange nor the cipher are FIPS approved algorithms and though the data is pretty well scrambled vs. Basic, it isn’t as good as TLS.
Compare to web servers
In the modern world, web servers make HTTPS and TLS the norm. ICA can be wrapped inside of TLS and this has existed in XenApp (4, 5, 6) since around 2005 though we used to call it “SSL” and the component that enabled this function is/was “SSLRelay”. In XenApp/XenDesktop 7.6 the TLS processing is moved into the Virtual Desktop Agent (VDA) itself, without using the SSLRelay component.
Here’s a blog that describes this function and a related Synergy 2015 breakout video that goes into some detail.
TLS usage for web servers requires installation of certificates on the web servers. This allows the web browser client to connect securely and the client can determine that it is indeed talking to the true host that it thinks it is. As with web servers, with TLS to VDA, certificates are required on the VDA servers whether they are terminal servers or hosted workstation and as with web server, this installation of certificates is a pain in the neck, but it is also the thing that secures the connection. The result is modern, industry standard crypto that is FIPS compliant and certifiably well-scrambled.
What crypto am I using?
The diagram below shows places where the crypto is in question. See “1”, “2” and “3”.
Remote access
Today, I am “at home” running a hosted workstation session at the office, Windows 8.1 via XenDesktop 7.6, with a NetScaler Gateway in the middle providing the ICA proxy. ICA proxy is a huge security advantage vs. classic VPN and that alone is a good topic for a future post or a small book, but which I will save for another time.
For today, know that the external network and the internal network are completely separate. The end user endpoint computer has no network visibility to the internal network and only the screen/keyboard ICA stuff travels across the gateway.
To figure out what crypto is being used, start at the Citrix Receiver on the client. Open the Windows system tray. The Citrix Receiver icon is black with squares, Right-Mouse-Button and then click About. Yes, “About”. Click on Advanced to expand, get this screen.
Click “Connection Center” to see your connections.
Select a connection on the left, and click “Properties” and you’ll see a dialog like this.
Survey says that connection “1” from home to the NetScaler Gateway is encrypted with TLS using a 128-bit cipher, which is probably some form of AES. Exactly which version of TLS is used and which cipher, I can’t see here, but it is negotiated between the Citrix Receiver client and the NetScaler Gateway using the same techniques as web servers.
Inside the NetScaler Gateway
At the NetScaler Gateway, the TLS packets are descrambled to reveal ICA data, which is then forwarded on to the workstation or terminal server host. If the internal connection is TLS, this ICA stream is wrapped inside TLS before being sent to the host. Observe that the TLS held ICA data is decrypted on the NetScaler. It is for this reason that I have steered people away from using the term “end to end SSL”. It isn’t. It is TLS from endpoint to the Gateway and then possibly also TLS from the Gateway to the host, but on the Gateway, it’s clear. This has advantages.
Pulling the TLS apart at the NetScaler Gateway makes it possible to use public CA certificates for the NetScaler Gateway “outside” and this means that users accessing remotely do not need to have a company root certificate installed on their endpoint computer and that a “default” installation of a computer, web browser and Citrix Receiver has a high probability of connecting. It also means that a company CA can be used internally, where installing a company root certificate is easier, meaning that the quantity of certificates that must be purchased is greatly reduced vs. an all public CA scenario. Pulling the TLS/ICA data apart at the Gateway also makes it possible for NetScaler Insight to perform ICA inspection.
Encrypted traffic arrives at the VDA
The ICA data travels across “2” and arrives to the VDA which is running on the terminal server or workstation host. This is true whether the VDA is a XenDesktop 7.6 terminal server or workstation or even XenApp 6.5 system. Different names, same function.
What crypto was used? How do I see it?
Consider that the programmers developing the VDA code need to know what crypto is being used and while it is possible to use network traces to get this information, programmers tend to automate things that consume their time. The VDA already knows the answer; a tool is needed to ask it, and one was written. It is named CtxSession.exe and what is neat is that it is installed with the VDA! It is command line, low budget, but it gets the job done.
For this post, I have verified that the tool exists on XenDestkop 7.6 VDA installation. If earlier versions also include this and you have quick access to that information, please add to the comments.
To run the tool, command prompt, change directory to the directory holding the VDA binaries. Execute “ctxsession –v”. In a workstation case, it will show your session (singular). On a terminal server case, if you are an admin, it will show you all the sessions, or if you are a user, it will show you your session and a whole bunch of access denied messages for all the other sessions.
Here’s what I get…
The survey reveals that my connection is using “CGP -> ICA”. That means, ICA wrapped inside of CGP. CGP is the protocol that implements “session reliability” allowing ICA to recover from brief network outages like those you will encounter when on wifi and walk down the hallway with the notebook lid open and you switch wifi access points as you walk. It is normal to have this enabled.
The –v (verbose) option also has the tool spit out some additional information on the IP address of the hosted desktop system and the gateway. The concepts of “local” and “remote” shown here are as viewed from the perspective of the VDA running on the hosted desktop. In the remote access case where I am logged in presently, the Remote Address is the internal network IP address of the Citrix NetScaler Gateway and the local address is the IP address of the hosted desktop system itself, in my case the Windows 8.1 workstation that is running the VDA.
Internal only query “3”
The internal only case “3” is just a variation of the above that doesn’t involve a NetScaler Gateway. For the internal only case, the “Remote Address” shown from ctxsession will be the IP address of the Citrix Receiver client machine.
PORTS
The tool also tells us which IP port is being used. Citrix ICA uses a well-known IP port address of 1494. CGP (Citrix Gateway Protocol = Session reliability) uses 2598 and the display above shows that 2598 is being used and this is consistent with the information display of CGP -> ICA. Separately, this port usage can also be shown with netstat.
Remote Access Summary
Analysis says that connection from my house to hosted workstation is using TLS on the outside and CGP on the inside. For today’s crypto inspection, I have confirmed that I have TLS on the outside and that is good, but that I do not have TLS on the inside and that, well it isn’t actually necessarily bad, but me being a security guy, I do like TLS everywhere. An outstanding question is whether the internal connection is using Basic encryption or SecureICA. From this information alone, I don’t know.
Update: 16-Jul-2015. Actually, the answer is there. The Client Connection Status dialog shows “Basic. 128-bit SSL/TLS in use”. The “Basic” in that display is the ICA encryption. Below activity still good though.
To answer, disconnect from the hosted session. Logon a different hosted desktop to “get inside”. From there, launch an “internal” (no gateway) connection to the original hosted desktop and repeat the procedure of Connection Center, Receiver, About, Advanced, Properties.
Survey says “Basic”. Technically, this measurement is an estimate. The inside Citrix Receiver connection to the host renegotiated everything, I am making an assumption that the internal and external connections use the same crypto and if I am using roughly the same Citrix Receiver client remote and local, it is probably correct. I would prefer that this internal connection is SecureICA. It isn’t. That said, smart people tell me to not get too worked up on Basic vs. SecureICA. The question I should really be asking is, “is it TLS”?
FIPS Example
Switch to another farm with FIPS 140-2 configuration. Still XenDesktop 7.6, but this one has TLS on the outside and TLS on the inside. Here is a screen shot of ctxsession.
What wonderful information this provides! Connection from NetScaler Gateway to hosted desktop is ICA, wrapped inside CGP, wrapped inside TLS. TLS is negotiated at level 1.0 and yes, that’d be better if were cranked along to 1.2, but it’s a good start and the cipher is AES-256, which by comparison is likely complete overkill for the data on this machine vs 128.
Closing thoughts
Is TLS needed outside the Gateway? Yes, Absolutely!
Is TLS needed inside? … It depends.
For some customers, the expectation of attack on the internal network is very low. This means that the investment to deploy TLS on the inside has a cost that may not be justified vs the value of the data * the expectation of compromise. How well controlled is your internal network? How likely is it that an adversary will have a presence on that network to inspect and possibly manipulate traffic? What are the odds that computers on your internal network be compromised and used remotely for an attack? Do you have evil insiders?
Some customers set up entire subnets just to run a particular set of applications and these are always accessed via a Gateway. Consider that if the only purpose of the internal network is to run that application, then the value of TLS securing the data on that partitioned network is reduced because anyone that can get to that network is already able to access the data without having to resort to network traffic inspection. That is, the protection point is the Gateway, not the internal network. Still, it is hard to argue, yes, making the network communication TLS has security advantages. TLS also permits securing the network without using network level security like IPSec, so it’s a winner. But, it does take work to get it operational.
Where is safe?
In worlds of old, we had a pretty high expectation that our internal networks were safe zones. In modern times, that formula is changing and using TLS on the inside is becoming more common as one piece of countering advancing threats. Implementing TLS to VDA requires growing the skill base in deploying encryption certificates for the VDAs on the XA/XD farms. The ability is there in 7.6; as my part of securing the world, I ask that you please put it to use.
Joe Nord