Présentation des processus cryptographiques

Date

avr. 08, 2021

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 et vérification des fichiers d’un paquet ;

  • signature et vérification des attributs d’un paquet ;

  • signature et vérification des actions immédiates sur les client WAPT ;

  • signature des inventaires et statut des clients WAPT ;

  • authentification de la connexion Websockets du client WAPT sur le serveur ;

  • communication https entre les clients WAPT et le serveur WAPT ;

  • communication https entre la console WAPT et le serveur WAPT ;

  • communication https entre les clients WAPT et les dépôts WAPT ;

Répertoires et fichiers référencés dans ce document

  • <WAPT> : répertoire d’installation de WAPT. Par défaut %Program Files (x86)%WAPT ;

  • <WAPT>wapt-get.ini : fichier de configuration du client WAPT (wapt-get et waptservice) ;

  • <WAPT>ssl : répertoire par défaut pour les certificats de confiance des paquets et actions ;

  • <WAPT>sslserver : répertoire par défaut pour stocker les certificats https du serveur (pinning) ;

  • <WAPT>\private : répertoire par défaut pour les certificats permettant de signer l’inventaire et les connexions Websocket ;

  • %LOCALAPPDATA%waptconsolewaptconsole.ini : fichier de configuration de la console et des actions de développement de l’outil wapt-get ;

  • %appdata%waptconsolessl : répertoire par défaut pour les certificats de confiance pour l’import de paquets depuis un dépot externe (c.à.d. les modèles de paquets) ;

Acteurs

  • Organisation

    il s’agit du périmètre de responsabilité dans lequel est exploitée la solution WAPT ;

  • Autorité de Certification

    elle détient les clés qui ont signé les certificats des Déployeurs de Paquets, et des serveurs HTTPS ;

  • Administrateurs

    ils sont en possession d’une clé RSA personnelle et d’un certificat signé par l”Autorité de Certification de l”Organisation ; ils ont aussi un identifiant et un mot de passe pour accéder à la console WAPT ;

  • Postes clients WAPT

    PC sous Windows à administrer pour lesquels les Administrateurs ont reçu l’accréditation de la part de l”Organisation. Les postes clients sont joints au domaine Active Directory de l”Organisation ;

  • Dépôts WAPT internes

    il s’agit d’un ou de plusieurs serveur Linux / Nginx qui diffusent aux Postes clients WAPT en HTTPS des paquets WAPT signés ;

  • Serveur WAPT

    il s’agit d’un serveur Linux / Nginx / PostgreSQL / WAPT de l”Organisation qui gère l’inventaire et le statut des postes clients WAPT.

    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 externes

    il s’agit de dépôts WAPT publics que les Déployeurs de Paquets peuvent utiliser pour importer des paquets conçus par d’autres Organisations, sous condition d’en vérifier l’adéquation aux normes internes de sûreté et de sécurité ;

  • Serveur Active Directory

    serveur gérant le domaine de l”Organisation ;

Synthèse des modules crypto mis en oeuvre par la solution WAPT

Coté client WAPT (WAPT 1.5.0.12) :

  • module ssl standard de Python 2.7.13 linké sur OpenSSL 1.0.2j 26 Sep 2016 pour les connexions https entre les clients WAPT et serveur WAPT ;

  • cryptography==1.9 linké sur openssl 1.1.0f pour toutes les opérations crypto RSA, génération de clés, de certificat X509, de signature et vérification ;

  • kerberos-sspi==0.2 et requests-kerberos==0.11.0 pour l’authentification du client WAPT lors de son enregistrement initial sur le serveur ;

  • pyOpenSSL==17.0.0 : pour récupérer la chaîne de certificats du serveur WAPT ;

  • certifi==2017.4.17 : base de certificats d’autorité racine ;

  • dll Openssl 1.0.2l pour la partie waptcommon.pas écrite avec la bibliothèque FPC Indy et la classe TIdSSLIOHandlerSocketOpenSSL ;

