End-To-End Encryption with XenApp and XenDesktop

White Paper

citrix.com

End-To-End

Encryption with

XenApp and

XenDesktop

Security guidance for Citrix Deployments

White Paper

citrix.com 2

End-To-End Encryption with XenApp and XenDesktop

Table of Contents

Introduction 3

Data in transit – encryption and the TLS protocol 4

Protecting encryption keys 8

Encryption policies and standards 9

Regulated use of encryption 11

End-to-end encryption with XenApp and XenDesktop 12

Planning ahead: The future of end-to-end encryption 20

The cloud today: Considerations for end-to-end encryption 21

Internet of Things: End-to-end encryption 21

Summary: Effective use of end-to-end encryption 22

References 23

Contributors 23

White Paper

citrix.com 3

End-To-End Encryption with XenApp and XenDesktop

Protecting sensitive data often requires end-to-end encryption,

meaning that data is encrypted from the point of service to

the nal point of termination, with no intervening decryption.

This is in response to trends that include regulatory compliance,

privacy legislation, contractual policies and vulnerability

mitigations. These trends mean that many organizations need

urgently to migrate to the use of TLS 1.2, and to manage cipher

suites closely.

This white paper describes when and where to implement encryption, how to select encryption

protocol options, and explains where to nd detailed conguration guidance for the

components of Citrix XenApp, XenDesktop, and NetScaler Gateway. It also discusses encryption

in the cloud and in the Internet of Things, and the future direction of cryptography.

Most organizations now do not attempt to retain full control over use of corporate networks,

as these networks often extend beyond organizational and management boundaries. Instead,

they segment networks according to use cases and security levels (for example, segmenting

less-trusted wireless networks available to visitors from more-trusted datacenter networks).

Meanwhile, organizations have also realized that the insider threat is greater than previously

believed. These threats can be perpetuated by malicious insiders, honest mistakes, and

miscongurations. Staff who are tricked by spear-phishing attacks, and “trusted” network

devices already compromised by external attacks clearly illustrate an insider threat that

simulates—but does not require—a rogue individual. Attackers are motivated to attack

corporate networks not just to obtain corporate assets, but also personal data that can

be used against individuals for identity theft or spear phishing.

The combination of disruptive forces—motivated insider threats on less trusted networks—means

that data must be protected by end-to-end encryption not just when crossing the Internet, but

also when traversing corporate networks. This is reected in recent regulatory requirements,

including updates to the PCI Data Security Standard. With end-to-end encryption, data is

protected throughout the data lifecycle, including data at rest, data in transit, and data in use.

However, blanket use of end-to-end encryption is not always an effective approach, due in part

to needs for content inspections, logging, and trafc management. This white paper explains a

prescribed use of end-to-end encryption with XenApp and XenDesktop, with specic details for

conguring the Transport Layer Security (TLS) protocol.

This white paper builds on the guidance in the white paper “Getting Started with Citrix XenApp

and XenDesktop Security” white paper, including the representative deployment described

there. This paper is designed to meet the needs of security specialists, systems integrators,

and consultants designing, deploying, and securing Citrix deployments.

SSL and TLS

The TLS (Transport Layer Security)

protocol has superseded SSL.

Although many products support

both SSL and TLS, and the term

“SSL” is often used to describe

both, the difference between

SSL and TLS is crucial.

Use TLS. SSL is no longer secure.

White Paper

citrix.com 4

End-To-End Encryption with XenApp and XenDesktop

Data in transit – encryption and the TLS protocol

The TLS protocol has evolved steadily since its origins in the Secure Sockets Layer (SSL) protocol

in 1995. (TLS and SSL are still informally known as SSL.)

This section describes in detail the cryptography used by TLS, the options available, and how

to select between them. This detail is important, because organizations may need to select

less-secure options for compatibility with earlier operating systems, or temporarily while

upgrading components.

Successive versions of the protocol:

• Correct security weaknesses in earlier versions

• Add support for new cryptography

• Add new protocol features

Cryptography in the TLS protocol

Cryptography in the TLS protocol is selected by a TLS cipher suite, which is negotiated between

the client and server. This denes the cryptographic algorithms that are used for the connection.

Some versions of the TLS protocol permit cryptographic algorithms that are now considered

weak, and should not be used. (However, not all usages of these algorithms within the TLS

protocol are insecure—it depends on the context.) Insecure usage can be prevented by

