Product Documentation

Sample Deployment with Secure Gateway (Single Hop)

May 08, 2015

This deployment uses Secure Gateway in a single-hop configuration to provide TLS/SSL encryption between a secure Internet gateway server and an SSL-enabled plugin, combined with encryption of the HTTP communication between the Web browser and the Web server. Additionally, you can secure ICA traffic within the internal network using IPSec.

This diagram shows sample deployment B, which uses Secure Gateway in a single-hop configuration.


The following table lists the components of the deployment and the operating systems required for the servers and client devices.

  Components Operating systems
XenApp farm

XenApp 6.0 for Microsoft Windows Server 2008 R2

SSL Relay enabled

Secure Ticket Authority installed on XenApp server

Windows Server 2008 R2

Web server Web Interface 5.3 for Internet Information Services

Windows Server 2008 R2

Windows Server 2008

Windows Server 2003 with Service Pack 2

.NET Framework 3.5 or 2.0 (IIS 6.0 only)

Visual J#.NET 2.0 Second Edition

Secure Gateway server Secure Gateway 3.2 for Windows

Windows Server 2008 R2

Windows Server 2008

Windows Server 2003 with Service Pack 2

User devices

Citrix online plug-in for Windows 12.x

TLS-enabled Web browser

Windows 7

Windows Vista

Windows XP Professional

How the Components Interact

Use TLS to secure the connections between client devices and Secure Gateway. To do this, deploy TLS/SSL-enabled plugins and configure Secure Gateway at the network perimeter, typically in a demilitarized zone (DMZ).

Secure the connections between users’ Web browsers and the Web Interface using HTTPS. Additionally, secure communication between the Web Interface and the XenApp servers using TLS.

This diagram shows a detailed view of sample deployment B.1.


In this deployment, Secure Gateway removes the need to publish the address of every XenApp server in the farm and provides a single point of encryption and access to the farm. Secure Gateway does this by providing a gateway that is separate from the XenApp servers and reduces the issues for firewall traversal to a widely accepted port for ICA traffic in and out of the firewalls.

Set against the increased scalability of sample deployment B is the fact that ICA communication is encrypted only between client devices and Secure Gateway. ICA communication between Secure Gateway and the XenApp servers is not encrypted.

Note that the SSL Relay in sample deployment B is used to encrypt communication between the Web Interface and the XML Service running on the XenApp servers. Secure Gateway communicates with the XenApp servers directly, so the SSL Relay is not used for communication between Secure Gateway and the server farm.

To comply with FIPS 140, secure the communication between Secure Gateway and the server farm using IPSec, as shown in sample deployment B.2.

This diagram shows a detailed view of sample deployment B.2, which includes IPSec.


Security Considerations for This Deployment

IPSec in Sample Deployment B

To enable IPSec to secure communication between Secure Gateway and the XenApp server farm, you must configure IPSec on each server, including the Secure Gateway server.

IPSec is configured using the local security settings (IP security policies) for each server. In sample deployment B.2, IPSec is enabled on the requisite servers and the security method is configured for 3DES encryption and SHA-1 integrity to meet FIPS 140 requirements.

FIPS 140 Validation in Sample Deployment B

In this deployment, the SSL Relay uses the Microsoft cryptographic service providers and associated cryptographic algorithms available in the Microsoft Windows CryptoAPI to encrypt and decrypt communication between client devices and servers. For more information about the FIPS 140 validation of the CSPs, see the Microsoft documentation.

For Windows Vista, Windows XP, Windows Server 2008, and Windows Server 2003, TLS/SSL support and the supported ciphersuites can also be controlled using the following Microsoft security option:

System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

For more information, see the documentation for your operating system.

TLS/SSL Support in Sample Deployment B

You can configure Secure Gateway and the Web Interface to use either the Transport Layer Security 1.0 protocol or the Secure Sockets Layer 3.0 protocol. In sample deployment B, the components are configured for TLS.

Supported Ciphersuites for Sample Deployment B

In this deployment, Secure Gateway and the Web Interface can be configured to use government-approved cryptography, such as the ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to protect “sensitive but unclassified” data.

Alternatively, for TLS connections, you can use AES as defined in FIPS 197. The government ciphersuites are RSA_WITH_AES_128_CBC_SHA for 128-bit keys and RSA_WITH_AES_256_CBC_SHA for 256-bit keys. As defined in Internet RFC 3268 http://www.ietf.org/rfc/rfc3268.txt, these ciphersuites use RSA key exchange and AES encryption. For more information about AES, see http://csrc.nist.gov.

Certificates and Certificate Authorities in Sample Deployment B

Citrix products use standard Public Key Infrastructure (PKI) as a framework and trust infrastructure. In sample deployment B, one server certificate is configured on Secure Gateway and one on the Web Interface. A certificate is also configured on each XenApp server.

Smart Card Support in Sample Deployment B

In this deployment, you can configure XenApp to provide smart card authentication. To do this, you must configure authentication with Microsoft Active Directory and use the Microsoft Certificate Authority.

Plug-ins Used in Sample Deployment B

In this deployment, users access their applications using the Citrix plug-in. For more information about the security features and capabilities of Citrix plug-ins, see Receiver and Plug-in Security.