Coté serveur WAPT :

  • nginx/1.10.2: configurée pour TLS1.2, chiffre “EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH”;

  • module ssl standard de python 2.7.5 linké sur OpenSSL 1.0.1e-fips 11 Feb 2013 ;

  • cryptography==1.9 linké sur OpenSSL 1.0.1e-fips 11 Feb 2013 pour toutes les opérations crypto RSA, X509, signature et vérification ;

Gestion des clés et des certificat de l’Administrateur

Contexte

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 :

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 :

  • la clé RSA générée est de 2048 bits, chiffrée par l’algorithme aes-256-cbc et encodée en format PEM avec l’extension .pem ;

  • le certificat est soit autosigné, soit signé par une autorité dont on a à disposition la clé et le certificat en format PEM ;

  • si le certificat est autosigné, son attribut KeyUsage comporte le flag keyCertSign ;

  • si l”Administrateur est habilité par l”Organisation à signer des paquets contenant du code python (présence du fichier setup.py), l’attribut du certificat extendedKeyUsage comporte le flag CodeSigning ;

  • le certificat X509 est encodé et remis à l”Administrateur en format PEM avec l’extension .crt ;

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).

Autoriser le certificat de l’Administrateur à signer un paquet

Le certificat utilisé par la console WAPT pour signer les paquets et actions est défini avec le paramètre personal_certificate_path de la section [global] du fichier %LOCALAPPDATA%waptconsolewaptconsole.ini.

WAPT demande à l”Administrateur son mot de passe pour permettre de rechercher la clé privée (encodée au format PEM) correspondant au certificat parmi les fichiers .pem du répertoire contenant les certificats.

Lors de la signature de paquet, WAPT refusera le certificat si le paquet contient un fichier setup.py et que le certificat n’est pas de type CodeSigning.

Gérer les clés et certificats du Client WAPT

Contexte

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 :

  • lors de la mise à jour du statut du poste sur le serveur. ( :command :update_server_status) : signature des informations ;

  • lors de la connexion Websocket du poste vers le serveur (waptservice) : signature de l’UUID du poste ;

Émission initiale et mise à jour du certificat du client WAPT

  • à l’issue du processus d’installation de l’agent WAPT sur le poste client, l’agent WAPT s’enregistre automatiquement auprès du serveur WAPT en émettant une requête https authentifiée par Kerberos qui utilise le TGT du compte machine ;

    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é.

  • si la clé et les certificats n’ont pas encore été générés, ou s’ils ne correspondent pas au FQDN actuel de la machine, l’agent WAPT génère une clé RSA et un certificat X509 autosigné avec les paramètres suivants :

    • la clé est de type RSA 2048 bits encodée en PEM et stockée dans le fichier <WAPT>\private\<fqdn du poste>.pem ;

    • le certificat généré a les attributs suivants :

      • Subject.COMMON_NAME = <device FQDN>;

      • Subject.ORGANIZATIONAL_UNIT_NAME = nom de l”Organisation de la machine tel qu’enregistré dans la base de registre ;

      • SubjectAlternativeName.DNSName = <device FQDN> ;

      • BasicConstraint.CA = True ;

      • validity = 10 ans ;

      • serialnumber = aléatoire ;

    • le certificat est sauvegardé dans le fichier <WAPT>private<device FQDN>.crt ;

Note

Seuls le compte machine et les Administrateurs Locaux ont accès au répertoire <WAPT>\private car des ACL spécifiques sont appliquées à l’installation de l’agent WAPT sur le poste.

  • l’inventaire ou les mises à jour de status du client sont envoyés au serveur WAPT par requête https POST ;

  • on authentifie la requête https POST en ajoutant deux headers http spécifiques :

    • X-Signature :

      • encodage en JSON des informations d’inventaire ou de status ;

      • signature du json avec la clé privée du client WAPT : hachage sha256 et padding PKCS#1 v1.5 ;

      • encodage de la signature en base64 ;

    • X-Signer: Subject.COMMON_NAME ou UUID du client WAPT.

  • après avoir initialement authentifié le client WAPT avec Kerberos, le serveur reçoit le certificat envoyé par le client et il le stocke dans son inventaire, dans la table hosts (champ host_certificate en format PEM).

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.