disabling the corresponding cipher suites. Many Citrix products automatically prevent use

of insecure cipher suites, or disable them by default.

Your organizational policy may require specic cipher suites, and this may be determined

by regulations, as explained later.

Cipher suites are named in the form TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384. This

can be interpreted as follows:

• TLS is the protocol (Transport Layer Security)

• ECDHE_RSA is the key exchange algorithm (Elliptic Curve Dife-Hellman)

• AES_256_CBC is the cipher (Advanced Encryption Standard, Cipher Block Chaining)

• SHA384 is the (MAC) message authentication code (Secure Hash Algorithm)

Examining the key exchange algorithm, ECDHE indicates that this cipher suite offers forward

security. RSA indicates that a RSA digital certicate must be used.

Examining the cipher, AES_256_CBC indicates that this cipher suite uses a 256-bit key in

CBC mode.

Examining the MAC, SHA384 indicates that this cipher suite uses the HMAC-SHA386 algorithm.

White Paper

citrix.com 5

End-To-End Encryption with XenApp and XenDesktop

The cipher suite does not identify the version of the TLS protocol and many cipher suites are

common to different TLS versions.

Note: The naming scheme above is the one from the TLS standards. Some implementations,

including OpenSSL and Citrix NetScaler, use a slightly different naming scheme for historical

reasons. (For example, TLS1.2-ECDHE-RSA-AES-256-CBC-SHA384 corresponds to

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.)

Strong and weak cipher suites

In this context, a weak cipher suite is one that can be attacked successfully now or projected in

the next few years. (An attack may be difcult, but is at least possible.) Advances in technology,

tools and techniques may weaken ciphers well before their initially projected lifespan and

the known strength of ciphers should be periodically veried through NIST and other

trusted sources.

Cipher suites containing the following algorithms are generally considered weak:

• DES (although 3DES—also known as TripleDES or TDEA—is not generally considered weak)

• RC2

• RC4

Additionally, the so-called ‘export’ or ‘step-down’ cipher suites are weak. These cipher suites limit

the length of the signing key to 512 bits, which can be broken by brute force. These weak ‘export’

cipher suites were devised to satisfy export considerations that have not applied for many years.

Strong cipher suites can and should be used instead.

Hashing algorithms including the SHA1 and MD5 are also considered weak for signatures in

digital certicates, with SHA-256 being specied as the minimum standard. The usage of

previous algorithms is so weak that public certicate authorities will no longer issue certicates

that use them. Digital certicates using MD5 or SHA1 should be replaced. Some platforms,

including Microsoft Windows, are already preventing their use.

In summary, for TLS today, the following are considered weak:

Algorithm In certicates In ciphersuites

DES – Weak

RC2 – Weak

RC4 – Weak

3DES (TDEA) – Not weak

MD2 Weak –

MD5 Weak Not weak, but avoid

SHA1 Weak Not weak

HMAC functions

In cipher suites, MD5 and

SHA1 algorithms are used as

HMAC-MD5 and HMAC-SHA1

message authentication codes.

These HMAC constructions are

not considered weak.

However, some regulations

do not permit the use of MD5

for any purpose. Therefore it is

recommended that MD5 cipher

suites are avoided. SHA1 cipher

suites are not affected.

(MD5 and SHA1 used for

signatures in digital certicates

are weak.)

White Paper

citrix.com 6

End-To-End Encryption with XenApp and XenDesktop

Preferred cipher suites

AES is a block cipher: every block cipher is used in a particular mode of operation. Three of these

modes have been standardized within TLS, as part of the cipher denition:

• AES-CBC (Cipher Block Chaining)

• AES-CCM (Counter with Cipher Block Chaining-Message Authentication Code). This mode is

rarely used.

• AES-GCM (Galois Counter Mode)

The CBC mode is more widely supported than GCM, including in TLS version 1.0 and version 1.1.

The GCM mode is often preferred to CBC mode, because:

• It is higher-performance

• It is resistant to side-channel attacks, specically padding oracle attacks such as Lucky Thirteen.

(However, such attacks against CBC mode can be mitigated in other ways.)

• It is resistant to adaptive plaintext attacks, specically the BEAST (Browser Exploit Against

SSL/TLS) attack. (Again, this attack against CBC mode is mitigated in version TLS 1.1 or in

other ways.)

