Présentation des principes de sécurité¶
Sont documentés ici différents principes avancés de sécurité incorporés dans WAPT.
La lecture de cette documentation n’est pas indispensable pour utiliser WAPT ; elle est cependant recommandée pour vous permettre de mieux comprendre certains choix architecturaux.
Préambule et définitions¶
Attention
Le service WAPT fonctionne en compte système privilégié.
Attention
A partir de la version 1.5 de WAPT, le répertoire d’installation par défaut devient C:\Program Files (x86)\wapt.
Indication
les sous-composantes wapttray, waptservice et waptexit de l’agent WAPT peuvent être optionnellement désactivées en fonction du contexte d’usage.
Périmètre à sécuriser¶
Les éléments à sécuriser qui concernent strictement WAPT sont :
The WAPT Server (waptserver).
The WAPT agents (wapt-get) and its sub-components (wapttray, waptservice et waptexit).
The management console (waptconsole).
The network communications between these different components.
En complément des éléments listés ci-dessus, un exploitant de WAPT devra choisir et suivre une méthodologie adaptée au contexte de son Organisation pour :
Insure the safe provisioning of all other files that are to be incorporated into a WAPT package.
Develop the WAPT package python
setup.pyscript so as to avoid any exploitable security or confidentiality defect.Manage in a safe way the private keys for signing the packages.
Manage in a safe way the Authorities of Certification and Revocation for the SSL and HTTPS certificates.
La gestion sûre de ces éléments complémentaires est exclue du périmètre de cette documentation.
Description des utilisateurs typiques¶
Les rôles suivants doivent être compris pour évaluer les principes de sécurité présents dans WAPT :
Utilisateur
A User is an individual/ user of a WAPT equipped end-device (Enterprise and Discovery).
Déployeur de Paquet
A Package Deployer is an individual with the ability to sign packages that DO NOT contain python code (generally group, host and unit packages) and with the ability to upload the package to the main repository (Enterprise).
Développeur de Paquet
A Package Developer is an individual with the ability to sign any package, may it include or not include python code, and to upload the package to the main repository (Enterprise);
Note
The distinction between Package Deployer and Package Developer only exists in the Enterprise version of WAPT.
SuperAdmin
The SuperAdmin is an individual with all rights within WAPT.
Administrateur Local
A Local Administrator is an individual with local administration right of the WAPT equipped end-devices (Enterprise and Discovery);
Note
En fonction du contexte de la documentation et de la version du produit, un Administrateur désignera un Déployeur de Paquet, un Développeur de Paquet ou bien le SuperAdmin.
Note
Les Utilisateurs membres du groupe de sécurité Active Directory waptselfservice sont considérés comme des Administrateurs Locaux du point de vue de la sécurité WAPT.
Description of the sensitive assets in WAPT¶
Par définition, un bien sensible est une donnée (ou fonction) jugée comme ayant de la valeur pour un attaquant.
Sa valeur est estimée selon des critères de sécurité (aussi appelés besoins de sécurité) :
Availability;
Integrity;
Confidentiality;
Authenticity.
Les biens sensibles à protéger sont les suivants :
Bien sensible B1 : Les communications¶
Les communications entre le serveur central et les agents ainsi que les communications entre la console et le serveur sont un bien sensible et doivent être protégées.
Note
Besoin de sécurité des communications
Integrity;
Confidentiality;
Authenticity.
Bien sensible B2 : Les données d’inventaire¶
Les informations sur l’état de déploiement des paquets, ainsi que configuration matérielle et logicielle des postes clients sont un bien sensible et doivent être protégées.
Note
Besoin de sécurité des données d’inventaire
Integrity;
Confidentiality.
Bien sensible B3 : Les journaux d’historique¶
Les journaux générés par WAPT sur le serveur central et les agents sont un bien sensible et doivent être protégés.
Note
Besoin de sécurité des journaux d’historique
Availability.
Bien sensible B4 : Les valeurs de configuration¶
Les valeurs de configuration du serveur (clés du serveur https, configuration accès à la base de données, configuration de l’authentification au serveur) sont un bien sensible et doivent être protégés.
Note
Besoin de sécurité des valeurs de configuration
Integrity;
Confidentiality.
Bien sensible B5 : Les exécutables WAPT installés sur les postes client¶
Les exécutables WAPT installés sur les postes client managés (contenu du répertoire wapt incluant les binaires, les dll, les fichiers de configuration et la base de données) sont un bien sensible et doivent être protégés.
Note
Besoin de sécurité des valeurs de configuration
Integrity.
Bien sensible B6 : L’authentification¶
Les données d’authentification à la console d’administration ainsi que les données d’authentification des agents sur le serveur (clé publique de chaque agent WAPT) sont un bien sensible et doivent être protégées.
Note
Besoin de sécurité de l’authentification
Integrity;
Confidentiality.
Description des hypothèses sur l’environment d’exploitation de WAPT¶
Par définition, les hypothèses sont des déclarations portant sur le contexte d’emploi de WAPT ou de son environment.
Les hypothèses suivantes sur l’environment d’exploitation de WAPT doivent être considérées :
Hypothèse H1 : Les Administrateurs et Déployeurs de Paquet WAPT sont formés¶
Les Administrateurs et les Développeurs de Paquets sont formés à l’usage de WAPT. En particulier, ils doivent s’assurer que leurs identifiants et clés de sécurité restent secrets.
Hypothèse H2 : Les systèmes subjacents à WAPT sont sains¶
Les systèmes d’exploitation sur lesquels les agents WAPT s’exécutent mettent en oeuvre des mécanismes de protection adéquats (confinement, contrôle d’accès, etc.) paramétrés et configurés selon les bonnes pratiques.
Les systèmes d’exploitation sont à jour des correctifs en vigueur au moment de l’installation, ils sont sains et exempts de virus, chevaux de Troie, etc.
Hypothèse H3 : Les binaires nécessaires au fonctionnement de WAPT sont intègres¶
Toutes les librairies et outils nécessaires au fonctionnement de WAPT sont considérées saines. A la réception d’une requête par l’agent WAPT, il vérifie que la requête est correctement signée.
Hypothèse H4 : Les paquets WAPT sont construits de manière sûre¶
Il est de la responsabilité de l”Administrateur de s’assurer que les fichiers destinés à être intégrés dans des paquets WAPT proviennent de sources sûres et sont en particuliers exempts de virus, chevaux de Troie, etc.
Hypothèse H5 : Les Utilisateurs des postes client ne sont pas Administrateurs Locaux¶
Un Utilisateur n’a pas les droits d’administration de son poste de travail. Sinon l”Utilisateur est considéré comme un Administrateur Local.
En particulier, l”Utilisateur n’a pas les droits d’écriture dans le répertoire d’installation du client WAPT.
Hypothèse H6 : Les Administrateurs Locaux des postes client sont formés¶
L”Administrateur Local d’un poste client doit être formé à l’exploitation de WAPT, ou à défaut ne pas modifier les fichiers d’installation se trouvant dans le dossier d’installation de WAPT.
Description des menaces pesant sur les biens sensibles WAPT¶
Par définition, une menace est une action ou un événement susceptible de porter préjudice à la sécurité globale de la machine équipée de WAPT.
Les agents menaçants à considérer pour l’évaluation de sécurité sont les suivants :
Unauthorized entities: it is a human attacker or an entity that interacts with WAPT without legitimately having access to it.
Note
Les Administrateurs et les Administrateurs Locaux ne sont pas considérés comme des attaquants.
Les menaces qui portent sur les biens sensibles WAPT définis ci-dessus sont les suivantes :
Description des fonctions de sécurité de WAPT¶
Par définition, les fonctions de sécurité sont l’ensemble des mesures techniques et mécanismes mis en œuvre pour protéger de façon proportionnée les biens sensibles contre les menaces identifiées.
Fonction de sécurité F1 : Authentification des contrôles d’accès¶
Fonction de sécurité F1A : Authentification d’une machine lors de son enregistrement initial dans la base de données WAPT¶
Nouveau dans la version 1.5.
Note
risques traités
The registering of an illegitimate device in the database.
A denial-of-service attack by overloading the database.
The insertion of a fraudulent inventory in the database.
Solution mise en place¶
Pour exister dans la base de données et ainsi apparaître dans la console WAPT, une machine doit s’enregistrer auprès du serveur WAPT avec une commande register.
La commande register peut être exécutée automatiquement lors de l’installation ou de la mise à jour de l’agent WAPT si la machine est correctement enregistrée avec un compte machine Kerberos dans le domaine Active Directory de l”Organisation.
Si la machine ne présente pas au serveur WAPT un ticket Kerberos valide, alors la commande register échoue;
Note
La méthode avec Kerberos assume que le serveur Active Directory répond au moment du register.
Fonction de sécurité F1B : Vérification des certificats HTTPS du serveur par les clients WAPT¶
Nouveau dans la version 1.5.
Note
risques traités (notamment MITM) :
The sending of sensitive informations to an illegitimate and unauthorized WAPT Server.
The recovery of sensitive informations by an unauthorized entity.
The display of fake information in the management console of the Administrator.
An incorrect date to be sent upon a HEAD request, thus preventing future upgrades (request for a modified file date).
Sending the WAPT console password to an illegitimate and unauthorized WAPT Server.
Solution mise en place¶
Pour fonctionner correctement en version sécurisée :
An option for verifying the server HTTPS certificate is introduced in
C:\Program Files (x86)\waptwapt-get.inion the WAPT agents that will force the verification of the server certificate by the WAPT agents.An option for verifying the server HTTPS certificate is introduced in
C:\Program Files (x86)\waptwapt-get.inion the WAPT agents that will force the verification of the server certificate by the WAPT console.
L’implémentation technique peut être basée sur deux méthodes :
By using a certificate verification tool implemented in the configuration file of WAPT’s Nginx web server; this method is typically provided by a Certificate Authority that is trusted by your network.
By using the certificate pinning method, which consists of providing the WAPT agent a short list of trusted certificates that will be stored in
C:\Program Files (x86)\wapt\ssl\server.
Fonction de sécurité F1C : Aucun port n’écoute sur les agents WAPT¶
Nouveau dans la version 1.5.
Note
risques traités
An unauthorized entity using an open port fraudulently.
Solution mise en place¶
Les connexions vers le serveur WAPT sont exclusivement initiées pas les clients, et les différentes actions instantanées (update / upgrade / install …) passent au travers d’une connexion permanente par une Websocket initiée par l’agent WAPT.
Note
si HTTPS est activé, l’agent vérifie que la Websocket s’établit bien avec le bon serveur.
Fonction de sécurité F1D : Signature des remontées d’inventaire¶
Nouveau dans la version 1.3.12.13.
Note
risques traités
An unauthorized entity sending a fake inventory for a device that rightfully exists in the database.
Solution mise en place¶
On the first register, each device generates a key/ certificate pair that is stored in
C:\Program Files (x86)\wapt\private, only accessible in read-only mode to Local Administrators. Once the device has successfully registered, the public key is sent to the WAPT Server.When the inventory is updated, the new inventory status is sent along with the private key of the device. The new inventory is then decrypted with the public key stored in the database.
The server will refuse any inventory that is signed with a wrong key.
Fonction de sécurité F2 : Protection de l’intégrité du processus d’installation des paquets WAPT¶
Fonction de sécurité F2A : Signature des paquets WAPT¶
Note
risques traités
To avoid an unauthorized entity modifying the content or the behavior of a WAPT package.
Solution mise en place¶
When an Administrator or a Package Deployer builds a WAPT package, the file
manifest.sha256is created that lists the control sums of all files in the package.A file
signature.sha256encrypted with the WAPT agent’s private key is then created in the folderWAPT; it contains the control sum of the filemanifest.sha256.The whole is then compressed and suffixed with a .wapt extension.
When a WAPT agent downloads a WAPT package, the agent checks that the file
signature.sha256has been signed with the private key that matches the certificate present in the folderWAPT.The WAPT agent then checks that the certificate or the chain of certificates in
certificate.crthas been signed with a key matching one of the certificates present in the folderC:\Program Files (x86)\wapt\ssl.The WAPT agent then generates the control sum of all the files contained in the package (except the files
signature.sha256andcertificate.crt) and verifies that it matches the filemanifest.sha256contained in the package.If one of these steps does not pass, this means that a file has been modified/ added/ removed. The execution of the
setup.pyis then canceled.The altered package is then deleted from the local cache and the event is journalized in the logs of the agent.
Note
Depuis la version 1.5, le fichier manifest est passée de sha1 à sha256.
Fonction de sécurité F2B : Signature des attributs du fichier control¶
Nouveau dans la version 1.4.
Note
risques traités
An unauthorized entity modifying WAPT dependencies on WAPT equipped devices by falsifying
https://waptserver/wapt/Packages.
Solution mise en place¶
Lors de la signature d’un paquet WAPT, les attributs sensibles du paquet sont listés dans l’attribut signed_attributes.
Note
Exemple d’une liste signed_attributes :
package, version, architecture, section, priority, maintainer, description, depends, conflicts, maturity, locale, min_os_version, max_os_version, min_wapt_version, sources, installed_size, signer, signer_fingerprint, signature_date, signed_attributes,
Les attributs listés dans signed_attributes sont signés avec la clé privée de l”Administrateur et la signature est stockée dans l’attribut signature du fichier control.
Le certificat associé à cette clé privée est stocké dans le fichier WAPT\certificate.crt à l’intérieur du paquet WAPT.
Sur le serveur WAPT, lors de l’opération wapt-scanpackages (déclenchée par un ajout ou suppression de paquet), l’index Packages des paquets est régénéré.
Le serveur WAPT extrait de chaque paquet le certificat du signataire et l’ajoute dans le fichier ZIP Packages, dans le répertoire ssl. Chaque certificat est nommé avec sa fingerprint encodée en hexadécimal.
Lorsque le client WAPT effectue un update (mise à jour des paquets disponibles), il télécharge le fichier index Packages, qui contient à la fois les attributs signés de tous les paquets et les certificats des signataires.
Si le certificat du signataire des attributs d’un paquet est approuvé (ce qui signifie que ce certificat est signé par une Autorité de Certification ou que le certificat lui-méme est de confiance), ET que le certificat du signataire peut vérifier la signature des attributs, le paquet est ajouté à l’index des paquets disponibles, sinon il est ignoré.
Fonction de sécurité F2C : Restriction d’accès au répertoire d’installation de l’agent WAPT¶
Note
risques traités
An unauthorized entity modifying the behavior of a WAPT agent.
Le répertoire d’installation C:\Program Files (x86)\wapt est accessible en lecture et modification :
To the Local Administrators by direct access to the installation folder of the WAPT agent on the device.
To the Administrators through the deployment of WAPT agent upgrades.
Ni les Développeurs de Paquets, ni les Utilisateurs n’ont d’accès en écriture au répertoire d’installation de l’agent WAPT.
Fonction de sécurité F2D : Restriction totale d’accès au répertoire de stockage du couple clé privé / certificat de signature d’inventaire¶
Note
risques traités
An unauthorized entity falsifying an inventory status update.
An unauthorized entity impersonating the identity of a WAPT equipped device.
Aucun droit d’accès au répertoire C:\Program Files (x86)\wapt\private n’est accordé à aucun Utilisateur, quel qu’il soit. Seul l’agent WAPT a accès en lecture et écriture à ce répertoire.
Note
Le stockage du couple clé privée / certificat découle d’un choix technique qui consiste à dire que la machine détient seule toutes les informations qui la concernent.
Fonction de sécurité F3 : Sécurisation des communications entre les différents composants WAPT¶
Fonction de sécurité F3A : Signature des requêtes envoyées aux agents WAPT¶
Nouveau dans la version 1.5.
Note
risques traités
An unauthorized entity sending falsified requests to the WAPT agents.
Solution mise en place¶
Les commandes ci-dessous sont signées par le serveur WAPT avant d’être envoyées au travers de la Websocket à l’agent WAPT destinataire de la commande :
wapt-get install: requests the WAPT agent to install a WAPT package flagged as MISSING.wapt-get remove: requests the WAPT agent to remove a package.wapt-get forget: requests the WAPT agent to forget the existence of a previously installed WAPT package without removing the software or the configuration.wapt-get update-status: requests the WAPT agent to send its current inventory status to the WAPT Server.wapt-get upgrade: requests the WAPT agent to execute a package flagged as NEED UPGRADE.wapt-get update: requests the WAPT agent to update the list of available packages.
L’ensemble des attributs de cette requête sont signés :
The device’s UUID;
The action (ex: install);
The arguments (ex: tis-firefox);
The timestamp of the requests.
Le certificate associé à la signature est également passé :
Upon receiving a request, the WAPT agent verifies that the request has been properly signed.
The agent will the verify that the timestamp is within a one minute delay window.
Ultimately, the agent will verify that the certificate is authorized to launch actions.
Présentation des processus cryptographiques¶
Date |
janv. 09, 2024 |
Rédacteur |
Hubert TOUVET |
Applicable pour WAPT |
>= 1.5.0.17 |
Version du document |
1.5.0.17-0 |
Les processus cryptographiques sont utilisés dans les activités suivantes :
Signature and verification of the files contained in a package.
Signature and verification of the attributes of a package.
Signature and verification of instantaneous actions on the WAPT clients.
Signature of inventories and status of WAPT clients.
Authentication of the WAPT client Websocket connections on the WAPT server.
HTTPS communication between the WAPT clients and the WAPT Server.
HTTPS communication between the WAPT console and the WAPT Server.
HTTPS communication between the WAPT clients and the WAPT repositories.
Répertoires et fichiers référencés dans ce document¶
<WAPT>: WAPT installation folder. By default%Program Files (x86)%WAPT.<WAPT>wapt-get.ini: WAPT client configuration file (wapt-get and waptservice).<WAPT>ssl: default directory for signed actions and trusted certificates.<WAPT>sslserver: default directory for storing HTTPS server certificates (pinning).<WAPT>private: default certificate directory for signing the inventory and the Websocket connections.%LOCALAPPDATA%waptconsolewaptconsole.ini: configuration file for the console and package development actions for the wapt-get tool.%appdata%waptconsolessl: default trusted certificate directory for importing packages from an external repository (i.e. package templates).
Definitions of Actors¶
Organisation
An Organization is the realm of responsibility within which WAPT is used.
Autorité de Certification
A Certificate Authority is the entity that keeps the keys that have been used to sign certificates for the Package Developers, the Package Deployers and the HTTPS servers.
Administrateurs
Administrators have a personal RSA key and a certificate that has been signed by the Certificate Authority of the Organization; they also have a login and a password for accessing the WAPT console.
Postes clients WAPT
WAPT clients are the realm of devices that the Organization has allowed the Administrators to manage with WAPT. The clients may or may not be a member of the Organization’s Active Directory domain.
Serveur WAPT
The WAPT Server is the Linux / Nginx/ PostgreSQL that the Organization uses to keep the inventory of WAPT equipped devices.
Par défaut, le serveur WAPT joue également le rôle de dépôt WAPT interne. Le serveur WAPT a un compte ordinateur dans l’Active Directory de l”Organisation.
Dépôts WAPT internes
Internal WAPT repositories are one or several Linux/ Nginx servers that deliver signed WAPT packages to WAPT clients using the HTTPS protocol.
External WAPT repositories
External WAPT repositories are a public WAPT repository that the Package Developers may use to import packages designed by other Organizations, under the condition that they check the adequacy of the WAPT package in regards the internal policies on security and safety;
Serveur Active Directory
The Active Directory Server manages the Organization’s AD domain;
Synthèse des modules crypto mis en oeuvre par la solution WAPT¶
À faire
sfonteneau
Coté client WAPT (WAPT 1.5.0.12) :
Python 2.7.13 standard ssl module linked on OpenSSL 1.0.2j 26 Sep 2016: used for the HTTPS connections between the WAPT clients and the WAPT server.
cryptography==1.9 linked on openssl 1.1.0f: used for all RSA crypto operations such as key generations, X509 certificate generations and signature verifications.
kerberos-sspi==0.2 and requests-kerberos==0.11.0: used for authenticating the WAPT client on its first registering on the WAPT Server.
pyOpenSSL==17.0.0: used to recover the WAPT Server certificate chain.
certifi==2017.4.17: used as base for the Root Authorities certificates.
Openssl 1.0.2l dll: used in waptcommon.pas written with the FPC Indy library and the TIdSSLIOHandlerSocketOpenSSL class.
Coté serveur WAPT :
nginx/1.10.2: configured for TLS1.2, cipher “EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH”.
python 2.7.5 standard ssl module linked on OpenSSL 1.0.1e-fips 11 Feb 2013.
cryptography==1.9 linked on OpenSSL 1.0.1e-fips 11 Feb 2013: used for all RSA crypto operations such as key generations, X509 certificate generations and signature verifications.
Key and certificate management for the Administrators¶
Les paquets et actions de l”Administrateur sont signés pour n’autoriser que les Administrateurs de confiance à intervenir sur les postes.
L”Administrateur de la solution WAPT a en sa possession :
A private 2048 bit RSA key that has been encrypted by the aes-256-cbc algorithm.
A X509 certificate signed by an Certificate Authority trusted by the Organization.
Note
Le processus d’émission de ces clés, la signature du certificat, la distribution et la révocation sont à la charge de l”Organisation utilisant WAPT et sortent donc du périmètre fonctionnel de WAPT.
Cependant, pour facilement tester la solution, WAPT propose une fonction pour générer une clé RSA et un certificat X509 :
The generated RSA key is 2048bit long, encrypted with aes-256-cbc, encoded in PEM format and saved with a .pem extension.
The certificate is either self-signed, or signed by a Trusted Authority from whom we have received a key and a PEM formated certificate.
If the certificate is self-signed, then its KeyUsage attribute contains the keyCertSign flag.
If the Administrator is authorized by the Organization to sign packages that contain python code (the presence of a
setup.pyfile is detected in the package), the extendedKeyUsage attribute of the certificate contains the CodeSigning flag.The X509 certificate is encoded and handed over to the Administrator in PEM format with a .crt extension.
Validité du certificat de l’Administrateur¶
Jusqu’à la version 1.5.0.12 incluse, Le client WAPT ne gère pas la vérification de la révocation du certificat de l”Administrateur lors du processus de vérifcation des paquets, attributs et actions de l”Administrateur.
Il ne vérifie que les dates de validité (attributs notValidBefore / notValidAfter). Le certificat est valide si (Now >= notValidBefore et Now <= notValidAfter).
Managing the WAPT agent’s key and certificate¶
Le client WAPT (waptservice) utilise des clés RSA et un certificat X509 pour interagir avec le serveur WAPT.
Le certificat du client WAPT est utilisé dans les situations suivantes :
When updating the WAPT client status on the server (update_server_status) signing informations.
When the WAPT agent establishes a Websocket with the server (waptservice) signing the WAPT client UUID.
Émission initiale et mise à jour du certificat du client WAPT¶
On finishing the installation process of the WAPT agent on the device, the WAPT agent automatically registers itself on the WAPT Server by sending a kerberos authenticated HTTPS request that uses the TGT of the machine account.
L’agent WAPT utilise les API kerberos de Windows en s’appuyant sur les modules python kerberos-sspi et requests-kerberos ;
Note
Cette procédure fonctionne si et seulement si le Poste client est joint au domaine Windows pour lequel le serveur WAPT est configuré.
If the key and the certificates have not yet been generated, or if they do not match the current FQDN of the device, the WAPT agent generates a self-signed RSA key and X509 certificate with the following parameters:
The key is 2048 bit RSA encoded in PEM format and stored in the file
<WAPT>private<device FQDN>.pem.The generated certificate has the following attributes:
Subject.COMMON_NAME = <device FQDN>.
Subject.ORGANIZATIONAL_UNIT_NAME = name of the Organization registered in the WAPT client’s Windows registry.
SubjectAlternativeName.DNSName = <device FQDN>.
BasicConstraint.CA = True.
Validity = 10 years.
Serialnumber = random;
The certificate is saved in the
<WAPT>private<device FQDN>.crt.Note
Seuls le compte machine et les Administrateurs Locaux ont accès au répertoire
<WAPT>\privatecar des ACL spécifiques sont appliquées à l’installation de l’agent WAPT sur le poste.The inventory and the WAPT agent status updates are sent to the WAPT Server over POST HTTPS requests;
The POST HTTPS requests are authenticated by adding two specific headers:
X-Signature :
JSON encoded BLOB of inventory or status informations.
signature of the JSON file with the private key of the WAPT Client: sha256 hashing and PKCS#1 v1.5 padding.
base64 encoding of the signature.
X-Signer: Subject.COMMON_NAME ou UUID du client WAPT.
After having initially authenticated the WAPT client with kerberos, the WAPT Server receives the certificate sent by the Client and stores it in the table hosts of its inventory in PEM format (column host_certificate).
Note
Si le poste client WAPT est renommé, la paire de clés et le certificat sont recréés.
Lors de la tentative de mise à jour de status du client vers le serveur, la requête POST sera refusée, car la machine est enregistrée dans la base de données avec un autre certificat.
La machine tentera alors de se ré-enregistrer (register) avec authentification kerberos ; ainsi le nouveau certificat sera enregistré dans la base de données.
Communications HTTPS entre les clients WAPT et les dépôts WAPT¶
Communications Websockets entre les clients WAPT et le serveur WAPT¶
Pour permettre des actions immédiates sur les clients WAPT, le service WAPT déployé sur les clients tente d’établir et de maintenir une connexion Websocket vers le serveur WAPT.
Cette connexion s’effectue sur un connexion chiffrée avec le protocole TLS et utilise côté client le même bundle de certificat que la connexion HTTPS Client vers Serveur WAPT.
Communications entre la console WAPT et le serveur WAPT¶
Déployer des certificats d’autorité¶
Paramètre verify_cert de la section [global] du fichier %LOCALAPPDATA%waptconsolewaptconsole.ini :
verify_cert = 1
Vérifie le certificat du serveur https en utilisant le bundle fourni par le module certifi. Ne fonctionnera bien que si le serveur https est configuré pour renvoyer son certificat et les certificats intermédiaires à l’initialisation de communication TLS ;
verify_cert = <chemin vers fichier .pem>
Vérifie le certificat du serveur https en utilisant le bundle de certificats indiqué. Tous les certificats de CA intermédiaires et root doivent être rassemblés dans un fichier au format .pem ;
verify_cert = 0
Ne pas vérifier le certificat du serveur https ;
Conventionnellement, on stocke le bundle de l”Autorité de Certification approuvées dans le répertoire <WAPT>sslserver.
La console WAPT comporte une fonction pour faciliter la récupération initiale de la chaîne de certificats du serveur et la stocker au format .pem dans le fichier <WAPT>sslserver<FQDN serveur>.
Il est de la responsabilité de l”Administrateur de s’assurer que la chaîne ainsi récupérée est authentique.
Il est également possible de récupérer la chaîne de certificats du serveur et de renseigner le paramètre verify_cert avec la commande wapt-get enable-check-certificate.
Processus de signature d’un paquet¶
Le processus de signature du paquet est lancé lors des actions suivantes :
action
wapt-get.exe build-upload <directory>.action
wapt-get.exe sign-package <path-to-package-file.wapt>.shell command
wapt-signpackage.py <WAPT-package-list>.saving a host package in the WAPT console.
saving a group package in the WAPT console.
importing a package from an external repository.
creating a package with the MSI setup wizard.
Paramètres initiaux¶
fichier ZIP du paquet ;
clé privée RSA du signataire encodée en format .pem et chiffrée (par l’algorithme aes-256-cbc de openssl si la clé a été créée dans la console WAPT) ;
certificat X509 du signataire correspondant à la clé privée ;
si le paquet à signer contient un fichier
setup.py, le certificat X509 doit avoir l’extension advanced Key Usage : codeSigning (1.3.6.1.5.5.7.3.3) ;
Signing the attributes in the control file¶
Le fichier control d’un paquet décrit les métadonnées du paquet, en particulier son nom, sa version, ses dépendances et ses conflits. C’est la fiche d’identité du paquet.
Ces métadonnées sont primitivement utilisées par l’agent WAPT pour déterminer si un paquet doit être mis à jour, et quels autres paquets doivent être installés ou désinstallés préalablement.
Ces informations sont donc signées pour garantir aux Postes client leur intégrité et leur authenticité.
Etapes du processus :
The attributes signed_attributes, signer, signature_date, signer_fingerprint are added to the structure of the
controlfile:signed_attributes : liste des noms d’attributs avec séparateur virgule (,) ;
signer : commonName de l’objet du certificat du signataire ;
signature_date : date et heure en cours (UTC) sous la forme “%Y-%m-%dT%H:%M:%S” ;
signer_fingerprint: hexadecimal encoded
sha256fingerprint of the fingerprint obtained with the fingerprint function included in the cryptography.x509.Certificate class.
The attributes of the control structure are JSON encoded.
The resulting JSON BLOB is signed with sha256 hashing and PKCS#1 v1.5 padding.
The signature is base64 encoded and stored as a signature attribute in the
controlfile.
Signature des fichiers du paquet¶
The
controlfile attributes are signed and serialized in JSON format. The result is stored in the<WAPT>controlfile of the WAPT package.The PEM serialized X509 certificate of the certificate holder is stored in the
<WAPT>certificate.crtfile of the WAPT package.The sha256 fingerprints of the all files contained in the WAPT package are hexadecimal encoded and stored as a JSON list [(filename,hash),] in the
<WAPT>manifest.sha256file in the WAPT package.The content of the file
<WAPT>manifest.sha256is signed with the private key of the Administrator (2048 bit RAS key), sha256 hashed and PKCS#1 v1.5 padded:The signature process relies on the signing function of the cryptography.rsa.RSAPrivateKey.signer class.
cryptography.rsa.RSAPrivateKey.signer relies on the OpenSSL functions of EVP_DigestSignInit.
The signature is base64 serialized and stored in the file
<WAPT>signature.sha256of the WAPT package.
Vérifier la signature des attributs d’un paquet¶
Elle a lieu :
When the index file of available packages on the WAPT client is updated from the
Packagesindex file on the repository.When a package signature is verified (installation, download) when not in development mode, i.e. if the installation takes place from a ZIP file and not from a development directory.
Elle consiste à :
Reading the control attributes from the WAPT package’s
controlfile.Recovering the X509 certificate from the certificate holder from the WAPT package’s
certificate.crtfile.Decoding the base64 formated signature attribute.
Constructing a JSON structure with the attributes to be signed (such as defined in the PackageEntry class).
Verifying if the public key of the holder’s certificate can verify the hash of the JSON structured list of attributes and the signature of the
controlfile, using sha256 hashing and PKCS#1 v1.5 padding.Verifying whether the certificate is trusted (either it is present in the list of trusted certificates, or signed by a Trusted Certificate Authority).
Dans le cas où nous devons vérifier les attributs sans avoir le paquet WAPT à disposition, nous récupérons la liste des certificats des détenteurs potentiels de certificats à partir du fichier d’index Packages sur le dépôt WAPT. Les certificats sont nommés ssl/<hexadecimal formated certificate fingerprint>.crt.
Un attribut de la structure control du paquet indique l’empreinte du certificat du signataire du fichier control.
Vérifier la signature d’un paquet¶
Elle a lieu :
When installing a package on a WAPT client.
When editing an existing package.
When importing a package from an external repository (if the checkbox is checked in the WAPT console).
Elle consiste à :
Recovering the X509 certificate from the certificate holder from the WAPT package’s
certificate.crtfile.Verifying that the certificate has been signed by a Trusted Authority whose certificate is present in the folder
sslon the WAPT client.Verifying the signature of the file
manifest.sha256with the public key.
Signature d’une action immédiate¶
Depuis la console, les Administrateurs peut déclencher des actions directes sur le client WAPT, s’il est connecté au serveur par le mode Websockets.
La console WAPT signe ces actions avec la clé et le certificat de l”Administrateur avant de les envoyer au serveur WAPT en utilisant une requête HTTPS POST ; la requête est ensuite transmise aux clients WAPT ciblés.
Les actions possibles sont :
trigger_host_update.
trigger_host_upgrade.
trigger_install_packages.
trigger_remove_packages.
trigger_forget_packages.
trigger_cancel_all_tasks.
trigger_host_register.
Processus de signature¶
The action is defined by its name and the actions attributes. The attributes are uuid, action, force, notify_server, and packages (for actions implicating a list of packages).
The attributes signed_attributes, signer, signature_date, signer_certificate are added to the structure of the action:
signed_attributes list of the attributes that are signed.
signer Subject.COMMON_NAME of certificate holder.
signature_date: current date and time (UTC) in “%Y-%m-%dT%H:%M:%S” format.
signer_certificate certificate holder’s base64 encoded X509 certificate.
The structure is JSON encoded.
The signature of the JSON file is calculated from the RSA private key of the signer using a sha256 hash algorithm and a PKCS1 v1.5 padding.
The signature is base64 encoded and stored on the signature attribute inside the JSON file.
Vérifier la signature d’une action immédiate¶
Depuis la console, les Administrateurs peut déclencher des actions directes sur le client WAPT, s’il est connecté au serveur par le mode Websockets.
Les actions sont encodées en JSON, signées avec la clé et le certificat de l”Administrateur et relayées vers le client WAPT visé par le serveur WAPT.
Les actions possibles sont :
trigger_host_update.
trigger_host_upgrade.
trigger_install_packages.
trigger_remove_packages.
trigger_forget_packages.
trigger_cancel_all_tasks.
trigger_host_register.
L’action get_tasks_status ne demande pas d’authentification ssl.
Sur réception d’un évènement par la connexion Websocket du client WAPT :
The X509 certificate of the certificate holder is extracted from the JSON file (format PEM).
The WAPT client tests whether the certificate is to be trusted, i.e. that it is present in
<WAPT>sslor that it has been signed by a Trusted Authority (certificate of the Authority present in<WAPT>ssl).The WAPT client checks whether the certificate can verify the signature that is present in the JSON structure of the action, which consists of:
Extracting the base64 encoded signature from the signature attribute in the JSON file;
Extracting the signature date formated in “%Y-%m-%dT%H:%M:%S” from the signature_date attribute;
Checking that the signature date is neither too old in the past, nor too late into the future by over 10 minutes;
Reconstructing a JSON representation of the attributes of the action;
Checking that the certificate’s public key can verify the JSON file with the signature by using a sha256 hash algorithm and a PKCS1 v1.5 padding.
Verifying the complete download of a package¶
Pour chaque paquet, une somme md5 du paquet est calculée et disponible dans l’index Packages du dépôt.
Lors de l’installation d’un paquet, le client vérifie si le paquet est déjà disponible localement dans le répertoire <WAPT>\cache.
Si le fichier est présent, sa somme md5 est comparée avec la somme md5 présente dans l’index. Si elles diffèrent, le paquet en cache local est effacé.
This md5 sum is only used to insure that a package has been fully downloaded.
The checking of the signature of the package will be used instead of the md5 sum to fully insure the integrity and the authenticity of the WAPT package.