85.1.37. pepsi-stage-vks-confirm

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

Handbuchabschnitt:

1

85.1.37.1.1. Name

pepsi-stage-vks-confirm - die Keyserver-Bestätigungs-Stage der Pepsi-Pipeline.

85.1.37.1.2. Übersicht

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

85.1.37.1.3. Beschreibung

pepsi-stage-vks-confirm ist ein Stage-Programm, das von pepsi-dispatch(1) als persistenter Worker ausgeführt wird, der Nachrichten-IDs von der Standardeingabe liest.

Ein auf einen verifizierenden Keyserver hochgeladener Schlüssel wird gespeichert, ist aber nicht über die Adresse auffindbar, bis jemand einem Link in einer Mail folgt, die der Server an diese Adresse sendet. Das für den Schlüssel jedes Benutzers von Hand zu tun skaliert nicht, also tut es diese Stage — und weil „eine in eingehender Mail gefundene URL abrufen“ ein wirklich gefährliches Primitiv ist, ist es ein eigenes Programm statt eines an pepsi-keys(1) oder eine Kryptographie-Stage angeflanschten Verhaltens: Der gefährliche Teil steckt in einem einzigen kleinen, unprivilegierten Programm, dessen Position in der Pipeline in der Konfiguration sichtbar ist.

Platzieren Sie sie auf dem eingehenden Pfad, irgendwo vor der lokalen Zustellung. Die Platzierung ist nachsichtig: Alles, worauf die Stage nicht reagiert, wird unberührt zu NEXT_STAGE weitergeschaltet, und das ist nahezu die gesamte Mail.

85.1.37.1.4. Worauf sie nicht reagiert

Jede der folgenden Bedingungen muss gelten, bevor ein einziges Byte abgerufen wird. Eine Nachricht, die eine davon verfehlt, wird unberührt weitergeschaltet, sodass der Fehlermodus darin besteht, dass der Benutzer die Mail erhält und den Link selbst anklicken kann — weshalb die Bedingungen es sich leisten können, streng zu sein.

1. Die Domain des Umschlagabsenders ist genau VKS_HOST. Keine Teilzeichenkette, keine Subdomain und nicht der From:-Header: keys.example.org.evil.test endet auf die richtige Zeichenkette, notkeys.example.org enthält sie, und keines von beiden ist der Keyserver.

2. SPF oder DMARC bestanden (REQUIRE_AUTHENTICATION, standardmäßig an). Ein MAIL FROM ist eine Behauptung; dies ist es, was daraus einen Beleg macht. Beachten Sie, dass dkim=pass bewusst nicht zählt — es sagt, dass eine Signatur verifiziert wurde, nicht wessen, und ein Angreifer, der mit seiner eigenen Domain signiert, bekommt eine gratis.

3. Jeder http(s) -Link im Nachrichtentext ist https zu genau diesem Host, auf dem Standardport. Eine Nachricht, die irgendeinen anderen Host benennt (oder einen einfachen http-Link oder einen anderen Port), wird vollständig verweigert, statt den fremden Link zu überspringen, und eine, die gar keinen Link enthält, wird einfach zugestellt. Eine echte Verifikationsmail verlinkt auf den Keyserver und sonst nirgendwohin, sodass ein fremder Link entweder bedeutet, dass die Mail nicht ist, was sie behauptet, oder dass der Keyserver seine Mail auf eine Weise geändert hat, die man sich ansehen sollte, bevor man automatisch darauf reagiert. Der Host wird nach etwaigen Userinfo-Angaben gelesen, denn https://keys.example.org@evil.test/ ist eine Anfrage an evil.test und liest sich auf den ersten Blick als das Gegenteil.

4. Ein Empfänger ist eine Adresse, auf die wir tatsächlich warten: eine veröffentlichte, aktive OpenPGP-Identität, die hochgeladen und noch nicht verifiziert ist. Eine unaufgeforderte Verifikationsmail — für eine Adresse, die wir nie hochgeladen haben, oder eine, deren Bestätigung schon eintraf — wird zugestellt, nicht angeklickt. Das ist zugleich das, was einen Fremden davon abhält, Pepsi durch Mail an eine bediente Adresse Anfragen ausführen zu lassen.

