Accelerator Client to Server communication encryption

Problem

Is communication between the Enterprise Vault (EV) Compliance Accelerator (CA) or Discovery Accelerator (DA) Clients and servers encrypted?

Solution

Communication between the Accelerator Clients and servers is encrypted by default. Such communication occurs over Transmission Control Protocol (TCP) via Remote Procedure Calls (RPC) over TCP ports 8085 and 8086 by default. The communication transport channel is handled by the .NET infrastructure using Windows Authentication via Transport Layer Security (TLS) and the Security Support Provider Interface (SSPI), also known as Schannel SSP or Schannel in short. To verify encryption is enabled (default behaviour), review the following configuration files located in the Accelerator installation folder, typically located under \Program Files (x86)\Enterprise Vault Business Accelerator on the Accelerator server.

-    AcceleratorManager.exe.config
-    AcceleratorManagerConsole.exe.config
-    AcceleratorService.exe.config
-    ADSynchroniser.exe.config

These configuration files should contain Remoting Channel Configuration sections which determine the communication channel behaviour. By default (on installation) the communication should be encrypted, as indicated by the secure setting being set to true, and the protectionLevel setting being set to EncryptAndSign.

Here is an example:

<!-- This channel configuration is for the Web client -->
    <add key="Remoting Channel Configuration" value="name=Client Port, port=8085,suppressChannelData=false, machineName=, priority=1, secure=true, protectionLevel=EncryptAndSign, useIpAddress=true,  bindTo=0.0.0.0, rejectRemoteRequests=false, exclusiveAddressUse=true, impersonate=false, authorizationModule=, typeFilterLevel=Full" />
    <add key="Remoting Channel Configuration IPv6" value="name=Client Port IPv6, port=8085,suppressChannelData=false, machineName=, priority=2, secure=true, protectionLevel=EncryptAndSign, useIpAddress=true,  bindTo=[::], rejectRemoteRequests=false, exclusiveAddressUse=true, impersonate=false, authorizationModule=, typeFilterLevel=Full" />
    <!-- This channel configuration is for the Windows client.-->
    <add key="Windows Client Remoting Channel Configuration" value="name=Windows Client Channel, port=8086,suppressChannelData=false, priority=1, secure=true, protectionLevel=EncryptAndSign, rejectRemoteRequests=false, exclusiveAddressUse=true, impersonate=false, typeFilterLevel=Full" />
    <add key="Windows Client Remoting Channel Configuration IPv6" value="name=Windows Client Channel IPv6, port=8086,suppressChannelData=false, priority=2, secure=true, protectionLevel=EncryptAndSign,  bindTo=[::], rejectRemoteRequests=false, exclusiveAddressUse=true, impersonate=false,  typeFilterLevel=Full" />

Notes on Schannel Cipher Suites

A cipher suite is a set of algorithms that help secure a Schannel network connection, such as TLS and SSL. Before a server and client can exchange data over an Schannel connection, they need to agree on the cipher suite to be used to secure the connection. In most cases, the list of available cipher suites is provided by the operating system (OS), usually arranged in order of the most secure cipher suite taking precedence. In some specialised use-cases, an application can require the use of a specific cipher suite. However, that is not the case with CA/DA, which use the cipher suites provided by the OS.

The list of cipher suites provided by the Windows OS can differ depending on the OS version in use. One method of determining the list of cipher suites currently in use is via the PowerShell command Get-TlsCipherSuite (if supported by the OS). Running this command on the server and/or client computer displays an ordered list of cipher suites provided by the OS. Another method is to review the Group Policy Objects (GPO) applied to the computer, as follows:

- From the Group Policy Management Console, go to Computer Configuration | Administrative Templates | Network | SSL Configuration Settings.
- Double-click SSL Cipher Suite Order, and then click the Enabled option.
- Right-click SSL Cipher Suites box and select Select all from the pop-up menu.
- Right-click the selected text, and select copy from the pop-up menu.
- Paste the text into a text editor.

Note - Even though the GPO lists the cipher suites under SSL configuration Settings and does not specifically state TLS, the cipher suite listing is used by Schannel connections, which include TLS and SSL.

References:

- TLS/SSL overview (Schannel SSP): https://docs.microsoft.com/en-us/windows-server/security/tls/tls-ssl-schannel-ssp-overview
- Cipher Suites in TLS/SSL (Schannel SSP): https://docs.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel
- Get-TlsCipherSuite: https://docs.microsoft.com/en-us/powershell/module/tls/get-tlsciphersuite
- Manage Transport Layer Security (TLS): https://docs.microsoft.com/en-us/windows-server/security/tls/manage-tls
- Cipher Suites: https://ciphersuite.info/cs/

Notes on TCP port 81 and TCP port 82 as used by Veritas Advanced Surveillance (VAS) in versions 14.0 and newer, and the DA Web Client in versions 14.4.0 and newer

The VAS and DA Web Client use TCP ports 81 and 82 by default as specified during the install or upgrade. Port 81 is the front-end website used by users to access the application over HTTPS. Port 82 is used for internal communication between the application and the internal API server via HTTP. Note that port 82 is not accessible to users and is only used locally by the front-end website on HTTPS port 81. As such, any calls between ports 81 and 82 are always local to the application on the server and encryption is not needed.

VAS and the DA Web Client use Integrated Windows Authentication to authenticate the user. Integrated Windows Authentication can work with both NTLM and Kerberos - see the following Microsoft site for more information: https://learn.microsoft.com/en-us/iis/configuration/system.webServer/security/authentication/windowsAuthentication/ . Internal calls to API endpoints on port 82 are first authenticated by the front-end website on HTTPS port 81, then the user's permissions are evaluated to verify the user making the call has the required permissions to do so. Once successfully evaluated, the internal call on port 82 is made using the Vault Service Account's (VSA) encrypted credentials, as this is the privileged user within the application and has the required permissions to perform the functions as requested by the front-end website. The VSA's encrypted credentials are stored in \Program Files (x86)\Enterprise Vault Business Accelerator\SupervisionApi\Web.config file in the <CipherValue> section for this purpose.