ICA encryption with XenApp and XenDesktop comes in three flavors: Basic, SecureICA and TLS.
When searching the remoted graphics look the same no matter how the data is encrypted, so how do you know what is used crypto? If you are an administrator, the PowerShell cmdlets "GetBrokerSession" shows you information for each session that the broker is managing. If check systems, I am a user usually and it turns out that this information is available to mere mortals also available; This article shows how to get it.
Basic, SecureICA and TLS
is required A bit of history. In the beginning there was MODEM. It was not a driving need for ICA session encryption because of the traffic on a telephone line was that probably catch the bad guys could not. Later in caveman times things were moved to local networks and is primarily used with hubs at counters, "all" on the LAN can see fly the packets through; the era of ICA encryption of having been on us.
"Basic" encryption, a relatively simple XOR-based algorithm, which encrypts the data, so it does not show, is not unique in a network analyzer. SecureICA came next. This uses Diffie-Hellman key exchange between client and server, and a 128-bit RC5 cipher to encrypt the data. Although these were certainly in time an excellent choice today neither the key nor the exchange cipher are FIPS-approved algorithms and although the data is pretty good against encrypted reason it is not as good as TLS.
compare to the Web server
In the modern world, making Web server HTTPS and TLS the norm. ICA can within TLS and this there was in XenApp (4, 5, 6) since around 05 are wrapped, even though we used to call it "SSL" and the component that this feature is enabled / was "sslrelay". In XenApp / XenDesktop 7.6 TLS processing in the Virtual Desktop Agent (VDA) moves without the sslrelay component.
Here is a blog that describes this feature and associated Synergy 2015 breakout video that detail goes.
TLS use for web server requires the installation of certificates on the Web servers. This makes it possible to connect the client Web browser sure and the customer can see that it speaks in fact the true host that it thinks it is. As with the web server with TLS requires VDA certificates on the VDA servers, whether they are Terminal Server or hosted workstation and as with Web Server this installation of certificates, is a pain in the neck, but it is also, which secures the connection. The result is a modern industry standard crypto, the FIPS-compliant and is certifiably well encrypted.
Which crypto I'm with?
The following diagram shows places where the crypto in question. See "1", "2" and "3".
Remote Access
Today I am "at home" a hosted workstation session running on the office, Windows 8.1 on XenDesktop 7.6, with a NetScaler Gateway providing in the middle of the ICA proxy. ICA proxy is a great safety advantage over traditional VPN and that alone is a good topic for a future post or a small book, but I'll save for another time.
There are know that the external network and the internal network are completely separated. The end user endpoint computer has no network visibility to the internal network and only the screen / keyboard ICA stuff moves through the gateway.
To find out which crypto is used to start the Citrix Receiver on the client. Open the Windows taskbar. The Citrix Receiver icon is black with squares, the right mouse button and then click About. Yes, "About". Click to expand Advanced, you get this screen.
Click to see "Connection Center" your connections.
Select. A compound on the left, and click "Properties" and you get a dialog to view as follows
survey says that the connection "1" from home on the NetScaler Gateway is encrypted using TLS with a 128-bit encryption, probably some form of AES is. Exactly what version of TLS is used and the cipher, I can not see here, but it is negotiated between the Citrix Receiver client and the NetScaler gateway using the same techniques as the Web server.
Inside the NetScaler Gateway
on NetScaler gateway TLS packets are to reveal descrambles ICA data then to the workstation or Terminal Server Host forwarded. When the internal connection is TLS, these ICA stream is wrapped within TLS, before being sent to the host. Note that the TLS decrypted ICA data on the NetScaler held. It is for this reason that I have directed people away from the use of the term "end to end SSL". It is not. It is TLS from the endpoint to the gateway and then possibly TLS also the gateway to the host, but on the gateway, that is clear. This has advantages.
on the NetScaler gateway TLS pulling enables public CA certificates for NetScaler Gateway to use "outside", and this means that the user remote access do not need a company to be installed root certificate on their endpoint computers, and that a "default" install a computer, Web browser and Citrix receiver has a high probability to join. It also means that a company CA can be used internally, where a company root certificate installation is simple, which means that the quantity of allowances that are greatly reduced against all public CA scenario purchased must. Drag TLS / ICA data except in the Gateway also makes it possible to perform NetScaler Insight ICA inspection.
Encrypted data traffic on the VDA is
The ICA data traveling over "2" and comes to the VDA, the run on the Terminal Server or Workstation host becomes. This is true whether the VDA is a XenDesktop 7.6 Terminal Server or a workstation or even XenApp 6.5 system. Various names, the same function.
Which crypto was used? How can I see it?
you have concerns that the programmers of the VDA code need to know to develop, which crypto is used, and while it is possible to use network takes to get this information, tend programmers to automate things that consume their time , The VDA already knows the answer; a tool is needed to ask them, and they were written. It is named CtxSession.exe and what's neat that it is installed with the VDA! It's command line, low-budget, but it is the work done.
for this article, I have found that the tool on XenDestkop 7.6 VDA installation exists. If earlier versions they are also, and you have quick access to this information, please add to the comments.
run the tool, command prompt, change to the directory containing the VDA binaries keeping. Run "ctxsession -v". In a workstation case, it shows your session (singular). On a terminal server case, if you are an administrator, it will show you all sessions, or if you are a user, it will show your session and a number of access denied messages for all other sessions.
Here's what I ...
The survey shows that my connection with "CGP -> ICA". This means ICA wrapped within CGP. CGP is the protocol that allows ICA down and go "Session Reliability" to recover from brief power outage that you implemented when encounter on WiFi and walking down the hall with the notebook lid open Wi-Fi access points, such as you walk. It is normal to enable this.
The -v (verbose) option and the tool has spit out some additional information about the IP address of the hosted desktop system and the gateway. The concepts of "local" and "remote" are shown here, are running seen from the perspective of the VDA on the hosted desktop. In remote access case where I am currently logged in 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 , the VDA is running.
internal Query only "3"
The internal only case "3" is only a variation of the above that no NetScaler Gateway includes. For internal only case of "Remote Address" of ctxsession shown the IP address of the Citrix Receiver client computer will be.
ports
The tool also tells us which IP interface is used. ICA uses a known IP port address of 1494 CGP (Citrix Gateway Protocol = Session Reliability) used in 2598 and the display above shows that will be used in 2598 and this is consistent with the information display of CGP -> ICA. Regardless, this port usage displayed with netstat.
Remote Access Summary
The analysis says that the connection used by my house to hosted Workstation TLS on the outside and CGP on the inside. For today's crypto inspection, I have confirmed that I, TLS on the outside, and that's good, but that I do not TLS on the inside, and that, well, it is actually not necessarily bad, but me to be a security guard I do like TLS everywhere. A remaining question is whether the internal connection of the Basic encryption or SecureICA used. From this information alone, I do not 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 this display is the ICA encryption. Below activity but still good. to answer
, disconnect it from the hosted session. Logon other hosted desktop to "get inside". From there, start a 'internal' (no goal) connection to the original hosted desktop and repeat the procedure from the Connection Center, receiver, About, Advanced, Properties.
survey says: "Basic". Technically, this measurement is an estimate. The internal Citrix Receiver connects to the host everything renegotiated, I make an assumption that the internal and external connections use the same crypto and if I use the same Citrix Receiver client remotely and locally'm about, it is probably correct. I would prefer that this internal connection is SecureICA. It is not. That is, intelligent people do not tell me to order based vs. SecureICA upset. The question I should really ask, "it is TLS"?
FIPS example
Switching to another farm with FIPS 140-2 configuration. Still XenDesktop 7.6, but this has TLS on the outside and TLS on the inside. Here is a screenshot of ctxsession.
What wonderful information it provides! Connection of NetScaler Gateway to hosted desktop is ICA, wrapped within CGP, wrapped within TLS. TLS is negotiated at level 1.0 and yes, it would be better if, were driven along to 1.2, but it is a good start, and the cipher is AES-256, which compared full probably overkill for the data on this machine vs 128.
closing thoughts
Is TLS required outside the gateway? Yes absolutely!
Is TLS required inside? ... It depends on.
For some customers, the expectation of the attack on the internal network is very low. This means that the investment is TLS provide on the inside at a cost that can not be justified against the value of the data * the expectation of compromise. How well controlled is the internal network? How likely is it that an opponent are represented in this network, is to examine and possibly manipulate traffic? What are the chances that the computer be compromised in your internal network and used from distance for an attack? Do you have nasty insider?
set some customers perform only entire subnets on a particular set of applications and they are always addressed via a gateway. Keep in mind that if the only purpose of the internal network is that the application will be executed, then the value of TLS is reduced to the data of this partitioned network security because anyone who can get to this network already able is access the data without having to network traffic inspection. That is, the protection point is the gateway, not the internal network. Still, it's hard to argue yes, the communication network make TLS security benefits. TLS also allows to secure the network without such IPSec network level security, so it is a winner. But it takes work to get it into operation.
Where is safe?
Add worlds old, we had a pretty high expectation that our internal networks were safe zones. At the present time the formula is changing and TLS used on the inside, is more likely than a piece counter continues to be threats. TLS implementation requires VDA in providing encryption certificates for VDAS the XA / XD farms the skills base grows. The ability is there in 7.6; to secure as my part of the world, I ask that you please put it in use.
Joe North
0 Komentar