59. pepsi-stage-vks-confirm

Dem Link zur Adressverifikation eines Keyservers folgen, und sonst nichts.

59.1. Rolle

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. pepsi-stage-vks-confirm tut das auf dem eingehenden Pfad, sodass die Schlüsselveröffentlichung abgeschlossen wird, ohne dass ein Mensch das Postfach jedes Benutzers liest.

Es ist ein eigenes Programm, weil es in eingehender Mail gefundene URLs abruft. Das ist ein gefährliches Primitiv; in einer eigenen kleinen, unprivilegierten Stage bleibt es den Programmen fern, die Schlüsselmaterial halten oder feindliches Chiffrat parsen, und seine Position in der Pipeline bleibt in der Konfiguration sichtbar. Referenz: pepsi-stage-vks-confirm(1).

Alles, worauf es nicht reagiert — nahezu die gesamte Mail —, wird unberührt zu NEXT_STAGE weitergeschaltet, sodass die Platzierung nachsichtig ist.

59.2. Was es verweigert

Jede einzelne dieser Bedingungen muss gelten, bevor ein Byte abgerufen wird. Schlägt eine davon fehl, wird die Nachricht stattdessen zugestellt, und der Benutzer kann den Link selbst anklicken — was es erlaubt, die Bedingungen derart streng zu fassen.

  • Die Domain des Umschlagabsenders ist genau VKS_HOST, keine Subdomain, kein Suffix-Treffer und nicht der From:-Header.

  • SPF oder DMARC bestanden (sofern nicht REQUIRE_AUTHENTICATION = no). Ein MAIL FROM ist eine Behauptung; dies ist es, was daraus einen Beleg macht. dkim=pass zählt bewusst nicht — es sagt, dass eine Signatur verifiziert wurde, nicht wessen.

  • Jeder Link ist https auf genau diesen Host, am Standardport. Eine Nachricht, die irgendeinen anderen Host benennt, wird vollständig verweigert, statt den fremden Link zu überspringen: Eine echte Verifikationsmail verlinkt auf den Keyserver und sonst nirgendwohin. Der Host wird nach etwaigen Userinfo-Angaben gelesen, denn https://keys.example.org@evil.test/ ist eine Anfrage an evil.test.

  • Ein Empfänger ist eine Adresse, auf die wir tatsächlich warten — veröffentlicht, hochgeladen, noch nicht verifiziert. Eine unaufgeforderte Verifikationsmail wird zugestellt, nicht angeklickt, und das ist zugleich das, was einen Fremden davon abhält, Pepsi durch Mail an eine bediente Adresse Anfragen ausführen zu lassen.

  • Höchstens MAX_LINKS je Nachricht, abgerufen über denselben gehärteten Client, den die Schlüsselentdeckung verwendet: nur HTTPS, verifizierte Zertifikate, die aufgelöste Adresse gegen den SSRF-Schutz abgeglichen, der Nachrichtentext während des Streamens gedeckelt.

59.3. Die Bestätigung wird verifiziert, nicht angenommen

Ein 200 auf den Link ist die Antwort des Servers auf eine Anfrage, keine Aussage, dass die Adresse jetzt veröffentlicht ist. Die Stage fragt daher den Keyserver, ob er unseren Schlüssel für die Adresse ausliefert, und nur eine Fingerabdruck-Übereinstimmung hält die Identität als verifiziert fest — sie beim 200 zu markieren würde die Wiederholungsaufgabe von pepsi-keys daran hindern, es je wieder zu versuchen. Dieselbe Prüfung entscheidet über das Schicksal der Mail: Sie wird nur verworfen (DISCARD_CONFIRMED), wenn mindestens eine Identität verifiziert wurde, und andernfalls zugestellt, sodass eine Bestätigung, die nicht gewirkt hat, noch von Hand abgeschlossen werden kann.

Jede Entscheidung und jeder Abruf wird auf info im Ziel vks-confirm protokolliert, und das ist der Prüfpfad.

59.4. Konfiguration

[stage-<name>]: PROGRAM = pepsi-stage-vks-confirm, NEXT_STAGE (erforderlich — siehe oben), VKS_HOST (Standardwert ist der Host von [pepsi-keys] VKS_SERVER; pepsi-setup weist einen Wert ab, der einen anderen Host benennt, da die Stage dann jede Bestätigung ignorieren würde), MAX_LINKS (3), DISCARD_CONFIRMED (yes: Eine Bestätigungsmail, die eine Identität verifiziert hat, ist maschinelle Mail über eine Aktion, die Pepsi vorgenommen hat) und REQUIRE_AUTHENTICATION (yes). Siehe pepsi-stage-vks-confirm(1).

59.5. State

  • Eingaben: state.auth.spf / state.auth.dmarc, der Umschlagabsender und der Nachrichtentext.

  • Ausgaben: keine. Die Stage schreibt nie in state und schreibt die Nachricht nie um; was sie ändert, ist die Veröffentlichungsbuchführung des Schlüsselspeichers.

59.6. Siehe auch

Schlüsselverwaltung, pepsi-keys, pepsi-httpd, pepsi-keydisc, pepsi-stage-vks-confirm(1).