Defending from man-in-the-middle attacks

Helix Proxy

This topic assumes you have read the Introduction to multi-site deployment architectures.

To improve performance obtained by multiple Helix server users accessing a shared Helix server repository across a WAN,

1. Configure P4P on the side of the network close to the users.
2. Configure the users to access the service through P4P.
3. Configure P4P to access the master Perforce service.

System requirements

To use Helix Proxy, you must have:

• Helix server release 2002.2 or later (2012.1 or later to use SSL)
• Sufficient disk space on the proxy host to store a cache of file revisions

Installing P4P

In addition to the basic steps described next, see:

• Enabling SSL support
• Defending from man-in-the-middle attacks

UNIX

To install P4P on UNIX or Linux, do the following:

1. Download the p4p executable to the machine on which you want to run the proxy.
2. Select a directory on this machine (P4PCACHE) in which to cache file revisions.
3. Select a port (P4PORT) on which p4p will listen for requests from Helix server applications.
4. Select the target Helix server (P4TARGET) for which this proxy will cache.

Windows

Install P4P as an option when running the Helix Core server installer for Windows:

Running P4P

To run Helix Proxy, invoke the p4p executable, configuring it with environment variables or command-line options. Options you specify on the command line override environment variable settings.

For example, the following command line starts a proxy that communicates with a central Helix server located on a host named central, listening on port 1666.

$ p4p -p tcp64:[::]:1999 -t central:1666 -r /var/proxyroot

To use the proxy, Helix server applications connect to P4P on port 1999 on the machine where the proxy runs. The proxy listens on both the IPv6 and IPv4 transports. P4P file revisions are stored under a directory named /var/proxyroot.

P4P supports connectivity over IPv6 networks as well as IPv4. See the Helix Core Server Administrator Guide: Fundamentals for more information.

Running P4P as a Windows service

To run P4P as a Windows service, either install P4P from the Windows installer, or specify the -s option when you invoke p4p.exe, or rename the P4P executable to p4ps.exe.

To pass parameters to the P4Proxy service, set the P4POPTIONS registry variable using the p4 set command. For example, if you normally run the Proxy with the command:

C:\> p4p -p 1999 -t ssl:mainserver:1666

You can set the P4POPTIONS variable for a Windows service named Helix Proxy by setting the service parameters as follows:

C:\> p4 set -S "Perforce Proxy" P4POPTIONS="-p 1999 -t ssl:mainserver:1666"

When the "Helix Proxy" service starts, P4P listens for plaintext connections on port 1999 and communicates with the Helix Core server via SSL at ssl:mainserver:1666.

P4P options

The following command-line options specific to the proxy are supported:

Proxy options

Option	Meaning
-d	Run as daemon - fork first, then run (UNIX only).
-f	Do not fork - run as a single-threaded server (UNIX only).
-i	Run for inetd (socket on stdin/stdout - UNIX only).
-q	Run quietly; suppress startup messages.
-c	Do not compress data stream between the Helix server to P4P. (This option reduces CPU load on the central server at the expense of slightly higher bandwidth consumption.)
-s	Run as a Windows service (Windows only). Running p4p.exe -s is equivalent to invoking p4ps.exe.
-S	Disable cache fault coordination. The proxy maintains a table of concurrent sync operations, called pdb.lbr, to avoid multiple transfers of the same file. This mechanism prevents unnecessary network traffic, but can impart some delay to operations until the file transfer is complete. When -S is used, cache fault coordination is disabled, allowing multiple transfers of files to occur. The proxy then decides whether to transfer a file based solely on its checksum. This may increase the burden on the network, while potentially providing speedier completion for sync operations.

General options

Option	Meaning
-h or -?	Display a help message.
-V	Display the version of the Helix Proxy.
-r root	Specify the directory where revisions are cached. Default is P4PCACHE, or the directory from which p4p is started if P4PCACHE is not set.
-L logfile	Specify the location of the log file. Default is P4LOG, or the directory from which p4p is started if P4LOG is not set.
-p port	Specify the port on which P4P will listen for requests from Helix server applications. Default is P4PORT, or 1666 if P4PORT is not set.
-t port	Specify the port of the target Helix server (that is, the Helix server for which P4P acts as a proxy). Default is P4TARGET or perforce:1666 if P4TARGET is not set.
-e size	Cache only those files that are larger than size bytes. Default is P4PFSIZE, or zero (cache all files) if P4PFSIZE is not set.
-u serviceuser	For proxy servers, authenticate as the specified serviceuser when communicating with the central server. The service user must have a valid ticket before the proxy will work.
-v level	Specifies server trace level. Debug messages are stored in the proxy server’s log file. Debug messages from p4p are not passed through to p4d, and debug messages from p4d are not passed through to instances of p4p. Default is P4DEBUG, or none if P4DEBUG is not set.