Some authorities prefer GCM: others nevertheless still prefer CBC.

Unnecessary cipher suites

You only need to enable cipher suites that match the type of digital certicate you have

installed—that is, which match the key exchange algorithm. For example, assuming you are

using an RSA certicate, disable cipher suites that use ECDSA or DSS.

There are also cipher suites that do not use digital certicates. These are intended for special

purposes that are outside the scope of this white paper. The usage of these should be

explicitly disabled.

There are also cipher suites that do not encrypt at all. These are also intended for special

purposes that are outside the scope of this white paper. The usage of these should be

explicitly disabled.

The TLS standards also reference the following algorithms which are not widely supported or

used: IDEA, Camellia, ARIA, GOST 28147-89. The usage of these should be explicitly disabled,

unless needed for an exceptional case.

Note: This is not an exhaustive list of cipher suites to avoid.

Because of the large number of cipher suites, many of which are weak or not useful, it is by far

safest only to enable the cipher suites that are actually needed. For most deployments, a handful

will sufce. Ensure that all clients, including browsers, support the restricted set of cipher suites

and test for proper operation as a key component of any client-side upgrade planning process.

White Paper

citrix.com 7

End-To-End Encryption with XenApp and XenDesktop

Planning for the future

TLS version 1.3 will introduce newer cryptography, which is explained below. TLS version 1.3 also

removes many aging cipher suites. Minimizing cipher suite usage will also simplify your future

upgrade to TLS version 1.3.

Versions of the protocol

Different versions of the protocol do not interoperate; so that an SSL version 3 client cannot

communicate with a TLS version 1.2 server, for example. Clients and servers typically implement

several versions of the protocol to avoid overall interoperability problems.

However, there is a risk in clients and servers that support more than one version of the protocol.

Recently, a set of ‘cross-protocol’ attacks have been found. One of these affects a client which

supports SSL version 2, even when it is using TLS version 1.2. It is therefore important to disable,

both on the client side and server side, versions of SSL and TLS protocols that are not required.

For example, if only TLS version 1.2 is required, congure both clients and servers to support TLS

version 1.2 only. This type of precaution will still be needed in the future, as newer versions

replace older versions. Consult documentation for the corresponding Citrix components.

SSL – the predecessor to TLS

Both SSL version 2 and version 3 have security weaknesses, and should no longer be used. Both

are ofcially deprecated by the IETF. If you have systems and applications that still rely on SSL

version 2 and version 3, plan their migration to TLS version 1.2 immediately.

At this time, some Citrix products continue to support SSL version 3 for existing deployments.

Support for SSL version 3 is being phased out.

TLS 1.0

TLS 1.0 is widely supported, including in Citrix products. TLS 1.0 is vulnerable to the BEAST

(Browser Exploit Against SSL/TLS) attack, but this attack can be mitigated independently of TLS.

TLS 1.0 is not recommended for new deployments, and some regulations (for example, PCI DSS

3.2) do not permit TLS 1.0 for new deployments.

TLS 1.1

TLS 1.1 is less widely supported, because it was quickly succeeded by TLS 1.2. It does not support

newer cryptography, so TLS 1.2 is usually preferred. TLS 1.1 and later versions are not vulnerable

to the BEAST attack.

TLS 1.2

TLS 1.2 is the preferred version for current deployments. It added cipher suites for newer

cryptography (in particular, for SHA256 and SHA384 and for GCM mode). It is recommended

or required by various regulations.

White Paper

citrix.com 8

End-To-End Encryption with XenApp and XenDesktop

TLS 1.3 – the future

TLS 1.3 is currently under development. Unlike earlier versions of TLS, it removes many algorithms

and little-used protocol features in the interest of security. It also introduces new cipher suites

for extra cryptographic algorithms that are not supported in TLS 1.2 (including new elliptic curves

ED25519 and ED488).

TLS and DTLS

Network protocols are of two kinds: connection-oriented (based on TCP) and connectionless

(based on UDP). TLS is used with TCP; DTLS is used with UDP.

UDP-based protocols are often used for applications that are designed to cope with trafc loss,

typically high-performance media streaming applications that deal with dropped frames but do

not tolerate delays. DTLS allows for trafc loss, but TLS does not.

DTLS is a close derivative of TLS. It provides end-to-end encryption using the same digital

certicates and cipher suites, but the DTLS protocol has a different handshake mechanism.