5. Je Nachricht werden höchstens MAX_LINKS Links verfolgt.

6. Der Abruf selbst läuft über denselben gehärteten Client, den die Schlüsselentdeckung verwendet: nur HTTPS, verifizierte Zertifikate, die hier aufgelöste und überprüfte Peer-Adresse (sodass ein Name, der auf Loopback, einen privaten Bereich, Link-Local oder die Cloud-Metadatenadresse auflöst, abgelehnt wird), der Nachrichtentext während des Streamens gedeckelt und höchstens eine Weiterleitung zum selben Host.

85.1.37.1.5. Bestätigen wird nicht angenommen

Ein 200 von der Bestätigungs-URL ist die Antwort des Servers auf eine Anfrage, keine Aussage, dass die Adresse jetzt veröffentlicht ist. Nach dem Verfolgen der Links fragt die Stage daher den Keyserver, ob er nun unseren Schlüssel für die Adresse ausliefert, und nur eine Fingerabdruck-Übereinstimmung hält die Identität als verifiziert fest. Sie allein aufgrund des 200 zu markieren würde die Wiederholungsaufgabe von pepsi-keys(1) daran hindern, es je wieder zu versuchen. Dieselbe Prüfung entscheidet über das Schicksal der Mail: Sie wird nur dann verworfen (DISCARD_CONFIRMED), wenn mindestens eine Identität verifiziert wurde, und andernfalls zugestellt.

85.1.37.1.6. Prüfpfad

Jede Entscheidung — angenommen, abgelehnt und warum, jeder verfolgte Link und der zurückgegebene Status sowie das resultierende Urteil — wird auf info im Ziel vks-confirm protokolliert. Das ist bewusst vollständig statt stichprobenartig: Ein Programm, das in Mail gefundene URLs abruft, muss eine Aufzeichnung jedes von ihm getätigten Abrufs hinterlassen.

85.1.37.1.7. Konfiguration

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

NEXT_STAGE (erforderlich)

Wohin jede Nachricht geht, die diese Stage nicht verbraucht — und das sind nahezu alle. Genau deshalb erforderlich: Eine Stage auf dem eingehenden Pfad, die stillschweigend verwerfen würde, was sie nicht erkennt, würde gewöhnliche Mail verlieren. pepsi-setup(1) prüft, dass das Ziel auflöst.

VKS_HOST (Standardwert: der Host von [pepsi-keys] VKS_SERVER)

Der eine Host, von dem diese Stage eine Verifikationsmail annimmt und dessen Link sie folgt. Er muss der Host von [pepsi-keys] VKS_SERVER sein (das seinerseits standardmäßig der erste Eintrag von [pepsi-keydiscovery] VKS_SERVERS ist), verglichen ohne Beachtung der Groß-/Kleinschreibung und ohne Port oder Pfad: Dieser Server empfängt die Uploads, also ist seine Verifikationsmail die Mail, auf die diese Stage wartet. pepsi-setup(1) verweigert eine Konfiguration, in der beide verschiedene Hosts nennen, da die Stage dann jede Bestätigung ignorieren würde. Die Option zu setzen ist daher immer nur eine Wiederholung; lassen Sie sie weg.

MAX_LINKS (Standardwert 3)

Wie viele Links eine Nachricht kosten darf. Eine echte Verifikationsmail trägt einen; die Obergrenze ist das, was eine Nachricht, die an allen anderen Prüfungen vorbeikam, davon abhält, zu einer beliebigen Zahl von Anfragen zu werden.

DISCARD_CONFIRMED (Standardwert yes)