Déployer les certificats d’autorité pour vérifier les paquets et les actions sur les clients

Les certificats au format PEM stockés dans des fichiers avec l’extension .crt ou .pem et présents dans le répertoire défini par le paramètre public_certs_dir du fichier <WAPT>wapt-get.ini sont réputés de confiance.

Ce paramètre public_certs_dir est initialisé par défaut à <WAPT>ssl.

Le déploiement de ces certificats d’autorité est effectué lors de l’installation initiale de l’agent WAPT par l’installeur.

Depuis la console, l”Administrateur compile un installeur personnalisé en vue de son déploiement par GPO sur les Postes clients.

La console WAPT incorpore dans cet installeur les certificats présents dans le répertoire <WAPT>\ssl du poste depuis lequel l’installeur est compilé.

L”Administrateur doit s’assurer d’enregistrer dans <WAPT>\ssl uniquement les certificats d’autorité nécessaires avant de lancer la compilation de l’agent.

Le déploiement ou la mise à jour de certificats de l”Autorité de Certification pour la vérification des paquets et actions peuvent être également assurés à postériori par une GPO Active Directory ou par un paquet WAPT.

Déployer les certificats d’autorité pour la communication HTTPS entre les clients WAPT et le serveur WAPT

Le service WAPT ainsi que l’outil en ligne de commande wapt-get communiquent avec le serveur WAPT pour envoyer l’inventaire (register) et le statut de déploiement des paquets (update-status).

Ces deux types de connexions vérifient le certificat https du serveur.

Paramètre verify_cert de la section [global] du fichier <WAPT>wapt-get.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 la connexion 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 pour la stocker au format .pem dans le fichier <WAPT>sslserver<FQDN serveur>.pem.

Il est de la responsabilité de l”Administrateur de s’assurer que la chaîne ainsi récupérée est authentique.

Lors de la compilation de l’installeur de l’agent WAPT, les certificats ou le bundle de certificats sont intégrés dans l’installeur.

Lors du déploiement de l’installeur sur les clients WAPT, le bundle est copié dans <WAPT>sslserver et le paramètre verify_cert de la section [global] du fichier <WAPT>wapt-get.ini est renseigné pour désigner le bundle.

Communications HTTPS entre les clients WAPT et les dépôts WAPT

Déployer des certificats d’autorité

Les connexions HTTPS de l’agent WAPT vers le dépôt principal utilisent les mêmes méthodes que les communications entre l’agent WAPT et le serveur WAPT.

L’agent WAPT utilise le même bundle de certificats pour communiquer en HTTPS avec le dépôt principal, avec le serveur WAPT, et avec les dépôts secondaires.

Client WAPT

La connexion https est mise en œuvre par les modules python requests, urllib3 et ssl.

Le certificat transmis par le serveur HTTPS du dépôt est vérifié par le module urllib3.contrib.pysopenssl.PyOpenSSLContext et urllib3.util.ssl_wrap_socket.

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 la connexion 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.

Déployer des certificats d’autorité pour vérifier les paquets importés dans le dépôt local

Contexte

Dans la console WAPT / onglet Dépôt privé, un bouton Importer depuis internet permet de télécharger un paquet depuis un dépôt externe dont l’URL est fournie par le paramètre repo_url de la section [wapt_templates] du fichier %LOCALAPPDATA%waptconsolewaptconsole.ini.

Une case à cocher Vérifier la signature de paquet permet de s’assurer que le paquet est signé avec un certificat provenant d’une Autorité de confiance.

Certificats d’Autorités de confiance

Les certificats d’autorité présents dans le répertoire désigné par le paramètre public_certs_dir de la section [wapt_templates] du fichier %LOCALAPPDATA%waptconsolewaptconsole.ini sont réputés de confiance.

Si le paramètre n’est pas mentionné explicitement, il est initialisé à %appdata%waptconsolessl.

Ce répertoire n’est pas automatiquement rempli par WAPT. Il est de la responsabilité de l”Administrateur de copier/coller les fichiers PEM d’autres Administrateurs de confiance ou les certificats des Autorités de Certification de confiance.

Les certificats d’autorité sont encodés en format PEM et stockés dans des fichiers avec l’extension .pem ou .crt. On peut stocker plusieurs certificats dans chaque fichier .crt ou .pem.

Il n’est pas nécessaire d’avoir la chaîne complète de certificats, WAPT acceptera le signataire d’un paquet à partir du moment que  :

  • le certificat du paquet est également présent dans le répertoire public_certs_dir. Le test d’égalité est fait avec l’empreinte du certificat ;

  • le certificat de l’Autorité ayant signé le certificat du paquet est présent dans le répertoire public_certs_dir. La recherche est faite avec l’attribut issuer_subject_hash du certificat. La signature du certificat est effectuée par la classe x509.verification.CertificateVerificationContext ;

Processus de signature d’un paquet

Le processus de signature du paquet est lancé lors des actions suivantes :

  • action wapt-get.exe build-upload <répertoire> ;

  • action wapt-get.exe sign-package <chemin-fichier-paquet.wapt> ;

  • commande shell wapt-signpackage.py <liste de fichiers paquets WAPT> ;

  • sauvegarde d’un paquet host dans la console WAPT ;

  • sauvegarde d’un paquet group dans la console WAPT ;

  • import direct d’un paquet depuis un dépôt externe ;

  • wizard de création de paquets à partir de MSI et de setup ;

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) ;

Signature des attributs du fichier control

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 :

  • les attributs signed_attributes, signer, signature_date, signer_certificate sont ajoutés à la structure du fichier control :

    • 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 : empreinte sha256 du certificat encodée en hexadécimal obtenue par la fonction fingerprint de la classe cryptography.x509.Certificate ;

  • les attributs de la structure control sont encodés en json ;

  • le JSON BLOB résultant est signé avec un hachage sha256 et un remplissage PKCS#1 v1.5 ;

  • la signature est encodée en base64 et stockée dans le JSON dans l’attribut signature du fichier control ;

Signature des fichiers du paquet

  • les attributs du fichier control sont signés et sérialisés en JSON. Le résultat est stocké dans le fichier <WAPT>control du ZIP du paquet ;

  • le certificat X509 du signataire depuis le fichier est stocké dans le fichier <WAPT>certificate.crt du paquet WAPT ;

  • les empreintes sha256 de tous les fichiers contenus dans le paquet WAPT sont codées en hexadécimal et stockées sous forme de liste JSON [(nom de fichier, hachage),] dans le fichier <WAPT>manifest.sha256 dans le paquet WAPT ;

  • le contenu du fichier <WAPT>manifest.sha256 est signé avec la clé privée de l”Administrateur (clé RAS 2048 bits), avec un hachage sha256 et un remplissage PKCS#1 v1.5 :

    • la procédure de signature fait appel à la fonction sign de la classe cryptography.rsa.RSAPrivateKey.signer ;

    • cryptography.rsa.RSAPrivateKey.signer repose sur les fonctions OpenSSL de EVP_DigestSignInit ;

  • la signature est encodée en base64 et stockée dans le fichier <WAPT>signature.sha256 du paquet WAPT ;

Vérifier la signature des attributs d’un paquet

