Understanding Encryption

---

Encryption has become extremely common in today's Web-enabled world. Companies need to secure their data so that it is only read by the intended recipient.

Encryption generally comes in two forms:

• Public Key-Private Key This type of encryption uses one key to encrypt the data, and one key to decrypt the data. The public key is used during the encryption process. Once the data is encrypted, it is sent to the recipient who then uses the private key to decrypt the data. The public key in this scenario can be transmitted freely across public lines. No data is contained in the public key that can compromise the private key. If an unauthorized user was to obtain the public key, they could only encrypt data, not decrypt it. This means that since the private key is used to decrypt your data, it must be kept secure at all times. The drawback to Public Key-Private Key is its speed. Though it is considered more secure than symmetric key encryption, it is also slower.

• Symmetric Key This encryption is a little different. It uses the same key to both encrypt and decrypt the message we are sending. While this encryption method is generally faster than Public Key-Private Key it also depends on the symmetric key remaining totally secure and never being compromised. This means that the symmetric key must be sent over a secure channel or hand delivered to the parties involved in the communication.

Another way to rate encryption is by the length of the key encrypting the data. A key that has only 8 bits would have 256 possible combinations. Trying each one of the combinations on a modern computer would take less than a second. But a key that has 128 bits would have 2^{128 possible keys. It is} estimated that a modern parallel processing computer like a Cray would take 1018 years to try every combination in a 128-bit key.

MetaFrame XP uses both of these encryption methods in its technology. MetaFrame uses the RC5 algorithm to encrypt data sent between the MetaFrame server and its ICA client. The RC5 algorithm was developed by RSA security and is a Symmetric Key algorithm, meaning the symmetric key must be delivered to the participants in a secure manor. For this, MetaFrame uses a Public Key-Private Key algorithm called the Diffie-Hellman key agreement algorithm.

The Diffie-Hellman key agreement algorithm was designed to allow two computers to exchange information that would allow both to arrive at the same exact symmetric key without ever transmitting data in the communication that would compromise the symmetric key used in that session.

The MetaFrame server runs an encryption service that generates two numbers at random intervals. These numbers, called Diffie-Hellman parameters, are used during key negotiation. When a secure ICA client establishes an encrypted session, the MetaFrame server and client use a public key algorithm to pass public keys and these parameters over the communication path. Using these parameters, the client and server's private and public keys, both the client and the server arrive at the same unique symmetric key. This symmetric key is 1024 bits long and unique for every client connection.

Exam Watch 

The exam is sure to test your knowledge of the two different encryption methods and how MetaFrame uses each. You should understand how they work and what the name of each algorithm is.

MetaFrame XP also supports three levels of encryption above Basic: 40-bit, 56-bit, and 128-bit. In addition to these three levels of encryption, MetaFrame also offers the following security features:

• 128-bit encryption during user authentication.

• Compatibility with the latest ICA clients for DOS, Win16, Win32, Web Clients, Windows CE, and Linux x86 clients. (The Linux ARM client is not supported.) These clients ship with MetaFrame XP (version 6.01.xxx) and support encryption. Earlier MetaFrame clients that were not distributed with Secure ICA may not support encryption.

• Enforceable minimum encryption levels that can be specified by Connection type using Citrix Connection Configuration or by Published Application using the Citrix Management Console.

• Dynamic key generation for each new ICA session.

When a user connects to a MetaFrame server, the entire ICA packet (except for a small encryption header) is encrypted. All ICA data between the client and the MetaFrame server are transmitted securely. This includes the following:

• Video updates and graphics information

• Keystrokes and mouse movements

• Client drive information

• Client printer data

• Client audio data

Exam Watch 

Be sure to know what data is encrypted when using Citrix encryption. The exam is sure to test your knowledge of this.

Now that you have a better understanding of encryption, here are some possible scenario questions and their answers:

Scenario & Solutions

You have just increased the required encryption level for your TCP connection. You then receive calls from several users stating that they can no longer connect to the MetaFrame server. After investigation, you find that all these users have a Mac client operating system. What can be done to resolve this issue?	You must reset the required encryption level to Basic if the Mac users are to connect. The Mac client does not support encryption above Basic.
You are contacted by one of your users, who asks if his data is encrypted when he saves it. He has been saving data from his Citrix session to a remote share on a file server.	Citrix does not encrypt this communication path. ICA encryption would encrypt communication between his Citrix session and his local client device, but not a file save to a remote server.
You are tasked to deploy Citrix in the most secure manner possible. You decide every connection should require 128-bit encryption. You audit you local client base and find that it contains the following OSs: Windows 9x, Windows 3.1, and Linux. Will you be able to encrypt all ICA traffic?	If the Linux clients are on Intel x86 platforms, yes. There are secure clients for Win32, Win16, and Linux x86.

