February 16, 2012

Secure Perforce communications with SSL

What's New
Healthcare

A good citizen of a secure world

The topic of security is a bit tricky for a version management system like Perforce. Although we need to keep security in mind, we're not a dedicated security system. Or, as one of my colleagues likes to say, Perforce isn't Fort Knox. It's the gold inside Fort Knox and needs to be protected. And, bear in mind that making data easy to find and use is a key requirement for Perforce.

Back in the good old days, most important IT systems were kept on closed networks guarded by big firewalls, so perhaps you could assume that security wasn't the concern of every application. Now, though, we know that those days are well and truly gone. Many companies have teams working on several continents, which may require less-than-ideal network connections. A lot of people want to work from home or while they're on the road. Personal mobile devices are all over the place. And the severity of malicious activity is worse than ever.

So keeping all that in mind, I'd say that Perforce tries to be a well-behaved part of a secure environment. A secure environment has a multi-layered, defense-in-depth design. It may include firewalls, policy restrictions, layered internal networks, and other pieces. As part of that environment, Perforce does several things to make your data more secure, like auditing, access control, and detecting data tampering.

Another layer of shielding

Now, Perforce is adding SSL-secured communication in the 2012.1 release. Keeping with the principle that a failure at one level won't compromise the entire system, a network intruder will now find it much more difficult to eavesdrop on Perforce traffic, even if they've made it past the firewall.

The implementation is quite simple:

  • You need SSL-enabled versions of the Perforce server (p4d) and any client programs in use
  • You provide your Perforce server (or broker) with your SSL certificate.
  • Include the ssl prefix in front of your server and client P4PORT settings. For example, your server may listen on ssl:p4server:1666, so your clients would use ssl:p4server:1666 as their P4PORT setting.

If you use a server with SSL turned on, all of your clients must communicate with it over SSL. If you're not ready to roll out SSL for your entire user base, you can put an SSL-enabled broker in front of your server and send the secure traffic through the broker. That may be useful if you only want SSL for folks working remotely. Coupled with access control rules that can take location (IP address) into account, it'll be even easier to let a remote team collaborate on your server while still taking sensible security precautions.

And the drawbacks? Besides the slight bit of extra configuration, using SSL does impose a performance penalty on network communications. I haven't measured the impact, but I've been using an SSL connection for a few weeks now and haven't noticed anything significant.

What do you need?

Give the 2012.1 release a spin if you need SSL in your environment. Are there other security bits you need? Are you subject to regulatory restrictions that impact how you use Perforce? Please let us know!