Posts tagged security

As part of our periodical PCI Compliance scans, our corporate vulnerability scanner recently picked up the View 4.6 PCoIP Gateway as having a few issues. These issues were as follows:

• SSL Server Supports Weak Encryption Vulnerability (port 4172/tcp over SSL)
• SSL Certificate – Subject Common Name Does Not Match Server FQDN
• SSL Certificate – Signature Verification Failed Vulnerability

We found this odd since we had an SSL certificate installed on the Security Server, and going to the site externally showed it using a proper cert. We opened a ticket with VMware who explained that this was due to port 4172 not using the SSL certificate that is used for HTTPS, and subsequently opened a ticket with Teradici.

To try to either get this fixed, we reached out to our local VMware reps for assistance. They were incredible helpful and went out of their way with conference calls, performing research on our behalf, and even writing up the following explanation on why the aforementioned results are actually false positives. It’s also an interesting read, regardless:

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.

The previous information has been critical in getting approval to re-enable our PCoIP Gateway, which is a lot more pleasant to use than RDP… especially on the iPad.