Somewhat confusingly, DTLS 1.0 is equivalent to TLS 1.1, and DTLS 1.2 is equivalent to TLS 1.2.

DTLS is not as widely deployed and supported as TLS. This is partly because UDP-based protocols

are more difcult to cross rewalls, and partly because UDP-based protocols are less widely used.

Organizational policies may not cover the need for DTLS, or may not distinguish between TLS

and DTLS.

Citrix has supported TLS for many years, and has introduced DTLS support to Citrix Receiver and

NetScaler Gateway to support Citrix FrameHawk technology and UDP audio. Contact your Citrix

representative if you have specic needs for DTLS support.

Protecting encryption keys

Encryption is only as strong as the keys it uses. In TLS, the main keys to be protected are the

private keys for digital certicates.

Private keys should never leave the machine. Ideally, they should be even more tightly conned,

with keys generated and stored within security hardware. For a client certicate, this is typically

within a smartcard. For a server certicate, this is within a hardware security module (HSM).

Consult NetScaler Gateway documentation for HSM options.

Private keys used for signing, as in TLS, should also never be imported or exported. However,

there are reasons why this is sometimes done:

• To si m pl if y c e rt i c at e i s su an c e: th e p ri v at e ke y i s g en e ra t ed el se w he re a n d i ts d i gi t al ce rt i c a te

is issued; both are then imported to the machine—avoid doing this. Generate the private key

on the machine itself.

• For backup purposes: the private key and its digital certicate are exported, so a replacement

machine can be made available when needed- avoid doing this. Have a replacement machine

ready with a separate private key and digital certicate ready.

White Paper

citrix.com 9

End-To-End Encryption with XenApp and XenDesktop

• For replicas: the private key and its digital certicate are exported to all replica machines. This

requires a special-purpose export mechanism so that the private key is only made available to

replica machines and no others. Consult NetScaler Gateway documentation for high-

availability options.

• For machines that share a certicate (which may be a wildcard certicate or not): the private key

and its digital certicate are exported to all sharing machines. These machines may not be true

replicas. Again, this should use a special-purpose export mechanism so that the private key is

only made available to machines which match that certicate.

• For stateless virtual machines: these require a specic solution, as they cannot store a private

key persistently because they reset automatically when turned off. See below for a solution for

XenApp and XenDesktop virtual desktops.

Encryption policies and standards

Organizations need to select encryption policies and standards to match business needs. These

policies and standards should then be enforced consistently, using appropriate technology.

Applying consistent policies

With end-to-end encryption, data is protected throughout the data lifecycle, including data at

rest, data in transit, and data in use. Consistent protection is required throughout the data

lifecycle; for example, to avoid strong protection for data at rest being weakened when in transit.

This means applying consistent policies for encryption algorithms, encryption key lengths, and so

on, wherever encryption is used.

This white paper focuses on encryption for data in transit, as supported by XenApp, XenDesktop,

and NetScaler Gateway. For encryption of data at rest on mobile devices, consult Citrix

XenMobile documentation.

Encryption for data in use is ultimately determined by application and data-level services (for

example, a database application or a mobile container). Citrix ShareFile provides managed

mobile container solutions, as part of the ShareFile app. Consult documentation specic to

individual applications for detailed information on application-level encryption.

Data in transit: End-to-end and hop-by-hop encryption

For data in transit protection of virtual applications and desktops, there are two basic

approaches; true end-to-end encryption, and hop-by-hop encryption.

Hop-by-hop encryption

True end-to-end encryption

White Paper

citrix.com 10

End-To-End Encryption with XenApp and XenDesktop

With true end-to-end encryption, data is encrypted in transit from its ultimate source (for

example, a client device) to its ultimate destination (for example, a database). This method is

seen in encryption from point-of-swipe for credit card transactions. The advantage of true end-

to-end encryption is that the data can be protected for condentiality, integrity and availability

everywhere. However, this is not always necessary or desirable. Connections often need to pass

through rewalls, gateways, and proxy servers, which cannot inspect true end-to-end encrypted

trafc. True end-to-end encryption also means that the client must know the true ultimate

destination, which gateway proxy servers are intended to conceal.

Therefore, hop-by-hop encryption is often used. This is better suited to the TLS and IPSec

protocols, which are generally deployed in hop-by-hop congurations. This means that data is