Certificate-handling options

Option	Meaning
-Gc	Generate SSL credentials files for the proxy: create a private key (privatekey.txt) and certificate file (certificate.txt) in P4SSLDIR, and then exit. Requires that P4SSLDIR be set to a directory that is owned by the user invoking the command, and that is readable only by that user. If config.txt is present in P4SSLDIR, generate a self-signed certificate with specified characteristics.
-Gf	Display the fingerprint of the proxy’s public key, and exit. Administrators can communicate this fingerprint to end users, who can then use the p4 trust command to determine whether or not the fingerprint (of the server to which they happen to be connecting) is accurate.

Proxy monitoring options

Option	Meaning
-l	List pending archive transfers
-l-s	List pending archive transfers, summarized
-v lbr.stat.interval=n	Set the file status interval in seconds.
-v proxy.monitor.level=n	0: (default) Monitoring disabled 1: Proxy monitors file transfers only 2: Proxy monitors all operations 3: Proxy monitors all traffic for all operations
-v proxy.monitor.interval=n	Proxy monitoring interval, in seconds. If not set, defaults to 10 seconds.
-m1 -m2 -m3	Show currently-active connections and their status. Requires proxy.monitor.level set equal to or greater than 1. The optional argument specifies the level of detail: -m1, -m2, or -m3 show increasing levels of detail corresponding to the proxy.monitor.level setting.

Proxy archive cache options

See the lbr.proxy.case configurable in Helix Core P4 Command Reference.

Administering P4P

The following sections describe the tasks involved in administering a proxy.

No backups required

You never need to back up the P4P cache directory.

If necessary, P4P reconstructs the cache based on Helix server metadata.

Stopping P4P

P4P is effectively stateless; to stop P4P under UNIX, kill the p4p process with SIGTERM or SIGKILL. Under Windows, click End Process in the Task Manager.

Upgrading P4P

After you have replaced the p4p executable with the upgraded version, you must also remove the pdb.lbr and pdb.monitor files (if they exist) from the proxy root before you restart the upgraded proxy.

Enabling SSL support

To encrypt the connection between a Helix Proxy and its end users, your proxy must have a valid private key and certificate pair in the directory specified by its P4SSLDIR environment variable. Certificate and key generation and management for the proxy works the same as it does for the Helix Core server. See Enabling SSL support. The users' Helix server applications must be configured to trust the fingerprint of the proxy.

To encrypt the connection between a Helix Proxy and its upstream Perforce service, your proxy installation must be configured to trust the fingerprint of the upstream Perforce service. That is, the user that runs p4p (typically a service user) must create a P4TRUST file (using p4 trust) that recognizes the fingerprint of the upstream Perforce service.

See the Knowledge Base article, "Enabling SSL Support for the Server/Broker/Proxy".

Defending from man-in-the-middle attacks

You can use the net.mimcheck configurable to enable checks for possible interception or modification of data. These settings are pertinent for proxy administration:

• A value of 3 checks connections from clients, proxies, and brokers for TCP forwarding.
• A value of 5 requires that proxies, brokers, and all Helix server intermediate servers have valid logged-in service users associated with them. This allows administrators to prevent unauthorized proxies and services from being used.

You must restart the server after changing the value of this configurable. See net.mimcheck.

Localizing P4P

If your Helix server has localized error messages (see "Localizing server error messages" in Helix Core Server Administrator Guide: Fundamentals), you can localize your proxy’s error message output by shutting down the proxy, copying the server’s db.message file into the proxy root, and restarting the proxy.

Managing disk space consumption

P4P caches file revisions in its cache directory. These revisions accumulate until you delete them. P4P does not delete its cached files or otherwise manage its consumption of disk space.

If you delete files from the cache without stopping the proxy, you must also delete the pdb.lbr file at the proxy’s root directory. (The proxy uses the pdb.lbr file to keep track of which files are scheduled for transfer, so that if multiple users simultaneously request the same file, only one copy of the file is transferred.)

Determining if your Helix server applications are using the proxy

If your Helix server application is using the proxy, the proxy’s version information appears in the output of p4 info.

For example, if a Perforce service is hosted at ssl:central:1666 and you direct your Helix server application to a Helix Proxy hosted at outpost:1999, the output of p4 info resembles the following:

$ export P4PORT=tcp:outpost:1999
$ p4 info
User name: p4adm
Client name: admin-temp
Client host: remotesite22
Client root: /home/p4adm/tmp
Current directory: /home/p4adm/tmp
Client address: 192.168.0.123
Server address: central:1666
Server root: /usr/depot/p4d
Server date: 2012/03/28 15:03:05 -0700 PDT
Server uptime: 752:41:23
Server version: P4D/FREEBSD4/2012.1/406375 (2012/01/25)
Server encryption: encrypted
Proxy version: P4P/SOLARIS26/2012.1/406884 (2012/01/25)
Server license: P4 Admin <p4adm> 20 users (expires 2013/01/01)
Server license-ip: 10.0.0.2
Case handling: sensitive

P4P and protections

For setting protections on proxies and brokers, see "Proxy and protections" under "Setting protections with p4 protect" in Helix Core Server Administrator Guide: Fundamentals.

Determining if specific files are being delivered from the proxy

Use the -Zproxyverbose option with p4 to display messages indicating whether file revisions are coming from the proxy (p4p) or the central server (p4d). For example:

$ p4 -Zproxyverbose sync noncached.txt
//depot/main/noncached.txt - refreshing /home/p4adm/tmp/noncached.txt
$ p4 -Zproxyverbose sync cached.txt
//depot/main/cached.txt - refreshing /home/p4adm/tmp/cached.txt
File /home/p4adm/tmp/cached.txt delivered from proxy server

Case-sensitivity issues and the proxy

If you are running the proxy on a case-sensitive platform such as UNIX, and your users are submitting files from case-insensitive platforms (such as Windows), the default behavior of the proxy is to fold case. For example, FILE.TXT can overwrite File.txt or file.txt.

In the case of text files and source code, the performance impact of this behavior is negligible. If, however, you are dealing with large binaries such as .ISO images or .VOB video objects, there can be performance issues associated with this behavior.

After any change to lbr.proxy.case, you must clear the cache before restarting the proxy.

Maximizing performance improvement

In addition to the topics in this chapter, see the Support Knowledgebase article on tuning tips for "Proxy Performance", including how to minimize the syncing of small files.

Reducing server CPU usage by disabling file compression

By default, P4P compresses communication between itself and the Helix server versioning service, imposing additional overhead on the service. To disable compression, specify the -c option when you invoke p4p. This option is particularly effective if you have excess network and disk capacity and are storing large numbers of binary file revisions in the depot, because the proxy (rather than the upstream versioning service) decompresses the binary files from its cache before sending them to Helix server users.

Network topologies versus P4P

If network bandwidth on the subnet with the Perforce service is nearly saturated, deploy the proxies on the other side of a router so that the traffic from end users to the proxy is isolated to a subnet separate from the subnet containing the Perforce service. You might split the subnet into multiple subnets and deploy a proxy in each resulting subnet:

Preloading the cache directory for optimal initial performance

Helix Proxy stores file revisions only when one of its users submits a new revision to the depot or requests an existing revision from the depot. That is, file revisions are not prefetched. Performance gains from P4P occur only after file revisions are cached.

After starting P4P, you can prefetch the cache directory by creating a dedicated client workspace and syncing it to the head revision. All other users who subsequently connect to the proxy immediately obtain the performance improvements provided by P4P. For example, a development site located in Asia with a P4P server targeting a Helix server in North America can preload its cache directory by using an automated job that runs a p4 sync against the entire Helix server depot after most work at the North American site has been completed, but before its own developers arrive for work.

By default, p4 sync writes files to the client workspace. If you have a dedicated client workspace that you use to prefetch files for the proxy, however, this step is redundant. If this machine has slower I/O performance than the machine running the Helix Proxy, it can also be time-consuming.

To preload the proxy’s cache without the redundant step of also writing the files to the client workspace, use the -Zproxyload option when syncing. For example:

$ export P4CLIENT=prefetch
$ p4 sync //depot/main/written.txt
//depot/main/written.txt - refreshing /home/prefetch/main/written.txt
$ p4 -Zproxyload sync //depot/main/nonwritten.txt
//depot/main/nonwritten.txt - file(s) up-to-date.

Both files are now cached, but nonwritten.txt is never written to the the prefetch client workspace. When prefetching the entire depot, the time savings can be considerable.

Distributing disk space consumption

P4P stores revisions as if there were only one depot tree. If this approach stores too much file data onto one filesystem, you can use symbolic links to spread the revisions across multiple filesystems.

For instance, if the P4P cache root is /disk1/proxy, and the Helix server it supports has two depots named //depot and //released, you can split data across disks, storing //depot on disk1 and //released on disk2 as follows:

$ mkdir /disk2/proxy/released
$ cd /disk1/proxy
$ ln -s /disk2/proxy/released released

The symbolic link means that when P4P attempts to cache files in the //released depot to /disk1/proxy/released, the files are stored on /disk2/proxy/released.