«

»

Securing Display Protocols for VDI

Security in IT environments is an incessant quest nowadays. During the client/server era the ability to encrypt data between datacenter and applications was indispensible to many organizations. Transport Layer Security (TLS), Secure Socket Layer (SSL) and IPsec were widely used to secure data transmissions; and still are.

With the introduction of hosted desktops (VDI) organizations were able to centralize and consolidate application processing and data. Beyond consolidation advantages from a capacity standpoint, this centralization and consolidation process moved the high security perimeters from the edge of the organizations to the datacenter.

 

image

BYOC (Bring your Own Computer) and the introduction of unmanaged devices (tablets etc…) hindered organization’s wide implementation of security techniques.

Because all the information that matters is now in the datacenters, administrators and engineers started spending less time and money on the datacenter outer side.

In a properly designed and implemented VDI solution the only data that should leave the datacenter is the display protocol. The display protocol is responsible for providing users with a graphical interface to a desktop hosted in the datacenter.

If the display protocol stream is intercepted or captured it is possible to render the screen as seen by the user. For that reason is essential that display protocols implement a cipher that performs encryption and decryption of the data.

 

PCoIP

PCoIP display protocol bundled with VMWare View offers support for AES-128 bit by default but it can be overridden with Salsa20-256. The encryption type and level can be manipulated via Group Policies using the ADM templates provided with VMware View.

Salsa20-256 provides better throughput (up to 20Mb/s) than AES-128 bit. However, Salsa20-256 bit cannot be used with PSG (read more on VMware View 4.6 PCoIP Software Gateway). The PCoIP Secure Gateway does not allow Salsa20-256 to be negotiated because the encryption algorithm is not considered strong enough for use over untrusted networks.

Enabling FIPS (Cryptographic Module Validation Program) mode on a PCoIP connection also will automatically disable Salsa20-256.

If you are in a private environment with adequate bandwidth (let’s say, LAN environment) then Salsa20-256 could improve PCoIP user experience given the higher throughput due to lower CPU overhead to decrypt packets.

In order to achieve even higher throughput using PCoIP it is required a PCoIP hardware host using Teradici’s Tear 1 cards. The same cards also allow strong AES-128 bit encryption. To put that to bed, in my personal experience anything over 5Mb/s is making use of High Definition video and/or Stereo CD quality Audio.

Interestingly, PCoIP does not allow encryption to be fully disabled.

 

Citrix XenDesktop HDX/ICA display protocol uses SSL Relay and Secure Gateway with RC5-128 bit encryption. SecureICA also does not use FIPS-compliant algorithms.

 

Local Mode

VMware View also allow for offline desktops (now called “local mode”). Local mode is another circumstance where data can be hosted of transferred outside the datacenter. Read more about Local mode and Transfer Servers at Simon Long’s article.

For local mode any data transferred to, or at rest, at a user’s laptop is encrypted with AES-128 by default but it can be overridden to AES-192 or AES-256.

 

Additional security measures may be required on the edge of the datacenter, more specifically at Connection Servers and Security Servers. Follow my article Hardening VDI (VMView) Deployments and the VMware View Security Hardening Practices.

Similar Posts:

Permanent link to this article: http://myvirtualcloud.net/?p=1965

Leave a Reply