Citrix SSL/TLS Vulnerabilities and Operating System Hardening

Brian MurphySenior Information Technology Consultant
Holistic technology infrastructure strategy, design, engineering and implementation that is highly scalable, secure, optimized, automated
#SSL #TLS #Citrix #HTTPS #PKI #Compliance #Certificate #Encryption #StoreFront #Web Interface #Citrix XenApp
Citrix technology runs on Windows client and server operating system. The Citrix Receiver client runs on Windows and non-Windows clients. Users leverage Internet Browsers on those clients to access Citrix platform.

The advent of SSL 2.0 becoming obsolete warrants inspection of client and server cipher suites, protocols, Internet browser versions and combinations.

This article provides recommendations for Microsoft Windows Server and client workstations to meet and exceed current and future requirements as they pertain to certificate encryption technology.

Citrix is inherently secure and yet is dependent on Windows Operating System and others;
1. Website URLs configured as published applications
2. Windows Server Operating System - Windows 2008R2, 2012R2, and future versions
3. Windows Client Operating System - Windows 7, 8, 10 with Citrix Receiver installed
4. Citrix Web Interface and StoreFront
5. Workstation and Citrix XenApp hosted Internet Browsers; Internet Explorer, Mozilla, Google, others
When implemented, the recommendations identify and reduce currently known SSL and TLS vulnerabilities for FREAK []2] and BEAST. These terms are all part of a larger design architecture referred to as Public Key Infrastructure. Some terms used in this article;
SSL = Secure Socket Layer
TLS = Transport Layer Security
HTTPS = Secure Hypertext Transfer Protocol
The focus is on the Microsoft operating systems because Citrix is primarily used on them. Further, client and server operating systems might have Web browsers that may not comply with current cipher suite standards about PKI, the certificate encryption or the process by which HTTPS works. The goal is to remind the reader the vulnerabilities listed here are still prevalent.
The tools and remediation plan discussed is specific to Microsoft Windows 7, 8.1, 10 and Server 2008 R2 or 2012 R2. Most of the vulnerabilities listed exist in latest operating systems and browsers, despite SHA-1 deprecation and disabling SSL 3.0 at the browser level. My preferred tool for Microsoft operating discussed later in this publication.

Citrix XenApp as a hosting platform for business applications often requires Internet access.  Often we publish internal and external URLs to the Internet.  This creates at least four contention points:
  1. XenApp runs on Microsoft Operating System and the OS as built-in protocols, ciphers, hashes and key exchanges.
  2. The client accessing Citrix is Windows or non-Windows and also has built-in protocols, ciphers, hashes and key exchanges
  3. Citrix XenApp can use multiple Internet Browsers and depending on the version of each decrease or increase risk
  4. The client workstations accessing Citrix XenApp can use multiple Internet Browsers and depending on the version of each decrease or increase risk
SSL as a protocol is considered legacy as we begin the migration to the TLS protocol, and this document provides the best combination of all the required aspects of PKI (Public Key Infrastructure) that provide the best encryption strength with the least overhead for SSL processing on Client and Servers. By PKI, I am referring to “certificate encryption” or HTTPS websites. If you browse the Internet, I provide the tools to check your client, browser and the website you wish to browse.
I prefer SSL Labs and SSL Pulse to measure compliance. The ratings are A to F and extrapolated and measured against the top 200,000 websites worldwide. The rating of A is not that hard to achieve as SSL Labs publishes a best practices book. The A rating can still be misleading where insecure renegotiation adds the vulnerability to BEAST, FREAK []2], and POODLE.
Using SSL Pulse, the percentage of this control group using the SSL protocol. This value shows the percentage of the top 200,000 websites (URLs) that allow SSL 2 and 3 despite allowing better protocols such as TLS 1.2. The data below shows about 10 per cent of those sites allow SSL 2 and just over 30 per cent allow SSL 3. So, if your client workstation supports SSL 2 or SSL 3, you might be vulnerable to BEAST, FREAK []2], and POODLE. If your workstation supports only TLS, it is still at risk of BEAST.


