[RESOLVED] Deployment of secrets on stations equipped with a WAPT agent

[croquebert]

Hello everyone,

Context:
Remote work without a VPN
WAPT version: 2.1 Enterprise
Server OS: Debian 11
Administration console OS: Win10pro
Package development workstation OS: Win10pro


We have a classic use case:

We would like to send or update a separate secret for each workstation managed using WAPT, while preserving the confidentiality of this secret between workstations (one workstation cannot acquire the secret of another).

One solution (1) would be to create a separate package for each workstation containing the secret to be deployed and associate it with the relevant workstation (taking care to secure the secret by following the guidelines at https://www.wapt.fr/fr/doc/wapt-create- ... pt-package ). However, this quickly becomes tedious when the number of workstations is large and the update frequency is high.

Another solution (2) would be to create a generic package that detects the relevant workstation and retrieves this secret from a protected location. But how can we access only the secret corresponding to the workstation without deploying another secret beforehand?

Another solution (3) would be to automate the creation and updating of packages for solution (1). This generation is performed on a workstation capable of signing packages (a WAPT development workstation outside the main workstation with a dedicated WAPT administration console).

Another solution (4) would be to push the secret to a given location on the workstation via an established bidirectional channel (websocket agent?) and then install a WAPT package that handles this secret directly on the workstation. But how do we push the secret to the target's file system via this channel?

Have you ever encountered this situation, and if so, how did you handle it?

Christophe

[vcardon]

One solution (1) would be to create a separate package for each workstation containing the secret to be deployed and associate it with the relevant workstation (taking care to secure the secret by following the instructions at https://www.wapt.fr/fr/doc/wapt-create- ... pt-package ). However, this quickly becomes tedious when the number of workstations is large and the update frequency is high.

This is the only good method if you want to ensure perfect security for your secrets, but it does lack an assistant to make the task less laborious.

You are the second person to raise this issue with us, so it's encouraging to know that this very useful feature is... being used.

I will pass your comment on to the development teams.

[sfonteneau]

It would be interesting to know the exact requirement

For example, we could also let the workstation choose its secret key (symmetric?) and let the workstation send the information back to the admin in encrypted form, in the case of a password for example:

Code: Select all

# -*- coding: utf-8 -*-
from setuphelpers import *
from waptcrypto import print_encrypted_data

def install():
    randompassword = 'password'
    print_encrypted_data(randompassword,glob.glob(('*.crt'))) 

- But that doesn't necessarily meet the need.

- Solution 3 would be possible but requires that a machine with the private key remain on (not the server) to recreate the packet from time to time.

In Python, we could also do some update_package functions like this:

Go get an Excel file from a share that represents a mapping of the workstation name -> key, (or last user logged on the machine or something else... something from the workstation inventory) and encrypt different data depending on the workstation.

This is the 1/3 mixed method (to update the package you will just need to relaunch the package update in the GUI from the console)

[croquebert]

One solution (1) would be to create a separate package for each workstation containing the secret to be deployed and associate it with the relevant workstation (taking care to secure the secret by following the instructions at https://www.wapt.fr/fr/doc/wapt-create- ... pt-package ). However, this quickly becomes tedious when the number of workstations is large and the update frequency is high.

This is the only good method if you want to ensure perfect security for your secrets, but it does lack an assistant to make the task less laborious.

You are the second person to raise this issue with us, so it's encouraging to know that this very useful feature is... being used.

I will pass your comment on to the development teams.

Hello Vincent,

Thank you for your feedback.

Indeed, one package per affected workstation would improve security. The missing mechanisms are for automating the creation, updating, and association of these packages with the target workstations (although this should be possible to automate with...) https://www.wapt.fr/en/doc/wapt-command ... t-packages).

Solution (4) suggested masking the complexity of creating the package containing the secret by offering in the WAPT interface a push-type functionality on the target's file system (a kind of reverse file copy GPO).

But I have what I need to get started.

Christophe

[croquebert]

It would be interesting to know the exact requirement

For example, we could also let the workstation choose its secret key (symmetric?) and let the workstation send the information back to the admin in encrypted form, in the case of a password for example:

Code: Select all

# -*- coding: utf-8 -*-
from setuphelpers import *
from waptcrypto import print_encrypted_data

def install():
    randompassword = 'password'
    print_encrypted_data(randompassword,glob.glob(('*.crt'))) 

- But that doesn't necessarily meet the need.

- Solution 3 would be possible but requires that a machine with the private key remain on (not the server) to recreate the packet from time to time.

In Python, we could also do some update_package functions like this:

Go get an Excel file from a share that represents a mapping of the workstation name -> key, (or last user logged on the machine or something else... something from the workstation inventory) and encrypt different data depending on the workstation.

This is the 1/3 mixed method (to update the package you will just need to relaunch the package update in the GUI from the console)

Hello Simon,

Thank you for your feedback.

The underlying idea is the updating of a configuration file containing a secret (e.g., VPN).

I'm going to use a single package that will encrypt each machine's secret using its certificate via an `update_package`. This package will contain the secrets of each machine, but encrypted. Each secret will only be readable by the authorized machine (this is essentially what the example in your documentation does).

I see at least two drawbacks to this method:

• An update_package will force the update on machines where the secret has not necessarily changed.

• All the secrets, even encrypted ones, are contained in a single package.

Question: What is the default encryption algorithm?

Christophe

[sfonteneau]

• An update_package will force the update on machines where the secret has not necessarily changed.

If there is no increment in the package version, that's fine
The packet should fail if the UUID of the host is not in the encrypted data

• All the secrets, even encrypted ones, are contained in a single package.

Yes, but it's only readable by the machine that has its key; secondary repositories and the server itself won't be able to read the package. (Note, however, that we're relying on the machine's inventory on the server...)

Question: What is the default encryption algorithm?

with encryption: RSAES-OAEP
with encrypt_fernet: 128-bit AES in CBC mode and PKCS7 padding, with HMAC using SHA256 for authentication