June 30, 2015

Straight Talk on Security Protocols in Perforce Helix

IP Protection
With POODLE, Heartbleed and other vulnerabilities in the news, I’ve had many of my customers asking me about the cryptographic protocols used in Perforce Helix. SSL 3.0 is used by many legacy systems and is vulnerable to attacks. However, our Helix Versioning Engine (P4D) does not use SSL 3.0 and supports only TLS 1.1.

Seeing is believing though, so let’s do a quick test to demonstrate how secure P4D is against such vulnerabilities.


Heartbleed, Shellshock and POODLE have been the three biggest security threats in the last several months.
  • The 2014.1 release of our P4D Versioning Engine was patched for the Heartbleed vulnerability, so we can check that box. That's one vulnerability down, two to go.
  • Shellshock was primarily outside of the scope of P4D itself. That said, P4D benefited from the remedial steps taken to secure the OS it is run on. OK, that's now two down as long as the OS that P4D is running on has been properly patched.
  • That leaves the POODLE attack to be addressed. In some sense, the POODLE vulnerability is worse because there is NO fix for it. 
On the other hand, POODLE is less impactful because it can be exploited only via Man-in-the-Middle or Man-on-the-Side attacks—that is, from same or adjacent networks—whereas Heartbleed could be exploited from anywhere. Having said that, if a rogue human client request is sent to a server that is not equipped to deal with SSL 3.0, the server is potentially vulnerable to human attackers.
The vulnerability itself exists in the SSL 3.0 protocol—a protocol for Internet encryption that is 15 years old. No modern system likes to use SSL 3.0 and instead uses the more secure TLS protocol, but almost all systems are still backwards compatible with SSL 3.0. Once the attacker forces a protocol downgrade from TLS to SSL 3.0, he or she can decrypt the traffic one byte at a time.
It is important to note the new SSL 3.0 feature TLS_FALLBACK_SCSV will prevent downgrade attacks only when both the client and server support it. It will not remediate the underlying SSL 3.0 issue, which is a fundamental design flaw.
P4D does not explicitly allow users to configure or choose SSL/TLS protocol versions at the application level. It does not maintain an application-specific ssl.conf to enable or disable any particular protocol. However, P4D does ignore the incoming traffic from the protocol it does not support within its server process.
Let’s see it in action:
First, I configured my Helix Versioning Engine (P4D server) to enable SSL as follows:
$ export P4ROOT=<where db.* files reside>

$ mkdir {P4ROOT}/sslkeys

$ chmod 700 {P4ROOT}/sslkeys

$ export P4SSLDIR={P4ROOT}/sslkeys

$ p4d -Gc

$ p4d -Gf

$ p4d -p ssl::1666 -r {P4ROOT} –d
Second, I established a direct trust between p4 and p4d:
$ p4 –P ssl::1666 trust –y

The fingerprint of the server of your P4PORT setting

'ssl::1666' ( is not known.

That fingerprint is 63:08:34:29:4D:3D:78:C3:7B:5B:73:02:13:09:B6:05:B0:91:6E:86

Added trust for P4PORT 'ssl::1666' (
Now my client ⇐⇒ server traffic is ready for secure data transfer.
Let’s look at a rogue human client request made to the Helix Versioning Engine using SSL 3.0 and TLS 1.1 protocol to see how the response from the server differs.

SSL 3.0

$ openssl s_client -connect localhost:1666 -ssl3

As you can see, the Versioning Engine clearly rejected SSL 3.0 renegotiation.

TLS 1.1

Now let’s look at the client request and response using TLS 1.1:
   $ openssl s_client -connect localhost:1666 -tls1
It's clear that the Versioning Engine gladly accepted the TLS1.1 request and responded back to the client.


The Helix Versioning Engine is safe from not only the Heartbleed vulnerability but also from the POODLE attack. Essentially, because it ignores the legacy SSL3.0 traffic and only allows TLS1.x traffic, it cannot be affected by legacy protocol issues. If you are responsible for security in your organization, our Helix Versioning Engine could give you one less thing to worry about.