85.1.37. pepsi-stage-vks-confirm

follow a key server’s address-verification link, safely

Section du manuel:

1

85.1.37.1.1. Nom

pepsi-stage-vks-confirm - l’étape de confirmation auprès du serveur de clés du pipeline Pepsi.

85.1.37.1.2. Synopsis

pepsi-stage-vks-confirm [GLOBAL-OPTIONS] worker

85.1.37.1.3. Description

pepsi-stage-vks-confirm est un programme d’étape exécuté par pepsi-dispatch(1) comme un worker persistant lisant les identifiants de message sur l’entrée standard.

Une clé téléversée vers un serveur de clés vérificateur est stockée mais introuvable par adresse tant que quelqu’un n’a pas suivi un lien dans un courrier que le serveur envoie à cette adresse. Le faire à la main pour la clé de chaque utilisateur ne passe pas à l’échelle : cette étape s’en charge donc — et parce que « aller chercher une URL trouvée dans du courrier entrant » est une primitive véritablement dangereuse, c’est un programme distinct plutôt qu’un comportement greffé sur pepsi-keys(1) ou sur une étape de cryptographie : la partie dangereuse tient dans un seul petit programme non privilégié dont la position dans le pipeline est visible dans la configuration.

Placez-la sur le chemin entrant, n’importe où avant la remise locale. Le placement est indulgent : tout ce sur quoi l’étape n’agit pas est avancé vers NEXT_STAGE sans être touché, ce qui représente la quasi-totalité du courrier.

85.1.37.1.4. Ce sur quoi elle refuse d’agir

Chacune des conditions ci-dessous doit être remplie avant qu’un seul octet ne soit récupéré. Un message qui en manque une est avancé sans être touché, de sorte que le mode de défaillance est que l’utilisateur reçoit le courrier et peut cliquer lui-même sur le lien — ce qui permet aux conditions d’être strictes.

  1. Le domaine de l’expéditeur d’enveloppe est exactement VKS_HOST. Pas une sous-chaîne, pas un sous-domaine, et pas l’en-tête From: : keys.example.org.evil.test se termine par la bonne chaîne, notkeys.example.org la contient, et ni l’un ni l’autre n’est le serveur de clés.

  2. SPF ou DMARC a réussi (REQUIRE_AUTHENTICATION, activé par défaut). Un MAIL FROM est une prétention ; c’est ceci qui en fait une preuve. Notez que dkim=pass ne compte délibérément pas — cela dit qu’une signature a été vérifiée, pas de qui elle est, et un attaquant qui signe avec son propre domaine en obtient une gratuitement.

  3. Chaque lien http(s) du corps est un lien https vers ce même hôte, sur le port par défaut. Un message nommant tout autre hôte (ou un simple lien http, ou un autre port) est refusé entièrement plutôt que de voir le lien étranger sauté, et un message ne portant aucun lien est simplement remis. Un vrai courrier de vérification renvoie vers le serveur de clés et nulle part ailleurs : un lien étranger signifie donc soit que le courrier n’est pas ce qu’il prétend, soit que le serveur de clés a modifié son courrier d’une manière qu’il vaut la peine d’examiner avant d’y réagir automatiquement. L’hôte est lu après tout userinfo, car https://keys.example.org@evil.test/ est une requête vers evil.test et se lit au premier coup d’œil comme l’inverse.

  4. Un destinataire est une adresse que nous attendons réellement : une identité OpenPGP publiée, active, téléversée et pas encore vérifiée. Un courrier de vérification non sollicité — pour une adresse que nous n’avons jamais téléversée, ou dont la confirmation est déjà arrivée — est remis, non cliqué. C’est aussi ce qui empêche un inconnu de faire émettre des requêtes par Pepsi en écrivant à une adresse servie.

  5. Au plus MAX_LINKS liens sont suivis par message.

  6. La récupération elle-même passe par le même client durci qu’emploie la découverte de clés : HTTPS uniquement, certificats vérifiés, l’adresse du pair résolue ici et passée au crible (de sorte qu’un nom se résolvant vers la boucle locale, une plage privée, le lien-local ou l’adresse de métadonnées du cloud soit refusé), le corps plafonné pendant le flux, et au plus une redirection vers le même hôte.

85.1.37.1.5. La confirmation n’est pas supposée

Un 200 renvoyé par l’URL de confirmation est la réponse du serveur à une requête, non une déclaration que l’adresse est désormais publiée. Après avoir suivi les liens, l’étape demande donc au serveur de clés s’il sert maintenant notre clé pour cette adresse, et seule une correspondance d’empreinte note l’identité comme vérifiée. La marquer sur le seul 200 empêcherait à jamais la tâche de réessai de pepsi-keys(1) de réessayer. La même vérification décide du sort du courrier : il n’est supprimé (DISCARD_CONFIRMED) que lorsqu’au moins une identité a été vérifiée, et remis sinon.

85.1.37.1.6. Piste d’audit

Chaque décision — acceptée, refusée et pourquoi, chaque lien suivi et le statut renvoyé, ainsi que le verdict obtenu — est journalisée au niveau info sur la cible vks-confirm. C’est délibérément exhaustif plutôt qu’échantillonné : un programme qui va chercher des URL trouvées dans du courrier doit laisser une trace de chaque récupération qu’il a faite.

85.1.37.1.7. Configuration

