Use TLS 1.2 with Deep Security

In Deep Security Manager 11.1 and higher, TLS 1.2 is enforced by default for new installations.

Review the table below to determine whether you need to take action.

If you are doing... And your deployment includes... Do this...
A new installation of Deep Security Manager 11.1+ Only 10.0+ Deep Security Agents, Relays, and Virtual Appliances

Nothing.

By default, TLS 1.2 is used between all components and enforced on the manager and relays.
Pre-10.0 Deep Security Agents, Relays, or Virtual Appliances

(Recommended.) Upgrade all of your components to 10.0+ versions which support TLS 1.2. See Upgrade components to use TLS 1.2. This is the best option to increase the security of your deployment.

Alternatively, you can re-enable TLS 1.0 to ensure backward compatibility with older components. See Re-enable early TLS (1.0).

An upgrade to Deep Security Manager 11.1+ Only 10.0+ Deep Security Agents, Relays, or Virtual Appliances

(Recommended.) Enable TLS 1.2 enforcement to increase the security of your deployment. See Enforce TLS 1.2.

Alternatively, you can do nothing. Whatever your TLS settings were in your previous deployment are preserved. If you had enforced TLS 1.2 before, then your enforcement settings are preserved after the upgrade. Conversely, if you had disabled enforcement, then those settings are preserved as well.

Pre-10.0 Deep Security Agents, Relays, or Virtual Appliances

(Recommended.) Although no immediate action is required, you should plan to upgrade older components to 10.0+ which support TLS 1.2, and then enforce TLS 1.2. See Upgrade components to use TLS 1.2 and Enforce TLS 1.2. This is the best option to increase the security of your deployment.

Alternatively, you can do nothing. Whatever your TLS settings were in your previous deployment are preserved. If TLS 1.0 was allowed before, then it will also be allowed after the upgrade.

Topics on this page:

Benefits of TLS 1.2

Transport Layer Security (TLS), and the earlier Secure Sockets Layer (SSL), are encryption protocols that enable secure connections between different endpoints. When Deep Security components need to communicate, they determine the latest mutually-supported version of the encryption protocol and then use that version to secure all communication for the duration of their session. The latest version of TLS is 1.2. SSL has been discontinued due to security issues.

Trend Micro strongly recommends that you use TLS 1.2 communication between all its components. This page describes the benefits of TLS 1.2, and how to use and enforce it in your Deep Security environment.

The main benefits of TLS 1.2 are:

  • additional security. TLS 1.2 has been enhanced to safeguard against the latest exploits.
  • PCI compliance. The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard that promotes the safety of cardholder data. To be PCI-compliant, organizations must disable Secure Sockets Layer (SSL) and early TLS on applicable connections. For more information on PCI compliance, see Meet PCI DSS requirements with Deep Security.

TLS 1.2 architectures

The diagrams below show the TLS communication in the Deep Security architecture.

Figure 1 shows the TLS communication when TLS 1.2 is enforced (This is the default for new 11.1+ Deep Security Manager installations.) You can see that the 9.6 agents can no longer communicate with Deep Security Manager, and neither can older third-party applications.

Figure 2 shows the TLS communication when TLS 1.2 is not enforced. You can see that 10.0 or higher agents communicate with Deep Security Manager over TLS 1.2, while 9.6 versions communicate over early TLS. Similarly, newer third-party applications use TLS 1.2, while older ones use early TLS.

Figure 1: TLS 1.2 is enforced

Figure 2: TLS 1.2 is not enforced

Upgrade components to use TLS 1.2

If you want your Deep Security components to use TLS 1.2, but do not necessarily want to enforce TLS 1.2, all you need to do is make sure that each component supports TLS 1.2. When two components support TLS 1.2, they automatically use TLS 1.2 to communicate. If one component does not support TLS 1.2 and another does, then they negotiate an earlier version of TLS.

Follow the instructions below to verify that your Deep Security components support TLS 1.2 and upgrade them if needed.

If you want to enforce TLS 1.2 and prevent the use of early TLS, see instead Enforce TLS 1.2.

Verify and upgrade your Deep Security Manager

  • Make sure you're using one of the following versions of Deep Security Manager, and if not, upgrade it:
    • Use Deep Security Manager 10.0 update 8 or later if you're planning to Enforce TLS 1.2 on the manager. Only 10.0 update 8 and later managers support TLS 1.2 enforcement.
    • Using Deep Security Manager 10.0 or later if you're not planning to Enforce TLS 1.2 on the manager. Only 10.0 and later managers support TLS 1.2 communication.
  • For upgrade instructions, see Upgrade the Deep Security Manager AMI.

