85.1.38. pepsi-stage-secure-link

hold a message that could not be encrypted, and mail the link

Handbuchabschnitt:

1

85.1.38.1.1. Name

pepsi-stage-secure-link - die Secure-Link-Ausweich-Stage der Pepsi-Pipeline.

85.1.38.1.2. Übersicht

pepsi-stage-secure-link [GLOBAL-OPTIONS] worker

85.1.38.1.3. Beschreibung

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

Es ist das ferne Ende von [stage-encrypt] ON_NO_KEY = secure-link. Wenn pepsi-stage-encrypt(1) eine Nachricht verschlüsseln muss und der Empfänger keinen brauchbaren Schlüssel veröffentlicht, leitet es die Nachricht hierher, statt sie im Klartext zu senden oder einen Bounce zu erzeugen. Diese Stage nimmt die Nachricht dann vollständig von der Leitung:

1. es erzeugt eine PIN, leitet das URL-Token aus dem Warteschlangendatensatz ab (siehe Wiederholungen) und einen Inhaltsschlüssel aus der PIN und dem serverseitigen Pfeffer und versiegelt die gesamte Nachricht darunter;

2. in einer Transaktion speichert es nur das AEAD-Chiffrat in pepsi.secure_message und reiht eine Benachrichtigungsmail an den Empfänger ein, die den Link trägt, und — unter dem Standardwert PIN_DELIVERY = sender — eine zweite Mail an den Absender, die die PIN trägt, damit der Absender sie per Telefon oder Kurznachricht weitergibt;

3. es löscht den Warteschlangendatensatz.

Der Datensatz wird gelöscht statt weitergeschaltet, weil das Weiterschalten den Klartext an genau den Empfänger übertragen würde, der keinen Klartext erhalten darf. Die Fortsetzung der Nachricht ist die Benachrichtigung, eine gewöhnliche ausgehende Nachricht, die bei [pepsi-secure-link] NOTIFY_STAGE injiziert und wie jede andere signiert und weitergeleitet wird. Die Stage ist daher terminal und hat kein NEXT_STAGE.

Eine Nachricht mit mehreren schlüssellosen Empfängern erzeugt eine gespeicherte Nachricht je Empfänger, jede mit eigenem Token, eigener PIN und eigenem Chiffrat, sodass die PIN eines Empfängers nie die Kopie eines anderen öffnet und keinem von ihnen die Empfängerliste offenbart wird.

85.1.38.1.4. Konfiguration

Der [stage-<name>]-Abschnitt der Stage trägt nur PROGRAM. Alles Übrige liegt im globalen Abschnitt [pepsi-secure-link] (siehe pepsi.conf(5)), und zwar bewusst: Das Ablauffenster, die PIN-Länge und die Sperre sind keine Verhaltensstellschrauben, die ein Korrespondent per E-Mail über pepsi-stage-edit-settings(1) bearbeiten dürfte, und ein globaler Abschnitt liegt außerhalb der Reichweite der Überschreibungsschicht je Adresse.

85.1.38.1.5. Beispiel

[stage-encrypt]
PROGRAM = pepsi-stage-encrypt
ENCRYPT = required
SECURE_LINK_STAGE = secure-link
NEXT_STAGE = srs

[stage-secure-link]
PROGRAM = pepsi-stage-secure-link

[pepsi-secure-link]
BASE_URL = https://secure.example.org
NOTIFY_STAGE = srs
# PEPPER is written to secrets.d/pepsi-secure-link.secret by pepsi-setup.

85.1.38.1.6. Wiederholungen

Ein Stage-Rumpf kann für denselben Warteschlangendatensatz mehr als einmal laufen: ein Worker, der nach seinen Seiteneffekten, aber vor dem Commit stirbt, ein Neustart von pepsi-dispatch(1), der einen running-Datensatz erneut beansprucht, ein erneutes Einreihen durch den Operator und ein Fehlschlag mittendrin, der wiederholt wird (siehe Fehler). Die Schleife über die Empfänger ist nicht atomar — ein Fehlschlag beim k-ten Empfänger lässt jeden Empfänger davor bereits gespeichert und benachrichtigt zurück —, wohl aber jeder einzelne Empfänger: Die gespeicherte Kopie und ihre Benachrichtigungen werden gemeinsam durch einen Aufruf der SQL-Funktion secure_message_store festgeschrieben oder gar nicht.

Das Token der sicheren Nachricht wird deshalb aus dem Warteschlangendatensatz abgeleitet, als geschlüsselter Hash aus dem Token des Datensatzes und der Position des Empfängers unter dem PEPPER der Installation, statt zufällig gezogen zu werden. Ein wiederholter Durchlauf berechnet dasselbe Token erneut, findet den pepsi.secure_message-Datensatz dieses Empfängers bereits vor, vermerkt eine Warnung im Journal und lässt ihn unangetastet: keine zweite Kopie, kein zweiter Link an den Empfänger und keine zweite PIN an den Absender. Das Token ist geschlüsselt und nicht bloß gehasht, weil es die Link-URL ist — alles, was ein Außenstehender nachrechnen könnte, wäre ein Link, den er erraten könnte.

Nur das Token wird abgeleitet. Die PIN bleibt bei jedem Durchlauf zufällig und wird nirgends gespeichert; das ist die Eigenschaft, die eine gestohlene Datenbank und selbst einen gestohlenen Server nutzlos macht (siehe pepsi-secure-link(1)); eine PIN, die aus dem Pfeffer und dem Token des Datensatzes reproduzierbar wäre, wäre eine, die der Operator nachrechnen könnte. Deshalb müssen die Kopie und ihre Ankündigung ein einziger Commit sein: Eine ohne ihre Benachrichtigungen gespeicherte Kopie trüge eine PIN, die nirgends mehr existiert, und keine Wiederholung könnte sie ankündigen. So aber ist eine gespeicherte Kopie immer eine angekündigte, und eine Wiederholung, die sie vorfindet, hat für diesen Empfänger nichts mehr zu tun.

Das Einzige, was eine Wiederholung wiederholen kann, ist PIN_DELIVERY = command: Der Befehl läuft vor dem Commit (sodass ein ausgefallenes Gateway nichts gespeichert zurücklässt), und schlägt der Commit danach fehl, sendet der nächste Durchlauf eine neue PIN; die frühere öffnet nichts, da unter ihr nichts gespeichert wurde.

85.1.38.1.7. Fehler

Alles, was fehlschlagen kann, geschieht, bevor der Warteschlangendatensatz gelöscht wird, und nichts, was fehlschlägt, schickt die Nachricht je weiter: Eine Nachricht, die diese Stage erreicht hat, ist definitionsgemäß eine, von der der Operator gesagt hat, dass sie nicht ungeschützt hinausgehen darf.

• Ein [pepsi-secure-link]-Abschnitt, der sich nicht parsen lässt, kein BASE_URL oder PEPPER hat (oder einen Pfeffer, der sich nicht lesen lässt) oder kein NOTIFY_STAGE, lässt den Worker den Start verweigern (Exit 78): Der Dispatcher hält die Warteschlange an, bis die Konfiguration korrigiert ist, statt jede Nachricht einzeln fehlschlagen zu lassen.

• Ein Fehler dieses Hosts — eine Benachrichtigungsvorlage, die sich nicht lesen lässt, PIN_DELIVERY = command, das nicht startet, fehlschlägt oder nicht innerhalb von 30 Sekunden fertig wird, die Datenbank — wird wiederholt, nach einer Minute und dann in sich verdoppelnden Abständen bis zu einer Stunde, bis die Nachricht länger als das MAX_LIFETIME der Stage (Standardwert 120 h) eingereiht war; dann geht sie an die BOUNCE_STAGE der Stage oder schlägt ohne eine solche fehl (siehe pepsi-dispatch(1)).

• Eine Nachricht mit dem Null-Umschlagabsender schlägt sofort fehl: Es gäbe niemanden, dem man die PIN geben könnte.

85.1.38.1.8. Exit-Status

Der Worker endet mit 0 bei einem sauberen Ende der Eingabe und mit 78, wenn er den Start verweigert, weil [pepsi-secure-link] nicht verwendbar ist (siehe Fehler). Ein Fehlschlag je Nachricht wird über die Warteschlange gemeldet, nicht über den Exit-Status.

85.1.38.1.9. Siehe auch

pepsi-secure-link(1), pepsi-stage-encrypt(1), pepsi-httpd(1), pepsi-dispatch(1), pepsi.conf(5), pepsi.state(7)