First, examine the data as of November 4, 2015.1-IMAGE1.png
Before examination of the operating system, I recommend testing all of your browsers.
So, about twenty thousand websites support SSL 2.0 and sixty thousand support SSL 3.0. How many browsers do you have installed on your client? This exercise is optional but if you wish to test each browser on your workstation or device the steps are below. I used this to test Chrome, Firefox 42 and Internet Explorer 11.



I use SSL Labs free online tool for the client browser check. Open up your browser, type, and click on the “Test Your Browser” link.

The first item, protocol support, tests for TLS 1.2 along with versions 1.0 and 1.1. TLS 1.2, considered the best available, is not an indication of what protocols your operating system supports. For now, supporting TLS 1.2 is enough in that if this fails you are in dire need of upgrading your browser.
Have you wondered what “protocol” version your connection to your banking site is? TLS version 1.2 is deemed best, but this is only the protocol. What about the cipher-suite, the privacy key encryption, the privacy key bit strength, the privacy-key protection during the certificate request (CSR), and the signature algorithm?

Did your browser pass? Next, scroll down to “Protocol Features”.

5-IMAGE5.pngProtocol features checks support for SSL and TLS. I am checking to make sure my browser does NOT support SSL 2 or SSL 3. At the same time, I am checking to make sure it does support TLS 1.2. Regardless of operating system or browser, I would be concerned if my browser supported SSL 2 or SSL 3. I would immediately start looking for an updated browser or change browsers because I know many websites are still vulnerable or use these outdated protocols.
Next, I look at the “Cipher Suites”, especially the order of preference. According to SSL Pulse (Reference), I know that 14 per cent of the 200,000 websites support weak cipher suites.

So, I scroll down further on my browser assessment, and it appears I am good. I have no NULL, or RC4 drivers enabled.
I can look at this and know that with Firefox and my operating system that I should not be vulnerable to FREAK []2], or POODLE. Regardless if the website I am using allows those protocols, I have disabled those protocols and ciphers on my workstation and the version of Firefox I use no longer supports SSL.
Back on my browser report, I scroll up to the FREAK []2] and POODLE section — just to confirm. Notice, it does not list BEAST, only FREAK and POODLE, and shows that this browser (Firefox) is not vulnerable.
When I originally started this exercise, way back when, my browser was vulnerable to both FREAK and POODLE. If you are running the latest “user agent” or browser this should show “not vulnerable”. I use this same process to help customers obtain compliance.


BEAST is a browser or client-side vulnerability. Most major browsers addressed this vulnerability with patches or new versions. TLS 1.0 and earlier (SSL) suffer from a flaw allowing for a man-in-the-middle (MITM) attack.
BEAST is short for Browser Exploit Against SSL/TLS. This vulnerability is an attack against the confidentiality of a HTTPS connection in a negligible amount of time []1].
Supporting TLS 1.1 and 1.2 does not address BEAST exploited by the attack. The first problem is that most of the Internet still relies on TLS 1.0. As of November 04, 2015 89.8 per cent of the top 200,000 websites are vulnerable to BEAST Attack.
9-IMAGE9.pngAm I secure against FREAK []2]?  Yes, based on this report. But how?
On Tuesday, March 2nd 2015, a group of security experts disclosed a finding regarding HTTPS website encryption using SSL Secure Socket Layer or TLS Transport Layer Security with RSA-Export keys and gave it the name “FREAK []2]” short for “Factoring RSA-Export Keys.”
The vulnerability takes advantage of a bug in the crypto libraries of “export cipher suites” and the misconception that those ciphers are no longer utilized. Most of these “export ciphers” remain on many servers, clients, and client Web browsers. The presence of these legacy ciphers allows an attacker to intercept HTTPS connections between vulnerable clients and servers and force them to use weak encryption and manipulate or steal sensitive information. This vulnerability takes advantage of the weaker cipher suites that remain in the operating system allowing for backward compatibility and any “cipher suite” that uses RC4. The key factor is that the vulnerability targets both clients and servers to force lowered encryption.
I used the SSL Labs (NARTAC) client and IISCrypto server tool on Windows 7 Professional to examine the default values then modified all the comparative settings using this same tool. The tool is supported on Windows 10 and Server 2012.
The cipher used is determined during the “negotiation” phase of the “TLS handshake.” A scenario exists where the hosting web server and the Windows server or workstation negotiate and in some cases they do so starting with the least or lowest cipher suite that both the web server (or site) can negotiate. Without going into much detail, I would simply say “consider downloading the free ISCrypto tool” for Windows. Run this on your Windows servers and workstations to reveal what ciphers suites remain enabled. Prepare for a surprise.
Transport Layer Security 1.0 with the RC4 cipher suite is associated with the FREAK []2] vulnerability. Some tools can assist with vulnerability assessment but won’t identify all of them. As of this writing, the published vulnerabilities for SSL 1.0, 2.0, and 3.0 are sufficient to support addressing those vulnerabilities.
I would pay close attention to the cipher order, enabled protocols, hashes, and key exchange. I like this tool because it allows the individual to implement automatically best practices with one button click.
Which best practices? Good question: it uses what it calls SSL Labs “BulletProof SSL and TLS.” I recommend this book for those interested in PKI security or website hardening from the “certificate” perspective.