Verify your Deep Security Manager database

  • If you're using Microsoft SQL Server as your Deep Security Manager database, make sure the database supports TLS 1.2, and if not, upgrade it. See this Microsoft article for guidance.
  • If you're using a PostgrSQL database, it supports TLS 1.2 so no action is necessary.
  • If you're using an Oracle database, only Oracle's native encryption is supported for database-manager communication, not TLS, so no action is necessary.
  • By default, there is no encryption between the database (SQL Server, PostgreSQL, or Oracle) and Deep Security Manager. You can enable it manually.

Verify your Deep Security Agents

  • If you have existing Deep Security Agents, make sure they're at version 10.0 or higher. Only 10.0 or higher agents support TLS 1.2.

If some agents are left un-upgraded (that is, they are pre-10.0), those agents communicate over early TLS, and you may need to re-enable early TLS. For details, see Re-enable early TLS (1.0).

To upgrade your agents:

  1. Import the latest Deep Security Agent software into Deep Security Manager, either manually or automatically. See Update the Deep Security Agent for details.
  2. Upgrade your Deep Security Agents:

Verify your Deep Security Relays

  • Make sure you're using one of the following versions of Deep Security Relay, and if not, upgrade it:
    • Use Deep Security Relay 10.0 update 8 or later if you're planning to Enforce TLS 1.2 on the relay. Only 10.0 update 8 and higher relays support TLS 1.2 enforcement.
    • Use Deep Security Relay 10.0 or later if you're not planning to Enforce TLS 1.2 on the relay. Only 10.0 and higher relays support TLS 1.2 communication.

To upgrade a relay, follow the same process as upgrading an agent:

  1. Import the latest Deep Security Relay software into Deep Security Manager, either manually or automatically. See Update the Deep Security Agent for details.

  2. Upgrade the relay:

Enforce TLS 1.2

Topics in this section:

Where can TLS 1.2 be enforced?

There are two enforcement points:

  • on the Deep Security Manager
  • on the Deep Security Relays

What happens when TLS 1.2 enforced?

When TLS 1.2 is enforced, the manager and relays stop accepting early TLS connections, and any applications that try to use early TLS are denied access and cease to function properly.

If you choose not to enforce TLS 1.2, the manager and relays still accept early TLS as well as TLS 1.2 connections. This means that both older and newer applications are able to connect.

Is TLS 1.2 enforced by default?

  • If you have a new installation of Deep Security Manager 11.1+ (not an upgrade), TLS 1.2 is enforced by default.
  • If you are upgrading an existing Deep Security Manager to 11.1 or higher, then your existing TLS settings are preserved, so if TLS was not enforced previously, it will continue to not be enforced after the upgrade. Conversely, if it was enforced, it will continue to be enforced.

Under what circumstances is TLS 1.2 enforcement possible?

You can only enforce TLS 1.2 if all Deep Security Agents have been upgraded to 10.0+, which is the version at which TLS 1.2 is supported.

Enforce TLS 1.2 on Deep Security Manager

  1. Before you begin:
    • Make sure that Deep Security Manager is at version 10.0 Update 8 or higher. You need this version to enforce TLS 1.2.
    • Make sure that all other components support TLS 1.2. See Upgrade components to use TLS 1.2.
  2. On the Deep Security Manager computer, run this dsm_c command:

    dsm_c -action settlsprotocol -MinimumTLSProtocol ShowValue

    A TLS version appears. This is the minimum TLS version that Deep Security Manager currently accepts.

  3. Run this dsm_c command:

    dsm_c -action settlsprotocol -MinimumTLSProtocol TLSv1.2

    This command sets the minimum TLS version to 1.2. Deep Security Manager now accepts TLS 1.2 connections and disallows TLS 1.0 connections.

    The Deep Security Manager service is restarted automatically.

Enforce TLS 1.2 on the Deep Security Relay

  1. Before you begin:
  2. Resend the policies associated with your relays:
    1. In Deep Security Manager, click Computers and find one of your relays in the list of computers. If you're not sure which ones are your relays, at the top, click Administration. On the left, expand Updates and then click Relay Management. In the main pane, expand a relay group to see your relays.
    2. Double-click the relay in the list of computers.
    3. In the main pane, click the Actions tab.
    4. Click Send Policy to resend the policy.
    5. Resend the policy to each of your relays.

Enforce TLS 1.2 on just the manager's GUI port (4119)