protected when “on the wire”; however, with hop-by-hop encryption the data is not encrypted at

the rewall, gateway, or proxy server itself.

Encryption policies do not usually distinguish between true end-to-end and hop-by-hop

encryption. So, in the rest of this white paper, the term end-to-encryption covers both true end-

to-end and hop-by-hop encryption. Implementation-specic details for systems and services

intervening in end-to-end encryption will be supplemented with guidance.

Data classication and encryption

Your organization should have a data classication policy. This policy should take into account

your organization’s regulatory, governance and contractual commitments that drive the need for,

and specication of, encryption.

Many organizations have three data classications: public data, private data internal to the

organization, and sensitive private data available only for specic groups of people. These

classications may be extended to cover customer information, and personally identiable

information in accordance with laws and regulations. The data classication policy should specify

which data is to be kept condential, as well as management needs for integrity and availability.

Public data need not be encrypted, by denition. Sensitive private data may well need to be

encrypted. The data classication policy may not itself specify whether encryption is to be used;

this may be detailed in other more specic organizational policies.

What to encrypt, and not to encrypt

Encryption should be used only when necessary, because:

• Encryption has a cost—for example, the operational cost in purchasing and managing digital

certicates, and the performance overhead of encryption (however small)

• There are legal and regulatory restrictions on the use of encryption

• Encrypted data cannot easily be scanned, for example to check for viruses or undesired content

Not all data needs to be kept condential (and therefore encrypted), whether at rest, in transit,

or in use.

White Paper

citrix.com 11

End-To-End Encryption with XenApp and XenDesktop

Your organization’s data classication policy should be a starting point for determining the

need for end-to-end encryption. However, some policies only cover application data (such as

documents and databases), but not system data (such as credentials and keys). Credentials and

private or secret keys must always be encrypted.

Administrative trafc (for example, between an administrative console and the server it controls)

should always be encrypted. In some cases, trafc is automatically encrypted, and therefore does

not require independent encryption. Where relevant, this is noted later in this white paper.

Regulated use of encryption

Over the years, encryption regulations have been simplied. Regulations still apply to national

and international use, and to specic sectors.

National and international regulation

Encryption is subject to international regulation, for export. Some countries also regulate the

import or use of encryption. This is separate from any industry–specic regulation in the nancial

services, telecommunications, or other sector.

Citrix publishes export information for Citrix products on the Citrix website (see References

section of this paper for further details). For information about importing Citrix products please

contact your Citrix representative.

Citrix cannot provide country-specic advice about the use of encryption. This includes

deployments that span more than one country. Please contact your legal advisers for further

guidance.

Sector-specic regulation

Organizations in the government, healthcare, energy, and nancial services sectors are likely to

be required to use encryption according to specic policies. These policies typically specify the

use of particular encryption algorithms and key lengths. These implementation considerations

are discussed in detail below, in the context of TLS.

Cryptographic validation – FIPS 140

Some sectors not only require use of particular cryptography, but also require that the

implementation is independently validated. This is typical of government systems.

The U.S. Government requires that cryptography in Federal systems has been validated under the

FIPS 140 validation program. Implementation of FIPS 140 is specied by levels that may include a

hardware security module (HSM) for key protection. For details of cryptographic validation for

XenApp and XenDesktop and its components, see the References section of this paper.

White Paper

citrix.com 12

End-To-End Encryption with XenApp and XenDesktop

End-to-end encryption with XenApp and XenDesktop

This applies to XenApp and XenDesktop 7.6 and later.

Refer to “Payment Card Industry and Citrix XenApp and XenDesktop Deployment Scenarios”

documentation to understand how these types of deployments help satisfy the Payment Card

Industry Data Security Standard (PCI DSS).

Representative XenApp and XenDesktop conguration

As explained in “Getting Started with Citrix XenApp and XenDesktop Security” white paper, the

conguration below provides remote access with end-to-encryption using TLS 1.2. This is the

simplest layered conguration for remote access. The conguration shows which components

are installed on different computers. The rewalls in this conguration should be congured to

isolate the back-end components (StoreFront, Delivery Controller, and VDA) from other networks.

(Refer to the “Getting Started with Citrix XenApp and XenDesktop Security” white paper for

component requirements, including necessary versions of components.)

RKey: Root Certiﬁcate S Server Certiﬁcate

Delivery Controller

Database Server

XML

