Securing communication between clients and the Surround SCM Server
Keeping your Surround SCM data secure is critical. To prevent hackers from compromising your data, encrypt communication between clients and the Surround SCM Server.
The following information explains how Surround SCM encrypts data, how authentication works, and how key exchange is used for different authentication methods. See Setting general global server options for information about configuring secure client/server communication.
Encryption scrambles data to prevent interception, or eavesdropping, as it passes between clients and the server. Surround SCM uses the OpenSSL implementation of Advanced Encryption Standard-256 (AES-256) to encrypt communication between clients and servers in Surround SCM 2014.1 and later.
Client/server communication is encrypted when you select Encrypt communication between clients and the server in the general global server options. See Setting general global server options.
Authentication is the process of logging in a user. The following authentication methods are used.
Authentication method | How it works |
---|---|
Helix ALM License Server | The username and mathematical proof that the user knows the password (not the actual password) are sent to the Surround SCM Server. The server sends different mathematical proof that it knows the password to the client. |
LDAP | Using single sign-on—Credentials proving the user's identity are sent from the LDAP server to the Surround SCM Server and verified. |
Not using single sign-on—The username and password are sent to the Surround SCM Server. |
Key exchange is a method of exchanging secret keys over an insecure network connection without exposing them to eavesdroppers. The key exchange method used depends on the authentication method.
The following key exchange methods are used.
Key exchange method | When it is used | How it works | To use it: |
---|---|---|---|
Secure Remote Password (SRP) | User is authenticated from the license server and RSA key exchange is not enabled | A shared secret key is generated during authentication. To compromise the secret key or impersonate the server, a hacker must know the user's password. | Select Encrypt communication between clients and the server in the general global server options. |
Diffie-Hellman | User is authenticated using LDAP and RSA key exchange is not enabled | A mathematical process is used to generate a secret key. To compromise the secret key, a hacker must have control over an intermediate network node or impersonate the real server. Does not protect against man-in-the-middle attacks. | Select Encrypt communication between clients and the server in the general global server options. |
RSA | RSA key exchange is enabled in the Security server options | The client generates a random, 256-bit secret key and encrypts it with the server's public key. The server hashes the secret key and signs the hash with its private key. The private key is only stored on the server hard drive and never leaves the server. To compromise the secret key or impersonate the server, a hacker must know the server's private key or substitute their own public key in client applications. | Select Encrypt communication between clients and the server and Use RSA key exchange in the general global server options. |
SRP and Diffie-Hellman are low risk key exchange methods if your organization’s network is secure and no client applications outside of the network can communicate with the server.
We recommend using RSA key exchange to prevent hackers from eavesdropping on communication if:
- Your organization stores sensitive information in Surround SCM.
- Your network is potentially insecure.
- Users log in to client applications from outside your network.
- Users are authenticated using LDAP or single sign-on.
Using RSA requires additional setup for users. See Configuring RSA key exchange.