Only read this section if you were unable to do a full enforcement on the Deep Security Manager and Relays as described previously in Enforce TLS 1.2 on Deep Security Manager and Enforce TLS 1.2 on the Deep Security Relay.

This section describes how to set the minimum TLS version to TLS 1.2 on port 4119. Applications that connect on port 4119 are typically web browsers and REST or SOAP API clients. Older Deep Security components that do not support TLS 1.2 can continue to connect to the manager (on port 4120, by default) using TLS 1.0.

  1. On Deep Security Manager, enable TLS 1.0 by running this dsm_c command:

    dsm_c -action settlsprotocol -MinimumTLSProtocol TLSv1

    Deep Security Manager now accepts TLS 1.0 connections from older agents and applications.

  2. Disable early TLS on the manager's GUI port (4119) (it is possible that it's already disabled):
    1. Open the configuration.properties file in the root of the Deep Security Manager installation directory.
    2. Under serviceName=, look for the protocols= setting.

      This setting defines the protocols that can be used to connect to Deep Security Manager when it is acting as a server to web browsers and REST or SOAP API clients.

    3. If the protocols= setting is present, remove it so that only TLS 1.2 is allowed on port 4119.
    4. Save the file.
  3. Restart the Deep Security Manager service.

Test that TLS 1.2 is enforced

  1. On a Deep Security component where early TLS 1.2 is enforced, run the following nmap command:

    2. nmap --script ssl-enum-ciphers <ds_host> -p <ds_port> -Pn

    where:

    • <ds_host> is replaced with the IP address or hostname of the manager or relay
    • <ds_port> is replaced with the listening port where TLS is being used (4119 for manager, 4122 for the relay, and 4118 for the agent—if manager-initiated activation is used)

    The response should only list TLS 1.2. Example response:

    PORT STATE SERVICE

    443/tcp open https

    | ssl-enum-ciphers:

    | | TLSv1.2:

    | ciphers:

    | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A

    | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A

    | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A

    | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A

    | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A

    | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A

    | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A

    | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A

    | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A

    | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A

    | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C

    | compressors:

Re-enable early TLS (1.0)

You'll need to re-enable early TLS (1.0) if you have a new installation of Deep Security Manager 11.1+ (not an upgrade) and:

  • you are using pre-10.0 agents. These only support early TLS. Go here to see if a 10.0+ agent is available for your OSs.
  • you are using third-party components that are older and need to use early TLS to communicate with Deep Security Manager.
  • you are using a 9.5 version of the Deep Security Virtual Appliance with an un-upgraded embedded agent.

To re-enable early TLS (1.0), follow the instructions below.

Re-enable TLS 1.0 on Deep Security Manager and the Deep Security Relay

  1. On the Deep Security Manager computer, run this dsm_c command:

    dsm_c -action settlsprotocol -MinimumTLSProtocol ShowValue

    A TLS version appears. This is the minimum TLS version that Deep Security Manager currently accepts.

  2. Run this dsm_c command:

    dsm_c -action settlsprotocol -MinimumTLSProtocol TLSv1

    This command sets the minimum TLS version to 1.0.

    TLS 1.0 is now re-enabled on your Deep Security Manager.

    The Deep Security Manager service is restarted automatically.

  3. Resend the policies associated with your relays:
    1. In Deep Security Manager, click Computers and find one of your relays in the list of computers. If you're not sure which ones are your relays, at the top, click AdministrationOn the left, expand Updates and then click Relay Management. In the main pane, expand a relay group to see your relays.
    2. Double-click the relay in the list of computers.
    3. In the main pane, click the Actions tab.
    4. Click Send Policy to resend the policy.
    5. Resend the policy to each of your relays.

    TLS 1.0 is now re-enabled on your relays.

Re-enable TLS 1.0 on the manager's GUI port (4119)

Read this section if you previously enforced TLS 1.2 only on the manager's GUI port (4119) and now want to re-enable TLS 1.0 on this port.

  1. Follow the instructions in Re-enabled TLS 1.0 on Deep Security Manager. This re-enables TLS 1.0 on the GUI port (4119).

Determine whether TLS 1.2 is enforced

If you're not sure whether TLS 1.2 is enforced on Deep Security Manager, follow the instructions below to find out.

  1. On the Deep Security Manager computer, open a command prompt and run the following dsm_c command:

    dsm_c -action settlsprotocol -MinimumTLSProtocol ShowValue

    The minimum TLS protocol accepted by the manager is displayed. If it shows TLS 1.2, then TLS 1.2 is enforced. If it shows TLS 1.0, then early TLS is allowed and TLS 1.2 is not enforced.

