View PCoIP Gateway - SSL Certificate Issues

[eeg3]

Since going to the View 4.6 PCoIP Security Gateway, our security scanner is returning the following results on port 4172 of our external security server.

1. SSL Server Supports Weak Encryption Vulnerability: Supports TLS v1 DES(56) and SSLv3 DES(56) on Port 4172/TCP over SSL
2. SSL Certificate - Self-Signed Certificate: port 4172/TCP over SSL
3. SSL Certificate - Subject Common Name Does Not Match Server FQDN: Port 4172/TCP over SSL

These do not pop up for port 80 or port 443, only port 4172.

We have an SSL Certificate installed on our Security Server (none on our connection servers), and it shows up properly when going to the site on HTTP/HTTPS. For some reason, our scanner is saying port 4172 is using a self-signed certificate for SSL. Anyone have any ideas why that would occur?

[eeg3]

Well, I opened a ticket with VMware, who believes this might be caused by the PCoIP protocol handling security on its own and not utilizing the signed cert. They've opened a ticket with Teradici as of last night.

[idle-jam]

thanks for sharing, i'm keen to know the actual root cause and the resolution.

[eeg3]

Update from VMware Support:

We have a ticket open with Teradici regarding this issue.  We have been able to confirm that they do use their own self signed Certificate for PCoIP encryption.  The data stream between the host and client is secured using the AES encryption algorithm in GCM mode as an IPSec ESP mechanism for confidentiality and Authentication.  By default this is an AES-GCM, 128 bit key, but with View clients there is the option to use Salsa20 256-bit.

Currently there is no mechanism available to change that self signed certificate.

[eeg3]

This is an old thread, but I figured it would be worth following up with our resolution.

With the help of the fine folks at VMware who have gone above and beyond in helping us get this resolved, here is an explanation on why this should not be considered an issue:

VMware wrote:

One of the roles of the View Security Server is to ensure that only traffic on behalf of authenticated users is allowed to reach the internal network and only to those desktops that the user is authorized to access. Authentication and authorisation is performed over an HTTPS (TCP 443) connection to View Security Server.

When a PCoIP virtual desktop is selected by the user at the View Client, View Connection Server (via Security Server) returns an IP address, a port number and a one-time token to the client to enable the PCoIP connection to the Security Server. This channel is protected using an SSL server certificate that can be replaced by a CA signed certificate. The client will connect to the supplied IP address/port number and will proceed only if the far end is a PCoIP server or View Security Server. The TCP 4172 listener on View Security Server 4.6, in its turn, will negotiate only with a PCoIP client executing in the context of an authenticated and authorized user. Once an SSL channel is established, the client provides the one-time token to the Security Server, which then associates the client with the authenticated user through the token. Over this assured channel, an IPSec security association is performed in a process analogous to an IKE Phase 2 negotiation.

All PCoIP traffic between the View Client and View Desktop, through View Security Server, is then AES-128 encrypted with GCM authentication. UDP packets arriving at the View Security Server (or the View Desktop) with an invalid IPSec SPI or that cannot be authenticated with the key associated with the SPI will be discarded. The client similarly discards traffic that is not from the server.

The PCoIP (4172) channel can not be used to gateway PCoIP traffic without the user first authenticating and having entitlements to access virtual desktops. We are aware that some security scanners will report a PCI violation relating to the use of self-signed certificates on this PCoIP channel because they cannot know that this channel can’t be used without the initial authentication.

Some vulnerability scanners have not been updated to compensate for View using multiple ports and authentication mechanisms in tunnel creation and as such report false positives against the View Security Server.

[KevinAlanHarris]

Is there any way to change the certificate and increase the encryption?  Is this something VMware is going to allow?

[Mnemonic]

Just notices this issue.

THIS IS A MAJOR CONCERN! Dispite what VMware writes in this post.

The problem is that the port 4172 is vulnerable to Man-In-The-Middle Attacks, and all PCoIP traffic can be read, and analysed by a 3. party without the users knowledge!

I think that this is a very importent issue, as this is still a problem with version 5.1 of View.

Best Regards

Brian Knutsson

Atea A/S

[WilliamReid]

hi Brian,

How is this possible?

"UDP packets arriving at the View Security Server (or the View Desktop) with an invalid IPSec SPI or that cannot be authenticated with the key associated with the SPI will be discarded."

So, Invalid IPSec SPI or key gets dropped, only way of obtaining those is to pass authentication.

"The PCoIP (4172) channel can not be used to gateway PCoIP traffic without the user first authenticating and having entitlements to access virtual desktops"

So a PCoIP session is not actually established until the client passes authentication...

If you can demonstrate how a man in the middle attack is performed, please file a support request so we can properly engage our security team.

Thanks!

Wm