Deployment Architecture

How to prevent Deployment Server spoofing in public networks

Builder

Scenario

I have laptops with Universal Forwarder. The UFs are configured as Deployment Clients. They download and run any package a Deployment Server offers them.
Obviously, I want to make sure the packages actually come from my Deployment Server and are not malware an attacker offered through a spoofed Deployment Server. This is particularly relevant if the laptops are frequently connecting to public WiFi networks.

Task: How to make it as difficult as possible to spoof a Deployment Server?

Research - Configuring Deployment Server

I know I can configure Deployment Server to use a TLS certificate of my choosing via server.conf. Let's assume I have configured TLS 1.2 correctly on the Deployment Server.

Research - Configuring Deployment Client

The remaining task is to ensure UF's Deployment Client only talks to my Deployment Server. The Deployment Client's TLS configuration is also in server.conf (on the UF), more specifically in the sslConfig stanza.

I found the following relevant settings:

# Talk to Deployment Server via TLS 1.2 only
sslVersionsForClient = tls1.2

# Make Deployment Client actually verify the server's certificate is valid
sslVerifyServerCert = true

# Deployment Server the Deployment Client is allowed to talk to
sslCommonNameToCheck = NAME-OF-MY-DEPLOYMENT-SERVER

# Depending on the TLS certificate, the Deployment Server name has to go here
sslAltNameToCheck = NAME-OF-MY-DEPLOYMENT-SERVER

This is all straightforward enough.


Question 1: is the above correct and complete?


The docs for sslCommonNameToCheck state:

This feature does not work with the deployment server and client communication over SSL.

Question 2: is that supposed to mean that sslCommonNameToCheck is not supported on the Deployment Server? In that case, it would not matter for this scenario, as long as it is honored on the Deployment Client.

0 Karma