Determining whether TLS 1.2 is enforced on the relay is harder. If you pushed out your TLS settings to the relay through policy according to Enforce TLS 1.2 on the Deep Security Relay or Re-enable TLS 1.0 on Deep Security Manager and the Deep Security Relay, then those TLS settings apply to the relay. If you did not push out TLS settings through policy, then the relay's default TLS settings apply. The relay's default settings depend on its version: if you're using an 11.1+ relay, then TLS 1.2 is enforced by default. For pre-11.1 relays, TLS 1.2 is not enforced by default.

Guidelines for deploying agents, and relays after TLS 1.2 is enforced

This section discusses special considerations when deploying agents and relays when TLS 1.2 is enforced. If you re-enabled early TLS (1.0), then there are no special considerations, and you do not need to read this section.

Topics in this section:

Guidelines for deploying agents, and relays when TLS 1.2 is enforced

  • You must deploy 10.0+ agents, and relays. Only 10.0+ agents and relays support TLS 1.2.
  • If you need to deploy a 9.6 or earlier agent or relay you must re-enable early TLS (1.0) wherever it was enforced (either on the manager, on the relay, or on the manager's GUI port 4119).

Guidelines for using deployment scripts when TLS 1.2 is enforced

If TLS 1.2 is enforced, you can install 10.0+ agents and relays using deployment scripts. Below are some guidelines to ensure the deployment scripts work:

  1. If you are deploying an agent or relay onto Windows computers, use PowerShell 4.0 or higher, which supports TLS 1.2.
  2. If you are deploying onto Windows XP, 2003, or 2008, where PowerShell 4.0 is not supported, see the Workaround below.
  3. If you are deploying an agent or relay onto Linux, use curl 7.34.0 or higher, which supports TLS 1.2.
  4. If you are deploying onto Red Hat Enterprise Linux 6, which uses curl 7.19 by default, do one of the following:
    • upgrade to curl 7.34.0 or later

      OR

    • See the Workaround below

Workaround

If TLS 1.2 is enforced, and...

  • you are deploying onto Windows XP, 2003, or 2008, where PowerShell 4.0 is not supported...

    OR

  • you are deploying onto a Red Hat Enterprise Linux 6 computer with curl 7.19 that cannot be upgraded...

    • Do this:

    1. From Deep Security Manager, download the agent installation package for your operating system. See Get Deep Security Agent software for details.
    2. Copy the installation package to your web server.
    3. Follow the instructions in Use deployment scripts to add and protect computers to add and protect computers, but instead of using Deep Security Manager to generate the script, use the Windows script or Linux script that is provided below.

    Windows script:

    You must set the baseUrl variable to the URL of your agent package on your web server.

    $env:LogPath = "$env:appdata\Trend Micro\Deep Security Agent\installer"

    New-Item -path $env:LogPath -type directory

    Start-Transcript -path "$env:LogPath\dsa_deploy.log" -append

    echo "$(Get-Date -format T) - DSA download started"

    $baseUrl=<server/package>

    echo "$(Get-Date -format T) - Download Deep Security Agent Package" $sourceUrl

    (New-Object System.Net.WebClient).DownloadFile($sourceUrl, "$env:temp\agent.msi")

    if ( (Get-Item "$env:temp\agent.msi").length -eq 0 ) {

    echo "Failed to download the Deep Security Agent. Please check if the package is on the server. "

    exit 1 }

    echo "$(Get-Date -format T) - Downloaded File Size:" (Get-Item "$env:temp\agent.msi").length

    echo "$(Get-Date -format T) - DSA install started"

    echo "$(Get-Date -format T) - Installer Exit Code:" (Start-Process -FilePath msiexec -ArgumentList "/i $env:temp\agent.msi /qn ADDLOCAL=ALL /l*v `"$env:LogPath\dsa_install.log`"" -Wait -PassThru).ExitCode

    Stop-Transcript

    echo "$(Get-Date -format T) - DSA Deployment Finished"

    Linux script:

    Use the script that is appropriate for your Linux distribution.

    Replace <server/package> with the URL of the agent package on your web server.

    For Linux distributions that use the RPM Package Manager:

    #!/usr/bin/env bash

    curl <server/package> -o /tmp/agent.rpm –silent

    rpm -ihv /tmp/agent.rpm

    For Debian-based Linux distributions:

    #!/usr/bin/env bash

    curl <server/package> -o /tmp/agent.deb –silent

    dpkg -i /tmp/agent.deb