Löscht eine Bestätigungsmail, auf die die Stage reagiert hat, statt sie zuzustellen. Es ist maschinelle Mail über eine Aktion, die Pepsi vorgenommen hat, adressiert an ein Postfach, dessen Eigentümer nicht darum gebeten hat, und sie ist bereits abgearbeitet, wenn sie ankäme. Gelöscht wird nur eine Mail, nach der der Keyserver für mindestens eine Identität unseren Schlüssel ausliefert: Hat das Verfolgen ihrer Links nichts verifiziert, wird die Mail unabhängig von dieser Option zugestellt, da sie dann der einzige verbleibende Weg ist, die Bestätigung von Hand abzuschließen. Setzen Sie sie auf no, um jede Bestätigungsmail zuzustellen.

REQUIRE_AUTHENTICATION (Standardwert yes)

Verlangt SPF oder DMARC pass, nicht bloß den richtigen Umschlagabsender.

Es gibt keine BOUNCE_STAGE: Die Stage lässt nie eine Nachricht fehlschlagen. Auch ein Fehler dieses Hosts schlägt offen fehl — ein Abschnitt, der sich für diese Nachricht nicht parsen lässt (eine Überschreibung pro Adresse kann ihn unbrauchbar machen), eine Datenbank, die nicht sagen kann, welche Bestätigungen ausstehen, ein HTTP-Client, der sich nicht bauen lässt: Es wird auf warn protokolliert und die Mail unverändert zugestellt, denn Warten hielte gewöhnliche Mail für etwas zurück, das der Benutzer von Hand erledigen kann. Ein Fehlschlag beim Festhalten einer bestätigten Identität wird ebenso protokolliert, und die Mail wird dann zugestellt statt verworfen. Die Basiskonfiguration (dieser Abschnitt, [pepsi-keys] und [pepsi-keydiscovery]) wird stattdessen beim Start des Workers geprüft: Eine fehlerhafte lässt den Worker den Start verweigern (Exit 78), sodass der Dispatcher die Warteschlange anhält, statt die Stage zu einem stillen Durchreichen werden zu lassen.

85.1.37.1.8. Nachrichtendaten

Die Stage lädt die vollständige Nachricht (Load::Full), weil die Links im Nachrichtentext stehen. Sie schreibt die Nachricht nie um, pausiert sie nie, lässt sie nie fehlschlagen und lässt state unberührt, sodass state.dsn und jedes andere Urteil überleben.

85.1.37.1.9. Befehle

worker

Liest Nachrichten-IDs von der Standardeingabe und verarbeitet jede. Der einzige Ausführungsmodus; der Dispatcher startet und stoppt diese Worker.

85.1.37.1.10. Globale Optionen

-c FILE, –config FILE

Liest die Konfiguration aus FILE, statt die Standardorte zu durchsuchen. Muss vor dem Unterbefehl stehen.

-L LOGLEVEL, –log LOGLEVEL

Setzt die Log-Ausführlichkeit (Standardwert info).

-v, –verbose

Zeigt Log-Meldungen aus allen Quellen.

-h, –help; -V, –version

Gibt eine Verwendungsübersicht / die Version aus und beendet sich.

85.1.37.1.11. Exit-Status

0

Der Worker hat sich sauber beendet.

1

Ein Fehler ist aufgetreten (eine fehlerhafte Konfigurationsdatei, ein nicht auflösbarer Stage-Abschnitt oder eine fehlgeschlagene Datenbankverbindung). Der Grund wird in das Journal geschrieben.

78

Der Worker hat den Start verweigert: Sein Abschnitt, [pepsi-keys] oder [pepsi-keydiscovery] lässt sich nicht parsen. Der Dispatcher reiht wieder ein, was er übergeben hatte, und versucht die Stage später erneut.

85.1.37.1.12. Beispiele

Eine eingehende Pipeline, die Keyserver-Mail vor der lokalen Zustellung bestätigt:

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

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

Eine Nachricht von Hand verarbeiten:

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

85.1.37.1.13. Siehe auch

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

85.1.37.1.14. Fehler

Melden Sie Fehler an den Pepsi-Issue-Tracker.