Configuring Encryption on a MetaFrame XP Server

There are two basic ways to configure security in your MetaFrame XP farm. You can enforce the encryption level at the connection the users use to connect to the MetaFrame server, or you can force the encryption level for specific published applications.

To configure a connection for minimum encryption, open Citrix Connection Configuration, edit the properties of the connection, and under the Advanced Connection Settings change the required encryption level to the one you wish to enforce. (See Figure 7-9.)

Figure 7-9: Advanced Connection Settings under Citrix Connection Properties

Exercise 7-3: Configuring a Connection to Use Encryption

1. Using Citrix Connection Configuration, edit the properties of the connection you use to connect to your server (e.g., ICA-TCP).

2. Edit the Advanced Properties of this connection by selecting the Advanced button in the Connection Properties window.

3. Set the required encryption level to 56-bit.

4. Save your changes to the connection.

5. Using the ICA client, create a connection to the server that uses 40-bit encryption.

6. Execute this connection and verify that you receive a message stating 'You do not have the proper encryption level to access this session.'

7. Select OK on the message.

8. Change the connection you created in step 5 to use 56-bit encryption.

9. Attempt to connect to the Citrix server now. You should connect successfully.

On The Job 

When using NFuse and forcing encryption at the connection level, you may experience problems where users have a secure client, launch an application via NFuse, but still receive the message that they do not meet the required encryption level. The easiest way to fix this, if you do not mind running encryption for every session (which you must not, since you set it at the connection level), is to set each application to use the encryption level you forced at the connection level. This information will be included in the ICA file when users connect to the NFuse site to launch applications, and their session will begin with the required encryption.

To configure an application to use encryption, we must change its default settings in the Citrix Management Console (see Figure 7-10). Do so by editing the properties of the published application. Go to the ICA Client Options tab and change the encryption level using the pull-down menu.

Figure 7-10: ICA client options within the properties of a published application

Security and NFuse

When using NFuse to allow users access to your farm via the Internet, there are several security questions that need to be taken into consideration. Some of these include these:

• How do I secure my user credentials between the client browser and my Web server?

• Is the information sent between my Web server and my MetaFrame server secure? If not, how can I secure it?

• Is the ICA session encryption taken care of by the Web server?

• What is placed in the ICA file that could be compromised?

The following security mechanisms have been put in place to address each of these items individually:

• Secure Hypertext Transfer Protocol (HTTPS). This is a secure version of HTTP used on the internet. It uses Secure Sockets Layer (SSL) to secure data passed through it. The NFuse Web pages should be configured to use HTTPS (see Figure 7-11) in order to guarantee that the user credentials are encrypted when they are passed from the client browser to the Web server. (See your Web server's admin guide on how to configure SSL).

Figure 7-11: The Directory Security tab for the default Web site on an Internet Information Server version 5

SSL relay also uses the SSL protocol, but the SSL relay encrypts the data between the Web server and the back-end MetaFrame server. Without the SSL relay being used, application information and user credentials are passed between the MetaFrame server and the Web server as clear text. (See the Citrix SSL Relay Configuration later in this chapter).

• ICA encryption (RC5) is used to secure the session information just as it would be in a normal session not using NFuse. This will encrypt all data sent between the ICA client and the MetaFrame server.

• Authentication tickets are used to keep the user's credentials secure in the ICA file downloaded to the user. The ICA file, by default, contains the user's username and domain name in clear text. The password is 'scrambled' in the ICA file. If the ICA file was captured, these credentials can be cut and pasted into a new ICA file and reused over and over. An authentication ticket is issued to the user and used in place of the user's credentials. This ticket is encrypted and good for only one use or 200 seconds. Once it has been used, or the timeout has expired, the ticket will no longer be accepted by the MetaFrame servers. (See Figure 7-12 and 7-13.)

Figure 7-12: Typical Nfuse ICA file not using authentication tickets

Figure 7-13: NFuse ICA file using authentication ticketing

Exam Watch 

In order to pass the exam, you must know each of the security functions for NFuse. HTTPS for login credentials, SSL Relay for Web server to MetaFrame server security, ticketing for securing ICA file user credentials, and RC5 for securing the ICA data stream.

Citrix SSL Relay Configuration

This tool is used to configure secure communications between your Web server and the back-end MetaFrame server. It can be accessed under the Citrix Program group and has three major tabs: Relay credentials, Connections, and Ciphersuites. (See Figure 7-14.) At the top of each tab is a small box that will indicate whether the information in that tab has been saved to the registry or not. A green check mark indicates the information is stored in the registry, while a red X indicates that the information has not been written to the registry yet.

Figure 7-14: The Relay Credentials tab of the Citrix SSL Relay Configuration tool

From the Classroom-NFuse Communication and Security

One of the toughest things to teach a new Citrix administrator is security as it relates to NFuse. The main reason for this is the new administrator's lack of understanding regarding how NFuse itself works.

The best way to learn these features is to first draw out how NFuse functions without concern for security. Draw out the following objects and their communications paths:

• Client Web browser communicates with the Web server, passing user credentials to the Web server.

• The Web server communicates with the MetaFrame XP server on behalf of the client, passing the user's credentials to an Extensible Markup Language (XML) service on the MetaFrame server and receiving back a list of applications.

• The Web server issues an ICA file to the client that contains connection information for the server.

• Client establishes an ICA session with the MetaFrame server.

Now that you have the communication paths drawn out, you can see everything that needs to be secured. We can see that the client to Web server communication path needs to be a secure (HTTPS connection). The data sent between the Web server and the MetaFrame server needs to be secured (SSL Relay). The ICA file contains the username and domain in clear text, along with just a lightly scrambled password that can be used over and over (authentication tickets). And the ICA stream itself needs to be secure (RC5).

-Ron Oglesby MCSE, CCEA, CCI, CSA

The Relay Credentials tab contains the following information (see Figure 7-14):

• Key Store Location This specifies which directory on the server contains the certificate used to present the relay's identity to the NFuse Web servers. The default location for this certificate is %SYSTEMROOT%\SSLRelay\keystore.

• Display Friendly Name This will display the Certificate's friendly name instead of its common name (generally the server name).

• Server Certificate Specifies the server certificate used to identify the SSL Relay.

• Password Specifies the password used by the selected server certificate.

The Connection tab contains configuration settings for the listener port and specifies the destinations for the SSL Relay (see Figure 7-15).

Figure 7-15: The Connection tab in the Citrix SSL Relay Configuration dialog box

• Relay Listening Port Specifies the port over which your Web server will communicate with the SSL Relay. This uses the default SSL port of TCP 443. If you change the port number for the SSL relay, you must also change the port number on your Web server.

• Server IP Address Shows the IP addresses of the MetaFrame XP servers to which decrypted packets will be sent. By default, only the server hosting the SSL Relay is listed, but other MetaFrame server can be added for redundancy.

• Ports Specifies which TCP port is being used for the XML service. The default for this port is 80, but this can be changed during install or later using a command-line utility.

• New Allows you to add additional MetaFrame XP server to the relay destination list. You will need to configure the target server's IP address, the port number in which the XML service is running, and the source address for the packets.

The Ciphersuites tab contains the settings that configure which ciphersuites the SSL relay will accept from the Web server. A ciphersuite is an encryption/decryption algorithm. This tab contains a list of all Citrix supported ciphersuites. From the list of available ciphersuites, you may select which ciphersuites you wish to use. The Add button moves the selected ciphersuite from the list of available ciphersuites to the list of selected ciphersuites. The Delete button removes a selected ciphersuite (see Figure 7-16).

Figure 7-16: The Ciphersuites tab in the Citrix SSL Relay Configuration tools

In order to configure an SSL relay, you must obtain a server certificate from a Certificate Authority such as Verisign (www.verisign.com). This certificate must then be copied into the Keystore directory; the default is %SYSTEMROOT%\SSLRelay\Keystore\certs. You must keep the original file extension of the certificate file sent to you and use the KEY extension for the private key file. Once this is installed, use the Citrix SSL Relay Configuration tool to configure the certificate and the servers you will relay to.

Now that you understand how to configure encryption for the server and security for NFuse, here are some possible scenario questions and their answers:

Scenario & Solutions

You have deployed NFuse to the Internet to allow your users to access their applications from home. Your company hires a consultant to perform a security audit, and he finds that he can capture the username, domain name, and password of any user logging in to this Web site. What security feature needs to be put in place to correct this?	HTTPS should be configured to secure the username and password transmission to the Web server. The security consultant has most likely captured the data between clients and your Web server.
You have decided to place your IIS server outside the firewall, but are worried about the server-to-server communication between the IIS server and the MetaFrame server. How can you secure this communications?	Configure your MetaFrame server to use an SSL Relay. This will allow for secure communication between your Web server and the MetaFrame server.

---