       |
|
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 Surround SCM 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. RC4 encryption is used for backward compatibility with earlier Surround SCM and TestTrack versions.
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.
Note: Always use encryption unless you are evaluating Surround SCM or troubleshooting a performance issue. Passwords are always encrypted even if client/server communication is not.
Login credentials sent from web browsers to the Surround SCM web server via HTTP are not encrypted, even if encryption is enabled on the Surround SCM Server. We strongly recommend using HTTPS to encrypt communication from the browser to the web server. HTTPS connections use a self-signed certificate by default, but you can configure the web server to use your own SSL certificate in the Surround SCM Registry Utility. See the Surround SCM Registry Utility help for information.
Authentication is the process of logging in a user to Surround SCM. The following authentication methods are used in Surround SCM.
| Authentication method | How it works |
|---|---|
| Seapine 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. | |
| External authentication | Data from the organization's authentication system is 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 in Surround SCM.
| Key exchange method | When it is used | How it works | To use it: |
|---|---|---|---|
| Secure Remote Password (SRP) | User is authenticated from the Seapine 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 or external authentication, 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 Surround SCM Server.
We recommend using RSA key exchange to prevent hackers from eavesdropping on communication if:
Using RSA requires additional setup for users. See Configuring RSA key exchange.
| |
|