IIS Crypto is a free tool that gives administrators the ability to enable or disable protocols, ciphers, hashes and key exchange algorithms on Windows Server 2003, 2008 and 2012. It also lets you reorder SSL/TLS cipher suites offered by IIS, and implement best practices with a single click and test your website.


  • Single click to secure your site using best practices
  • Stop FREAK []2], BEAST, and POODLE attacks
  • Easily disable SSL 2.0 and SSL 3.0
  • Enable TLS 1.1 and 1.2
  • Disable other weak protocols and ciphers
  • Enable forward secrecy
  • Reorder cipher suites
  • Templates for compliance with government and industry regulations - FIPS 140-2 and PCI
IIS Crypto requires the .NET Framework version 2.0 or greater. If you are running Windows Server 2012, download the .NET 4.0 version or make sure you have .NET 4.5.2 installed.


Take a first look at the defaults for a Windows 7 workstation. Suffice it to say, I am surprised. I need to fix this "Protocols Enabled" and "Ciphers Enabled".  At a minimum I need to disable PCT 1.0, SSL 2.0, SSL 3.0 and in the Ciphers Enabled all the RC2, RC4, and NULL ciphers in the red box.

11-IMAGE11.pngBefore I do this, I need to inspect the cipher suites.  I scroll down and notice a series of wrong combinations. Another surprise, I have a bad order and many cipher suites in the order that should be disabled.



To the bottom right is a button “Best Practice” that works on the Microsoft operating systems. All I do is click “Best Practice” button. The tool originally was designed for Internet Information Server (IIS) but works regardless of whether IIS is installed on the client or server.


  1. Download appropriate version
  2. Double click EXE
  3. Click Best Practice Button
  4. Click Apply
  5. Reboot<
13-IMAGE13.pngNow my operating system is up-to-date from an SSL/TLS vulnerability perspective. It is not immune to or cured of vulnerabilities, but I feel much better having done this exercise.
My operating system is “Best Practice” according to a leader in the industry. My browser is updated against certain attacks.
14-IMAGE14.pngWhat next? Now the client operating system is updated; I can start looking at my hosted websites or servers by typing in the URL to, or, from the main page click "Test your server."



Once I check and update my browser I'm ready to test my website. The free online test located at If you do NOT want the information public make sure to check the box "Do not show results on the boards". Type your domain and click Submit.

ssltest2.pngAt the bottom of this initial test page the "Recent Worst", "Recent Best" and "Recent Scan". You might find interest in the "Recent Worst" list or use the search tool to check a site already scanned. A score of "F" translates to "avoid this website".

You might not have time to check every website prior to visit. The consolation is hardening the XenApp servers and client workstations with steps provided.



Brian MurphySenior Information Technology Consultant
Holistic technology infrastructure strategy, design, engineering and implementation that is highly scalable, secure, optimized, automated

Comments (1)

Jim HornSQL Server Data Dude
Most Valuable Expert 2013
Author of the Year 2015

Lots of content here and very well illustrated.  Voting Yes.
And I see it just made Featured Article on the homepage.  Congratulations!

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.