Service

Secure

Ticket

Authority

VDA

Firewall Firewall

User device

Web

Browser

Citrix

Receiver

NetScaler Gateway

NetScaler

Gateway

S R

StoreFront

S R

HTTPS

Port 443

TLS 1.2

Port 443

TLS 1.2

Port 443

TLS 1.2

Port 443

TLS 1.2 Port 443

TLS 1.2

Port 443

TLS 1.2 Port 443

This white paper provides general guidance for TLS conguration for each of the link (hops) in

this diagram. For step-by-step instructions, refer to product documentation for the version of

the component involved.

White Paper

citrix.com 13

End-To-End Encryption with XenApp and XenDesktop

Each link is administered differently, but has common guidance that covers:

• Preventing unencrypted communication

• Enforcing TLS 1.2

• Selecting ciphersuites

• Deploying digital certicates

In some cases, conguration is recommended at both ends of the link, and this needs to be

congured separately.

Similarly, where a component has more than one link (for example, StoreFront as shown above),

in general these links need to be congured separately. These conguration steps can be

combined, but for clarity are explained separately below.

Where possible, consider using Microsoft Group Policy to automate conguration across these

components. Updates to Microsoft Windows (including as part of the automatic Windows

Update process) have previously included changes to Microsoft-supported ciphersuites.

Questions about these changes should be directed to Microsoft Corporation.

If a FIPS conguration is required, also refer to “Citrix XenApp 7.6 and XenDesktop 7.6 FIPS 140-2

Sample Deployments” documentation. This affects all components of the deployment.

Note: Specic versions of components may be required.

As shown in the diagram above, all TLS communication uses the standard TCP port 443. Refer

to Citrix product documentation for use of different port numbers for TLS and other protocols;

corresponding changes to network rewalls and operating system rewalls will be needed. This

type of conguration is not generally recommended, but may be necessary if other applications

or services are using the standard ports.

User device to NetScaler Gateway

This section describes TLS conguration for the link between the user device and

NetScaler Gateway.

NetScaler Gatewa

Firewall

Deploying digital certicates

Automate this process for all

components if you can. You will

need different procedures for

Windows and non-Windows

components, and for public and

non-public certicates.

Do not use default certicates

in a production deployment.

White Paper

citrix.com 14

End-To-End Encryption with XenApp and XenDesktop

To prevent unencrypted communications, congure NetScaler Gateway to enforce TLS only,

disabling all other protocols, such as telnet, FTP, and HTTP. Additionally, conrm that the external

rewall has been congured so that NetScaler Gateway cannot be bypassed.

To e n fo rc e T LS 1. 2, co n g ur e Ne t Sc a le r G at e wa y v S er ve r t o e na b le on l y th e T L S 1. 2 p ro to c ol ,

and disable all others. Additionally, on each user device, congure Citrix Receiver, the web

browser (if used) and the underlying operating system to enable only the TLS 1.2 protocol.

Refer to Citrix Receiver documentation.

To select ciphersuites, congure NetScaler Gateway vServer to enable only the required

ciphersuites, and disable all others. Additionally, on each user device, congure Citrix Receiver,

the web browser (if used) and the underlying operating system to enable only the required

ciphersuites. Refer to Citrix Receiver documentation.

To deploy digital certicates, refer to NetScaler product documentation. NetScaler Gateway is

Internet-facing. Its server certicate should be obtained from a suitable public certication

authority (CA), according to your organization’s security policy.

NetScaler Gateway to StoreFront

This section describes TLS conguration for the link between NetScaler Gateway and StoreFront.

Note: There are connections in both directions.

Firewall

StoreFrontNetScaler Gateway

Communication between NetScaler Gateway and StoreFront involves two TLS connections:

one from NetScaler Gateway to StoreFront, and another from StoreFront to NetScaler

Gateway. The connection from StoreFront to NetScaler is required for SmartAccess usage, and

recommended for all congurations; it is congured via the Callback URL in the Authentication

Settings of StoreFront.

To prevent unencrypted communications, congure Microsoft IIS on the StoreFront server to

disable HTTP binding. Additionally, conrm that the internal rewall has been congured so

that StoreFront cannot be bypassed.

White Paper

citrix.com 15

End-To-End Encryption with XenApp and XenDesktop

To enforce TLS 1.2, at StoreFront (the TLS server) use Microsoft Group Policy, PowerShell cmdlet,