[stage-<name>] avec PROGRAM = pepsi-stage-vks-confirm :

NEXT_STAGE (requis)

Où va chaque message que cette étape ne consomme pas — c’est-à-dire presque tous. Requis précisément pour cela : une étape du chemin entrant qui abandonnerait en silence ce qu’elle ne reconnaît pas perdrait du courrier ordinaire. pepsi-setup(1) vérifie que la cible se résout.

VKS_HOST (par défaut : l’hôte de [pepsi-keys] VKS_SERVER)

L’unique hôte dont cette étape acceptera un courrier de vérification et vers lequel elle suivra un lien. Ce doit être l’hôte de [pepsi-keys] VKS_SERVER (qui vaut lui-même par défaut la première entrée de [pepsi-keydiscovery] VKS_SERVERS), comparé sans tenir compte de la casse et sans port ni chemin : ce serveur reçoit les téléversements, son courrier de vérification est donc celui qu’attend cette étape. pepsi-setup(1) refuse une configuration dans laquelle les deux nomment des hôtes différents, puisque l’étape ignorerait alors chaque confirmation. Le définir n’est donc jamais qu’une redite ; omettez-le.

MAX_LINKS (3 par défaut)

Combien de liens un message peut coûter. Un vrai courrier de vérification en porte un ; la borne est ce qui empêche un message ayant franchi toutes les autres vérifications de devenir un nombre arbitraire de requêtes.

DISCARD_CONFIRMED (yes par défaut)

Supprime un courrier de confirmation sur lequel l’étape a agi, au lieu de le remettre. C’est du courrier machine à propos d’une action que Pepsi a menée, adressé à une boîte aux lettres dont le propriétaire ne l’a pas demandé, et il a déjà été traité au moment où il arriverait. Seul est supprimé un courrier après lequel le serveur de clés a été vu servir notre clé pour au moins une identité : lorsque suivre ses liens n’a rien vérifié, le courrier est remis quoi que dise cette option, puisqu’il est alors le seul moyen restant de terminer la confirmation à la main. Mettez-la à no pour remettre chaque courrier de confirmation.

REQUIRE_AUTHENTICATION (yes par défaut)

Exige un pass SPF ou DMARC, et pas seulement le bon expéditeur d’enveloppe.

Il n’y a pas de BOUNCE_STAGE : l’étape ne met jamais un message en échec. Une défaillance de cet hôte laisse elle aussi passer le message — une section qui ne s’analyse pas pour ce message (une surcharge par adresse peut la rendre invalide), une base de données qui ne peut dire quelles confirmations sont en attente, un client HTTP qui ne peut être construit : elle est journalisée au niveau warn et le courrier est remis intact, car attendre retiendrait du courrier ordinaire pour quelque chose que l’utilisateur peut faire à la main. Un échec d’enregistrement d’une identité confirmée est journalisé de la même façon, et le courrier est alors remis plutôt qu’écarté. La configuration de base (cette section, [pepsi-keys] et [pepsi-keydiscovery]) est en revanche vérifiée au démarrage du worker : une configuration invalide fait refuser au worker de démarrer (code 78), de sorte que le dispatcher retient la file plutôt que de laisser l’étape devenir un passage silencieux.

85.1.37.1.8. Données du message

L’étape charge le message complet (Load::Full) parce que les liens sont dans le corps. Elle ne réécrit jamais le message, ne le met jamais en pause ni en échec, et laisse state intact, de sorte que state.dsn et tout autre verdict survivent.

85.1.37.1.9. Commandes

worker

Lit les identifiants de message sur l’entrée standard et traite chacun. Le seul mode d’exécution ; le dispatcher démarre et arrête ces workers.

85.1.37.1.10. Options globales

-c FILE, –config FILE

Lire la configuration depuis FILE au lieu de parcourir les emplacements par défaut. Doit venir avant la sous-commande.

-L LOGLEVEL, –log LOGLEVEL

Règle la verbosité de journalisation (par défaut info).

-v, –verbose

Affiche les messages de journal de toutes les sources.

-h, –help ; -V, –version

Affiche un résumé d’utilisation / la version et quitte.

85.1.37.1.11. Code de sortie

0

Le worker s’est terminé proprement.

1

Une erreur s’est produite (un fichier de configuration malformé, une section d’étape non résoluble, ou une connexion à la base échouée). La raison est écrite dans le journal.

78

Le worker a refusé de démarrer : sa section, [pepsi-keys] ou [pepsi-keydiscovery] ne s’analyse pas. Le dispatcher remet en file ce qu’il lui avait confié et réessaie l’étape plus tard.

85.1.37.1.12. Exemples

Un pipeline entrant qui confirme le courrier du serveur de clés avant la remise locale

[pepsi-keys]
VKS_SERVER = https://keys.openpgp.org

[stage-vks-confirm]
PROGRAM = pepsi-stage-vks-confirm
NEXT_STAGE = local

Traiter un message à la main

echo 4711 | pepsi-stage-vks-confirm -c /etc/pepsi/pepsi.conf worker

85.1.37.1.13. Voir aussi

pepsi-keys(1), pepsi-httpd(1), pepsi-keydisc(1), pepsi-dispatch(1), pepsi.conf(5), pepsi.state(7)

85.1.37.1.14. Bogues

Signalez les bogues au gestionnaire de tickets de Pepsi.