ICA Encryption

ICA encryption allows the data connection between a MetaFrame server and an ICA client to be made secure. During the configuration of the ICA client or when publishing applications and desktops, it is possible to set the desired encryption options. The encryption level for the ICA protocol can be set through the extended connection settings of Citrix Connection Configuration or through the Terminal Services Configuration properties. It is also possible to set the required encryption of an ICA connection using a rule in the policies. The methods described in the following list progress from the weakest level of encryption to the strongest.

The available options for the encryption levels are as follows:

• Basic encryption based on a non-RC5-conform algorithm that does not provide complete protection from deciphering the data.

• RC5 encryption with 128 bit for authentication only; the ICA connection is encrypted with the basic procedure.

• RC5 encryption with 40 bit for the whole ICA data stream.

• RC5 encryption with 56 bit for the whole ICA data stream.

• RC5 encryption with 128 bit for the whole ICA data stream.

In principle, ICA encryption is a means of making it difficult or impossible for an unauthorized user to intercept data from an ICA communication and to display it in a comprehensible form without going to an excessive amount of trouble. An attacker could see, at most, meaningless screen commands, but he or she would be unable to extract any sensitive information.

ICA encryption is primarily used for internal communication within a corporate network. It is supported by almost all versions of the ICA client software. ICA encryption presents some problems if the communication is on public networks (the Internet) or across perimeter networks (demilitarized zones).

Note

A perimeter network uses firewalls to establish special network segments that do not belong to the internal or the external network. This is done using package filtering mechanisms. These perimeter networks (also known as DMZs, demilitarized zones, and screened subnets) contain particularly endangered components that can be addressed only from the intranet or extranet through special connection ports. The separation of servers with certain particularly exposed services usually increases the security of a corporate network considerably.

Citrix SSL Relay

The Citrix SSL Relay ensures consistent encryption through Secure Socket Layer (SSL) or Transport Layer Security (TLS) between appropriately configured MetaFrame servers and the ICA clients. (See Chapter 8.) The ICA data stream on the MetaFrame server is sent to the SSL Relay, which then encrypts the data following the standard procedure. Almost all ICA clients can then communicate with the MetaFrame server through the encrypted data stream.

It makes sense to use Citrix SSL Relay where only a small number of MetaFrame servers are concerned, no perimeter network is used, and the IP address of the MetaFrame server does not need to be hidden through Network Address Translation (NAT), but industry-standard consistent encryption between the MetaFrame server and ICA clients is required.

The basic prerequisite for using Citrix SSL Relay is that every MetaFrame server to be secured must have a server certificate installed under %Systemroot%\sslrelay\keystore\certs. Either an X.509 certificate can be bought from a certifying authority, or a certificate can be created through the company’s own Certificate Authority. After this has been done, the further configuration can be carried out by the Citrix SSL Relay Configuration Tool, which is found under Start\All Programs\MetaFrame XP.

Secure Gateway

A considerably more scalable means of encrypting the ICA data stream with SSL or TSL is the Citrix Secure Gateway. It establishes its own central instance in the network that can encode large numbers of ICA connections between MetaFrame servers and ICA clients. As with Citrix SSL Relay, the Secure Gateway uses server certificates.

The Secure Gateway encrypts the ICA data streams and the access to the MetaFrame server through a single point. This considerably simplifies the management of the certificates and means that the IP addresses of all of the involved MetaFrame servers do not need to be published. Only the Secure Gateway needs to have the MetaFrame server’s address information.

The problem here is that the ICA connection between the MetaFrame servers and the Secure Gateway is not secure. Only the connections between the Secure Gateway and the ICA clients are encrypted by SSL or TSL. It is therefore important in many environments to use the ICA encryption feature in combination with Secure Gateway.