Elle a lieu :

  • lors de la mise à jour de l’index des paquets disponibles à partir de l’index Packages du dépôt ;

  • lorsqu’une signature de paquet est vérifiée (installation, téléchargement) lorsqu’elle n’est pas en mode développement, c’est-à-dire si l’installation se fait à partir d’un fichier ZIP et non d’un répertoire de développement ;

Elle consiste à :

  • lire les attributs du fichier control depuis le fichier <WAPT>\control du ZIP du paquet ;

  • récupérer le certificat X509 du signataire depuis le fichier <WAPT>\certificate.crt du ZIP du paquet ;

  • décoder l’attribut signature du control depuis le format base64 ;

  • construire une structure JSON avec les attributs devant être signés (tels que définis dans la classe PackageEntry) ;

  • vérifier si la clé publique du certificat du titulaire peut vérifier le hachage de la liste structurée des attributs JSON et la signature du fichier control, en utilisant le hachage sha256 et le remplissage PKCS#1 v1.5 ;

  • vérifier si le certificat est de confiance (soit présent en tant que tel dans les certificats de confiance, soit signé par une Autorité de Certification de confiance) ;

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 :

  • lors de l’installation d’un paquet sur un Poste client ;

  • lors de l’édition d’un paquet existant ;

  • lors de l’import d’un paquet depuis un dépôt externe (si option cochée dans la console) ;

Elle consiste à :

  • récupérer le certificat X509 du signataire depuis le fichier <WAPT>\certificate.crt du ZIP du paquet ;

  • vérifier que le certificat a été signé par une autorité de confiance dont le certificat est présent dans le fichier ssl du client WAPT ;

  • vérifier la signature du fichier <WAPT>\manifest.sha256 avec la clé publique ;

Signature d’une action immédiate

Contexte

Depuis la console, l”Administrateur 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 du 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

  • l’action est définie par son nom et des attributs dépendants de l’action. Les attributs sont uuid, action, force, notify_server, et packages (pour les actions impliquant une liste de paquets) ;

  • les attributs signed_attributes, signer, signature_date, signer_certificate sont ajoutés à la structure de l’action :

    • signed_attributes : liste des noms des attributs qui sont signés ;

    • 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_certificate : certificat X509 du signataire encodé en base64 ;

  • la structure est encodée en JSON ;

  • la signature du JSON est calculée à partir de la clé privée RSA du signataire en utilisant un algorithme de hachage sha256 et un remplissage PKCS1 v1.5 ;

  • la signature est encodée en base64 et stockée dans le JSON dans l’attribut signature ;

Vérifier la signature d’une action immédiate

Contexte

Depuis la console, l”Administrateur 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.

Processus de vérification

Sur réception d’un évènement par la connexion Websocket du client WAPT :

  • le certificat X509 du signataire de l’action est extrait du json (format PEM) ;

  • le client WAPT teste si le certificat est un certificat de confiance, c’est-à-dire présent dans <WAPT>ssl ou signé par une autorité de confiance (certificat de l’autorité présent dans <WAPT>\ssl ;

  • le client WAPT teste si le certificat peut vérifier la signature présente dans la structure JSON de l’action ce qui consiste en :

    • extraire la signature encodée en base64 dans le json depuis l’attribut signature ;

    • extraire la date de signature formatée sous la forme “%Y-%m-%dT%H:%M:%S” depuis l’attribut signature_date ;

    • vérifier que la date de signature n’est pas trop ancienne ou dans le futur de plus de 10 minutes ;

    • reconstruire une représentation json des attributs de l’action ;

    • vérifier que la clé publique du certificat peut vérifier le JSON avec la signature en utilisant un algorithme de hachage sha256 et un remplissage PKCS1 v1.5 ;

Vérification du téléchargement complet d’un paquet

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é.

Cette somme md5 ne sert qu’à s’assurer qu’un paquet a été téléchargé complètement.

La vérification de la signature du paquet permettra d’être effectivement assuré de l’intégrité et de l’authenticité du paquet.