or registry conguration tools to congure the Microsoft Schannel provider.

Note: This conguration will affect all other usage of Microsoft Schannel on this computer.

To s e le c t ci p he r su i te s, at St or eF ro n t ( t he T L S s er ve r ) u se Mi cr os of t G ro up Po l ic y, Po w er S he ll

cmdlet, or registry conguration tools to congure the Microsoft Schannel provider.

Note: This conguration will affect all other usage of Microsoft Schannel on this computer.

To deploy digital certicates, follow Microsoft procedures to obtain, install, and congure a TLS

server certicate on StoreFront according to your organization’s security policy. Also install the

corresponding root certicate on NetScaler Gateway. For SmartAccess usage (which requires

conguring the Callback URL as explained above), install the root certicate corresponding to

NetScaler Gateway on StoreFront.

NetScaler Gateway to Delivery Controller

This section describes TLS conguration for the link between NetScaler Gateway and

Delivery Controller.

Firewall

Delivery Controller

NetScaler Gateway

To prevent unencrypted communications, congure Delivery Controller to enforce use of HTTPS

only. (This requires setting a registry value on the Delivery Controller.)

To enforce TLS 1.2, use Microsoft Group Policy, PowerShell cmdlet, or registry conguration tools

to congure the Microsoft Schannel provider on the Delivery Controller.

Note: This conguration will affect all other usage of Microsoft Schannel on this computer.

To select ciphersuites, use Microsoft Group Policy, PowerShell cmdlet, or registry conguration

tools to congure the Microsoft Schannel provider. To enforce selection of a particular

ciphersuite, it may also be necessary to alter the priority order of ciphersuites in this

conguration.

White Paper

citrix.com 16

End-To-End Encryption with XenApp and XenDesktop

Note: This conguration will affect all other usage of Microsoft Schannel on these computers.

To deploy digital certicates, follow Microsoft procedures to obtain, install, and congure a TLS

server certicate on the Delivery Controller according to your organization’s security policy. Also

install the corresponding root certicate on NetScaler Gateway.

Note: Microsoft IIS can be installed on the Delivery Controller, but Delivery Controller does

not require it.

StoreFront to Delivery Controller

This section describes TLS conguration for the link between the StoreFront and

Delivery Controller.

Delivery Controller

StoreFront

To prevent unencrypted communications, congure StoreFront and edit the Delivery Controller

conguration to select Transport type HTTPS. Additionally, congure Delivery Controller to

enforce use of HTTPS only. (This requires setting a registry value on the Delivery Controller.)

To enforce TLS 1.2, use Microsoft Group Policy, PowerShell cmdlet, or registry conguration tools

to congure the Microsoft Schannel provider. Apply this conguration both to StoreFront (the

TLS client) and the Delivery Controller (the TLS server).

Note: This conguration will affect all other usage of Microsoft Schannel on these computers.

To select ciphersuites, use Microsoft Group Policy, PowerShell cmdlet, or registry conguration

tools to congure the Microsoft Schannel provider. Apply this conguration both to StoreFront

and to the Delivery Controller. To enforce selection of a particular ciphersuite, it may also be

necessary to alter the priority order of ciphersuites in this conguration.

Note: This conguration will affect all other usage of Microsoft Schannel on these computers.

To deploy digital certicates, follow Microsoft procedures to obtain, install, and congure a TLS

server certicate on the Delivery Controller according to your organization’s security policy. Also

install the corresponding root certicate on StoreFront.

Note: Microsoft IIS can be installed on the Delivery Controller, but Delivery Controller does

not require it.

White Paper

citrix.com 17

End-To-End Encryption with XenApp and XenDesktop

Delivery Controller to Virtual Delivery Agent (VDA)

This section describes conguration for the link between Delivery Controller and VDA.

WCF

Delivery Controller

Virtual Delivery Agent

HDX

This connection is automatically encrypted using the WCF (Windows Communication

Framework) protocol with Web Services Security Kerberos Token Prole 1.1. Therefore, separate

conguration to use TLS 1.2 is not generally recommended, and is outside the scope of this

white paper.

NetScaler Gateway to Virtual Delivery Agent (VDA)

This section describes TLS conguration for the link between NetScaler Gateway and VDA:

Firewall

NetScaler Gateway

Virtual Delivery Agen

HDX

