Product Documentation

Network and Authentication Protocols

Sep 15, 2015

You can secure XenApp by using network protocols, ciphersuites, authentication, and authentication methods. You can find information about several security options in this article.

SSL/TLS Protocols

If user devices in your environment communicate with your farm across the Internet, Citrix recommends enabling Secure Sockets Layer (SSL) 3.0 or Transport Layer Security (TLS) 1.0 encryption when you publish a resource. These protocols are collectively referred to SSL/TLS.

Both SSL and TLS are open protocols that provide data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection:
  • SSL is an open, nonproprietary security protocol for TCP/IP connections.
  • TLS, which is also an open standard, is the latest, standardized version of the SSL protocol.

SSL 3.0 and TLS 1.0 are not interoperable. However, because there are only minor differences between them, the server certificates in your installation can be used for both SSL and TLS implementations.

SSL/TLS and FIPS Compliance

When configured properly, deployments using TLS 1.0 can use FIPS 140-validated cryptographic modules in a manner that is compliant with FIPS 140-2; SSL 3.0 is not FIPS compliant. For more information, refer to the Guidelines for the Selection and Use of the Transport Layer Security (TLS) implementations at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf.

Using SSL/TLS with SSL Relay or Secure Gateway

If you want to use SSL/TLS encryption, you must either use the SSL Relay feature or the Secure Gateway or both to relay ICA traffic to the computer running XenApp. For more information, see the information in Installing and Configuring the SSL Relay Tool or XenApp and Secure Gateway.

Deployment samples in the XenApp 6.5 Security Standards documentation include implementations of each. The nature of your environment may determine the way in which you enable SSL:
  • For user devices communicating with your farm remotely, Citrix recommends that you use the Secure Gateway to pass client communications to the computer running XenApp. The Secure Gateway can be used with SSL Relay on the computer running XenApp to secure the Secure Gateway to XenApp traffic, depending on your requirements.
  • For user devices communicating with your farm internally, you can do one of the following to pass client communications to the computer running XenApp:
    • Use the Secure Gateway with an internal firewall and place your farm behind the firewall.
    • Use the SSL Relay feature to secure the traffic between user devices and servers in your farm.
Note:
  • If you use SSL Relay, you must install it on every server in the farm.
  • Because SSL Relay requires you to store certificates on each server, it may be less convenient for larger environments. If your farm has more than five servers and you are concerned with internal threats, you may prefer to use the Secure Gateway with an internal firewall.
  • To use SSL with the Secure Gateway or SSL Relay, you must select the Enable SSL and TLS protocols setting when you publish an application.
  • If you are using Web Interface with the Secure Gateway, see the information about SSL in the Secure Gateway and Web Interface administrator documentation.

Government Ciphersuites

You can configure XenApp, the Web Interface, and Secure Gateway to use government-approved cryptography to protect "sensitive but unclassified" data by using the applicable ciphersuite:

IP Security

IP Security (IPSec) is a set of standard extensions to the Internet Protocol (IP) that provides authenticated and encrypted communications with data integrity and replay protection. IPSec is described in Internet RFC 2401.

IPSec is a network-layer protocol set, so higher level protocols such as Citrix Independent Computing Architecture (ICA) can use it without modification. Microsoft Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2, Windows Server 2008, and Windows Server 2003 have built-in support for IPSec.

Although not illustrated in the sample deployments, you can use IPSec to secure a XenApp deployment within a virtual private network (VPN) environment.

Citrix Single Sign-on

Citrix Single Sign-on increases application security for all XenApp applications, allowing organizations to centralize password management while providing users with fast sign-on access to Web, Windows, and host-based applications.

For more information, see the Citrix Single Sign-on documentation.

Smart Cards

You can use smart cards with XenApp, supported XenApp plug-ins, the Web Interface, and Single Sign-on to provide secure access to applications and data. Using smart cards simplifies the authentication process while enhancing logon security. XenApp supports smart card authentication to published applications, including “smart card-enabled” applications such as Microsoft Outlook.

