SSL and TLS under Citrix


In  Citrix  environments the theme security is always considered a top priority. As a matter in fact one of the mottos of the company is “We securely Deliver application and data”

Citrix flagship product: XenApp/XenDesktop focuses on delivering applications and desktops securely as this white paper suggests:

“XenApp keeps sensitive corporate information protected in the data center, but employees still need secure access to the XenApp infrastructure. Applications published using XenApp are accessible through Citrix Receiver™—a lightweight client that can be installed on any type of device,”

Citrix has two backend software packages to handle web authentication: Web Interface (5.4 was the latest and last version available) and StoreFront (3.7 is the latest version as of November 2016)

Web Interface 5.4 — – Is TLS 1.2, 1.1 supported?

No it’s not. Upgrade to StoreFront 3.x.
On page 173 of the product documentation guide for Web Interface 5.4 you will find the following paragraph:

” Transport Layer Security –
Transport Layer Security (TLS) is the latest, standardized version of the SSL protocol. The
Internet Engineering Taskforce (IETF) renamed it TLS when they took over responsibility for
the development of SSL as an open standard. Like SSL, TLS provides server authentication,
encryption of the data stream, and message integrity checks.
Support for TLS Version 1.0 is included in all supported versions of XenApp for Windows and
XenDesktop. Because there are only minor technical differences between SSL Version 3.0
and TLS Version 1.0, the server certificates you use for SSL in your installation also work
with TLS.
Some organizations, including U.S. government organizations, require the use of TLS to
secure data communications. These organizations may also require the use of validated
cryptography, such as Federal Information Processing Standard (FIPS) 140. FIPS is a standard
for cryptography.
Note: The maximum SSL/TLS certificate key size supported by the Web Interface for Java
Application Servers is 2048 bits.”

Here TLS 1.2 or 1.1 is nowhere mentioned, hence upgrade is highly recommended.
Also since WI 5.4 was designed in C# and support for C# has ended by Microsoft nearly two years ago any enhancement request will not be possible

The Wikipedia explanation:

“Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both frequently referred to as “SSL”, are cryptographic protocols that provide communications security over a computer network.[1]Several versions of the protocols find widespread use in applications such as web browsing, email, Internet faxing, instant messaging, and voice-over-IP (VoIP). Websites use TLS to secure all communications between their servers and web browsers.”

Why using TLS and not SSL:

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.

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 defines the cryptographic algorithms that are used for the connection.

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 Diffe-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 certifcate 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.

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 diffcult, 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 verifed 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 certifcates, with SHA-256 being specifed as the minimum standard. The usage of previous algorithms is so weak that public certifcate authorities will no longer issue certifcates that use them. Digital certifcates 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:


source: Citrix White Paper on SSL and TLS

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 defnition: • 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, specifcally 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, specifcally 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

SSL/TLs in XenApp 7.x:

SSL 7.6:

“Configuring a XenApp or XenDesktop Site to use the Secure Sockets Layer (SSL) security protocol includes the following procedures:

  • Obtain, install, and register a server certificate on all Delivery Controllers, and configure a port with the SSL certificate. For details, see Install SSL server certificates on Controllers.

    Optionally, you can change the ports the Controller uses to listen for HTTP and HTTPS traffic.

  • Enable SSL connections between users and Virtual Delivery Agents (VDAs) by completing the following tasks:
    Requirements and considerations:

    • Enabling SSL connections between users and VDAs is valid only for XenApp 7.6 and XenDesktop 7.6 Sites, plus later supported releases.
    • Configure SSL in the Delivery Groups and on the VDAs after you install components, create a Site, create Machine Catalogs, and create Delivery Groups.
    • To configure SSL in the Delivery Groups, you must have permission to change Controller access rules; a Full Administrator has this permission.
    • To configure SSL on the VDAs, you must be a Windows administrator on the machine where the VDA is installed.
    • If you intend to configure SSL on VDAs that have been upgraded from earlier versions, uninstall any SSL relay software on those machines before upgrading them.
    • The PowerShell script configures SSL on static VDAs; it does not configure SSL on pooled VDAs that are provisioned by Machine Creation Services or Provisioning Services, where the machine image resets on each restart.

For tasks that include working in the Windows registry:

Caution: Editing the registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: