- Citrix NFuse 1.5: Part 3 - Security
- Client/Web Server Communications
- Web Server/MetaFrame Server Communications
- Client/MetaFrame Server Communications
Web Server/MetaFrame Server Communications
The NFuse Web server communicates with the Citrix server farm via one or more MetaFrame servers running the Citrix XML Service. User credentials are transmitted from the Web server to the XML Service in exchange for the user's application set data. Except for user passwords, which are encrypted with Basic encryption, all other data is transmitted in clear text. As such, this leaves the communications channel vulnerable to sniffer attacks. An attacker could intercept standard user credentials and session tickets, both of which could then be used to access the MetaFrame server farm.
Citrix suggests two possible courses of action to eliminate this risk:
-
Configure the MetaFrame server as the Web server. Although this eliminates the network transmission of the XML data completely, it can introduce additional security and stability concerns, the most obvious of which is that MetaFrame user sessions can now directly impact the Web server's availability. The MetaFrame server itself may also become vulnerable to certain Web server security weaknesses.
-
The alternative is to use the Citrix SSL Relay option available as part of Feature Release 1. The Citrix SSL Relay allows the XML data transmission between the Web and MetaFrame servers to be secured using the standard Secure Sockets Layer (SSL) protocol.
Currently the Citrix SSL Relay feature is not supported in the MetaFrame for UNIX environment.
Citrix SSL Relay
When SSL Relay is used, the Web server is configured to send and receive user information via the Relay instead of directly from the XML service. In turn, the Relay communicates with the XML service on behalf of the Web server, as shown in Figure 5.
){kind=link}
The Citrix SSL Relay
By default, the SSL Relay communicates only with the XML service running on the same physical machine, thereby eliminating the clear-text transmission of credentials over the network. The Relay can be configured to broker NFuse Web server information on behalf of multiple XML services running on different machines, but this once again introduces clear-text credential transmission from the Relay to the remote XML service. This may be acceptable if the other MetaFrame servers are located on a private network that is physically protected from possible data sniffing.
Configuring SSL Relay
As I mentioned, to use SSL Relay, you must have an activated FR1 license on each MetaFrame server on which you want to run the SSL Relay service. Typically the Relay service is set up on each of the MetaFrame servers that the Web server has been configured to communicate with. You are not required to have the SSL Relay service installed on all servers in your Citrix farm. By default, the Relay service uses port 443, the standard listening port for SSL communications.
The process by which the Web server initiates a connection with the SSL Relay is identical to how a Web browser would initiate an SSL connection with a Web server. The Web server first requests a server certificate from the SSL Relay. It then establishes the SSL connection only if it can verify the certificate against a list of certificate authorities that it trusts. If the certificate cannot be validated, the connection fails and the Web server generates an error page.
To configure your NFuse environment to use SSL Relay, you will need to do to the following:
-
Ensure that an FR1 license has been added to the MetaFrame server that is going to run the SSL Relay service.
-
Acquire a certificate for the MetaFrame server. In my example, I am going to use a certificate generated by my internal certificate authority (CA) running on a Windows 2000 Server.
-
Ensure that the CA has been added to the trust list on the Web server.
-
Run the SSL Relay Configuration utility to assign the certificate and complete the Relay configuration.
-
Modify your existing Web pages, or generate a new Web site using the Web Site Wizard that has been set up to use SSL Relay.
Acquiring a Server Certificate
One of the areas that people seem to have the most difficulty with when setting up the SSL Relay service is the actual creation and assignment of a server certificate. The following is an example of the steps that I follow for generating a server certificate for a Windows 2000 Terminal Server from a Windows 2000 Certificate Server.
In this example, my certificate server is called TITAN, and my Terminal Server is called MEDUSA. The steps to create the certificate are as follows:
-
Log onto the Terminal Server, open IE, and point the browser to the certsrv Web page on the certificate server (for example, http://titan/certserv). The Certificate Services Web page should appear.
-
Select Request a Certificate, and click Next.
-
Select Advanced Request, and click Next.
-
Select Submit a Certificate Request to This CA Using a Form, and click Next.
-
The Advanced Certificate template should now appear, as shown in Figure 6. Make sure to select the Web Server template and then provide the name of the MetaFrame server in the name field that corresponds exactly to how it will be configured on the NFuse Web server. This name must match exactly, or the certificate will not be authenticated properly. In my example, I will simply use the Terminal Server host name (MEDUSA). I could use the fully qualified domain name medusa.noisyriver.com if I wanted, but I would need to use the same name on the NFuse site. If you end up having issues with the certificate, this is most likely where you have gone wrong.
Name and security settings in the certificate wizard
-
The other options on this form can be left as is, with the exception of Mark Keys as Exportable. Do not select the Export Keys to File option.
-
Click the Submit button to process the certificate request.
-
Click the Install This Certificate link to install the certificate on the MetaFrame server. We are not quite done yet. While the certificate is now on the server, the SSL Relay service will not yet be capable of seeing it.
-
Start up the Microsoft Management Console (MMC), and add the Certificates snap-in for My User Account. Open the Certificates folder under Personal, and find the certificate you just created. See Figure 7.
-
Right-click the certificate, and then select Export from the All Tasks menu.
-
When prompted, select Yes, Export the Private Key.
-
On the Export File Format dialog box, make sure to deselect the Enable Strong Protection option. Leaving it selected will produce a certificate that cannot be used by the SSL Relay service.
-
The password that you are prompted for will be used later when configuring the Relay service. Make sure that you don't forget it.
-
Finally, assign a name to the export file.
-
After exporting the file, there is one more step left to perform. This involves converting the exported file into a PEM file that the SSL Relay service can understand. This is done by using the KEYTOPEM command-line tool that is located in the %SystemRoot%\SSLRelay directory on the MetaFrame server. In my example, I would run the following command:
keytopem medusa.pfx
The resulting file would be called medusa.pem. -
The last step is to copy the PEM file into the %SystemRoot%\SSLRelay\certs directory.
){kind=link}
){kind=link}
The newly created certificate
The certificate is now ready to be used by the SSL service.
Adding the CA to the Web Server's Trust List
By default, NFuse includes support for Verisign Inc. and Baltimore Technologies certificate authorities. If you are using an alternate CA, you will need to add the root certificate to the cacerts folder under keystore on the NFuse-enabled Web server, not the MetaFrame server. This is located under %SystemRoot% on a Windows Web server. The certificate should be in DER format, not Base-64 encoding.
SSL Relay Configuration Utility
The final step in configuring the SSL Relay service itself is to run the Citrix SSL Relay Configuration Utility on the appropriate MetaFrame server. When it first opens, the tool retrieves the list of all certificates in the %SystemRoot%\SSLRelay\keystore directory and lists them in the Server Certificate drop-down list box (see Figure 8). The certificate that you created earlier should be listed. Select the certificate name, and then enter the password that was provided in step 13 when exporting the certificate. Click Apply to verify that the password is correct, and assign the certificate to the SSL Relay service. Normally you will not need to modify any of the other options within this utility.
){kind=link}
Selecting the server certificate for the SSL Relay service
When exiting the utility, you will be asked if you want to start the service. Normally, I select No until I am certain that the Relay is configured properly. Instead, I typically start the Relay from a command prompt so that I can monitor the output from the service.
You can run the SSL Relay from a command prompt by going into the %SystemRoot%\SSLRelay directory and running SSLServerRelay. If you have configured the certificate properly, you should see text similar to the following appear:
******************************************** Citrix SSL Relay Version 1.00 Copyright (c)1999-2000 Citrix Systems, Inc. All rights reserved. Copyright (c)1986-2000 RSA Security, Inc. All rights reserved. ******************************************** 12/3/2000 3:19:58 PM: Negotiating with Service Control Manager, please wait....... 12/3/2000 3:19:58 PM: Using SSL provider Citrix SSL interface v1.04 12/3/2000 3:19:59 PM: Waiting for incoming connections.
If you receive an error, it typically is because the certificate is invalid. You will need to repeat the certificate creation, ensuring that you are providing the proper password and exporting the private keys.
Configuring the Web Site to Use SSL Relay
After the SSL Relay service has been configured, the last thing that needs to be done is to configure the NFuse Web site to communicate with the Relay instead of directly with the XML service. There are two ways that you can do this:
-
Use the Web Site Wizard, and select Enable SSL on the second page. You must specify a server and a port. The default relay port is 443.
-
You can also modify an existing Web site to use SSL. I modified my existing ASP-based Web site by making the following two changes to the existing scripts:
- First in applist.asp, I replaced this line
gateway.initialize credentials
- with this one:
gateway.initialize credentials, “MEDUSA”, 443, “Ssl”, 0
if parser.Parse() = False then
parser.setSingleSessionField "NFuse_RelayServer", "MEDUSA" parser.setSingleSessionField "NFuse_RelayServerPort", "443" parser.setSingleSessionField "NFuse_Transport", "Ssl"
At this point, you are ready to test the SSL Relay communications. Simply point a client's browser at the Web site and perform a standard logon. You will be able to verify that the Relay communications are being performed if you see text similar to the following appear in the SSLServerRelay command prompt window on the Terminal Server.
******************************************** Citrix SSL Relay Version 1.00 Copyright (c)1999-2000 Citrix Systems, Inc. All rights reserved. Copyright (c)1986-2000 RSA Security, Inc. All rights reserved. ******************************************** 12/3/2000 4:19:06 PM: Negotiating with Service Control Manager, please wait....... 12/3/2000 4:19:06 PM: Using SSL provider Citrix SSL interface v1.04 12/3/2000 4:19:07 PM: Waiting for incoming connections. 12/3/2000 4:45:49 PM: Accepting connection from 10.10.75.210 12/3/2000 4:45:50 PM: Client requested connection to 10.10.75.100:80
The second-to-last line corresponds to the Web server initiating the request to the SSL Relay service. The last line is the SSL Relay service passing communications through to the XML service. In this case, 10.10.75.100 corresponds to the MEDUSA MetaFrame server on which the SSL Relay service is running.
If instead of the user's application list you see an error page similar to the following, then you most likely have an issue with the certificate, the CA trust, or the current time on the Web server:
"There was an error generating the app list."
"There was an error attempting to make a connection with the Citrix Relay Server. The name of the server to which the connection was attempted is MEDUSA. The port number to which the connection was attempted is 443. Please ensure that there is a Citrix Relay Server installed on the machine with that address and that it is listening on that port. Also ensure that the name contained in the server certificate that the Citrix Relay Server is configured to present matches exactly the name of the server to which the connection was attempted."
The first thing to try is to move the date on the Web server ahead by one day and attempt to reconnect to the NFuse Web site. In most situations, if you have created the certificate properly, this will fix the problem. When the certificate is created, it has a Valid After date assigned that corresponds to the current system date in Greenwich Mean Time (GMT). The NFuse component on the Web server does not take the current time zone into consideration when checking the validity of the certificate and, as a result, may think that the certificate has a “Valid After” date that is set in the future.
For example, if you created the certificate at “10/25/00 14:00 EST (Eastern Standard Time),” then the certificate is actually assigned a “Valid After” time of “10/25/00 19:00 GMT.” When this certificate is presented to the Web server, it thinks that the date of “10/25/00 19:00” is EST, not GMT. If the current time on the Web server is less than 19:00, then it will consider the certificate to be invalid. Once the time on the Web server has actually passed 19:00 EST, then the certificate will be considered valid and will be properly accepted.
If future-dating the Web server does not resolve the problem, then you should go back and review the exact steps taken to create the certificate, ensuring that you have assigned the host name properly and that the CA certificate has been placed on the keystore folder on the Web server.