Special considerations apply to the VDA: If TLS is enabled for one VDA in a Delivery Group,

it must be enabled for all VDAs in a Delivery Group, and so server certicates must be installed

for all of them

Note: The Linux VDA does not support TLS today.

To prevent unencrypted communications, refer to XenApp and Desktop product documentation.

A PowerShell script is provided that prevents unencrypted communications when TLS is enabled

for a VDA.

To enforce TLS 1.2, refer to XenApp and XenDesktop product documentation. A PowerShell script

is provided to select versions of the TLS protocol.

To select ciphersuites, refer to XenApp and XenDesktop product documentation. A PowerShell

script is provided to select sets of ciphersuites.

White Paper

citrix.com 18

End-To-End Encryption with XenApp and XenDesktop

To d e pl o y di g it a l c er ti  ca t es , re f er t o Xe nA p p a nd Xe nD e sk t op p ro d uc t d oc u me nt a ti o n. Fo r

the VDA, the typical approach depends on the machine catalog and the desktop experience,

as follows:

Machine catalog Desktop experience Digital certicate Install/update

Server OS Shared Master image

Desktop OS Pooled random Shared Master image

Desktop OS Pooled static Shared Master image

Desktop OS Dedicated Per machine Auto-enrolment

Remote PC Per machine Auto-enrolment

In summary, for the VDA:

• Non-persistent – If you install the server certicate as part of a master image, the machines

will need to share a certicate (likely a wildcard certicate). This applies to Server OS machine

catalogs, and also to Desktop OS machine catalogs with the Desktop Experience being either

Pooled random or Pooled static. Replace the certicate by updating the master image. (This is the

stateless virtual machine case described above.) Any Machine Management method can be used.

• Persistent – If you install the server certicate via auto-enrolment to Active Directory Certicate

Services (when the machine restarts), each machine can have its own certicate. This applies

to Desktop OS machine catalogs with the Desktop Experience being Dedicated, and also to

Remote PC machine catalogs. Use auto-reenrollment to Active Directory Certicate Services

to replace the certicate when required. A PowerShell script is provided to simplify these

processes at the VDA. Additionally, a scheduled task is required within the master image.

You can also install the certicate via auto-enrolment to Active Directory Certicate Services

for Desktop OS machine catalogs with the Desktop Experience being either Pooled random

or Pooled static. Each machine will then have its own certicate, avoiding the increased risk

of exposure of a wildcard certicate. However, a new certicate will then be installed on every

machine restart. If there is more than one server certicate present on the VDA, the PowerShell

script mentioned above can select the appropriate certicate.

Delivery Controller to SQL Database

This section describes TLS conguration for the link between Delivery Controller and

SQL Database.

Delivery Controller

SQL Server

White Paper

citrix.com 19

End-To-End Encryption with XenApp and XenDesktop

To p re ve n t u ne n cr yp t ed co mm u ni c at i on s, co n g ur e M ic ro s o ft S Q L S er ve r t o f o rc e e n cr yp t io n .

(As explained in Citrix Knowledge Center article CTX1377556, it is also possible to force

encryption at the Delivery Controller, or for each service. However, these alternatives have

no advantage in production environments.)

To enforce TLS 1.2, it may be necessary to install a Microsoft update on Microsoft SQL Server. It is

also necessary to congure registry settings on both Delivery Controller and database server, and

other updates may also be required; refer to Microsoft article 3135244. Updates are available for

SQL Server 2014 SP1, and SQL Server Express 2012 (which is supplied with Desktop Delivery

Controller). Use SQL Server 2014 in a production environment. Microsoft recommends the use of

TLS 1.2 in this conguration.

To select ciphersuites, use Microsoft Group Policy, PowerShell cmdlet, or registry conguration

tools to congure the Microsoft Schannel provider. Apply this conguration both to the Delivery

Controller and to the Microsoft SQL Server. To enforce selection of a particular ciphersuite, it may

also be necessary to alter the priority order of ciphersuites in this conguration.

Note: This conguration will affect all other usage of Microsoft Schannel on these computers.

To deploy digital certicates, follow Microsoft procedures to obtain, install, and congure a TLS

server certicate on the Microsoft SQL Server. Also install the corresponding root certicate on

the Delivery Controller.

Additional steps may be needed, depending on which Microsoft SQL Server high availability

solution is selected for the Delivery Controller.