In a business network, smart cards are an effective implementation of public key technology and can be used for the following purposes:

  • Authenticating users to networks and computers
  • Securing channel communications over a network
  • Securing content using digital signatures

If you are using smart cards for secure network authentication, your users can authenticate to applications and content published on your server farms. In addition, smart card functionality within these published applications is also supported.

For example, a published Microsoft Outlook application can be configured to require that users insert a smart card into a smart card reader attached to the client device in order to log on to a XenApp server. After users are authenticated to the application, they can digitally sign email using certificates stored on their smart cards.

Note: The availability of some smart card features depends on the smart card cryptographic service provider (CSP).

Secure Use of Smart Cards

Your organization may have specific security policies concerning the use of smart cards. These policies may, for example, state how smart cards are issued and how users should safeguard them. Some aspects of these policies may need to be reassessed in a XenApp environment:

  • Tasks performed by smart card administrators (for example smart card issuance) may be inappropriate for carrying out through XenApp. Usually these functions are performed at a dedicated smart card station, and may require two smart card readers.
  • Infrequent and sensitive tasks, such as unblocking a smart card, may also be inappropriate for carrying out through XenApp. Security policies often forbid users to perform these functions; they are carried out by the smart card administrator.
    Note: Citrix recommends that you carry out these tasks locally on the user device if possible, rather than using XenApp.
  • Highly sensitive applications that require strict separation of duties or tamper-resistant audit trails may entail additional special-purpose security control measures. These measures are outside the scope of XenApp.

You can reset PINs from the desktop using Microsoft Identity Lifecycle Manager (ILM) and Certificate Lifecycle Manager (CLM) smart card management systems, or using any smart card vendor's reset utilities that use the Windows smart card PC/SC (WinSCard) API.

Smart Card Support

Citrix supports the use of Personal Computer Smart Card (PC/SC)-based cryptographic smart cards. These cards include support for cryptographic operations such as digital signatures and encryption. Cryptographic cards are designed to allow secure storage of private keys such as those used in Public Key Infrastructure (PKI) security systems. These cards perform the actual cryptographic functions on the smart card itself, meaning that the private key and digital certificates never leave the card. In addition, you can use two-factor authentication for increased security. Instead of merely presenting the smart card (one factor) to conduct a transaction, a user-defined PIN (a second factor) known only to the user, is used to prove that the cardholder is the rightful owner of the smart card.

XenApp supports various smart cards, including the Common Access Card in a deployment that includes the Citrix Receiver for Windows. Contact your Common Access Card vendor or Citrix representative for more information about supported versions of Common Access Card hardware and software.

Citrix continues to test smart cards to address compatibility with XenApp, using certificates from common certificate authorities such as those supported by Microsoft. If you have any concerns regarding your certificate authority and compatibility with XenApp, contact your local Citrix representative.

Kerberos Authentication

Kerberos is an authentication protocol. Version 5 of this protocol was first standardized as Internet RFC 1510. Many operating systems, including Microsoft Windows 2000 and later, support Kerberos as a standard feature.

XenApp extends the use of Kerberos. When users log on to a client device, they can connect to XenApp without needing to authenticate again. The user’s password is not transmitted to XenApp; instead, authentication tokens are exchanged using the Generic Security Services API (GSSAPI), which was first standardized in Internet RFC 1509.

This authentication exchange is performed within a Citrix Independent Computing Architecture (ICA) virtual channel and does not require any additional protocols or ports. The authentication exchange is independent of the logon method, so it can be used with passwords, smart cards, or biometrics.

To use Kerberos authentication with XenApp, both the client and server must be appropriately configured. You can also use Microsoft Active Directory Group Policy to selectively disable Kerberos authentication for specific users and servers.

For information on implementing Kerberos Authentication in a XenApp environment, see Knowledge Center article CTX121918.