34. pepsi-stage-decrypt

Mail an unsere Benutzer entschlüsseln und sagen, was ihre Signatur wert ist.

34.1. Rolle

pepsi-stage-decrypt ist die eingehende Hälfte von Pepsis Ende-zu-Ende-Kryptographie. Für eine Nachricht an einen Empfänger, den dieser Host bedient, öffnet es jedes Chiffrat, das die Nachricht trägt, verifiziert jede Signatur, die sie trägt, gegen eine echte Vertrauenskette, hält das Urteil fest und entfernt jeden Sicherheitsindikator, den der Absender gefälscht hat. Es verwendet die Zertifikate, die die Nachricht mitbringt, speichert aber keines davon. Es betreibt keine Netzwerk-E/A: Ist der Schlüssel des Signierenden unbekannt, wird die Nachricht pausiert, und ein pepsi-keydisc-Dienst gibt sie frei. Was es öffnet, wird als Klartext abgelegt, es sei denn, pepsi-stage-reencrypt versiegelt es kurz vor der Zustellung erneut an den eigenen Mail-Client-Schlüssel des Empfängers. Referenz: pepsi-stage-decrypt(1).

Beide Protokolle, die sie liest, sind Standards:

  • OpenPGP — RFC 9580 (die Krypto-Auffrischung, die RFC 4880 ablöst) für die Paketgrammatik und die Algorithmen, RFC 3156 für die PGP/MIME-Container (multipart/encrypted, multipart/signed und der micalg-Parameter). Inline-OpenPGP (nicht MIME) wird ebenfalls gelesen, aber nie geschrieben.

  • S/MIME — RFC 5652 für die Cryptographic Message Syntax, RFC 5083 mit RFC 5084 für AuthEnvelopedData (AES-GCM), RFC 3565 für AES-CBC-EnvelopedData, RFC 5753 für die ECDH-Schlüsselvereinbarung und RFC 8551 für das Nachrichtenprofil mit RFC 8550 für die Zertifikatsbehandlung. Die Zertifikate selbst — Pfadbildung, die erweiterte Schlüsselverwendung emailProtection und die rfc822Name-Bindung, die ein Zertifikat an eine Adresse knüpft — sind RFC 5280.

Zwei Grenzen werden hier genannt, damit sie nicht für Fehler gehalten werden. Zertifikatswiderruf wird nie geprüft: Weder CRLs (RFC 5280 §5) noch OCSP (RFC 6960) werden abgerufen, sodass ein widerrufenes Zertifikat weiterhin validiert und der gemeldete Widerrufsstatus stets „nicht geprüft“ lautet. Und ein unauthentifizierter Container wird nicht als gut gemeldet: AES-CBC-EnvelopedData trägt keinen MAC, öffnet sich also mit dem Urteil untrusted statt good, während AES-GCM-AuthEnvelopedData — was Pepsi ausgibt — authentifiziert ist. Beides ist in RFC-Index aufgeführt.

Warnung

Setzen Sie diese Stage hinter die ARC-Stage und vor die Inhalts-Stages. Die empfohlene eingehende Kette ist init = arc → decrypt → aliases → (anti-spam / language / …) → local delivery. Ein ARC-Set versiegelt die Nachricht so, wie sie ankam; zuerst zu entschlüsseln würde das versiegelte AMS Bytes beschreiben lassen, die sonst niemand je gesehen hat. pepsi-setup warnt, wenn es eine ARC-Stage findet, die von einer Decrypt-Stage aus erreichbar ist, und erneut, wenn von einer solchen keine lokale Zustell-Stage erreichbar ist.

34.2. Funktionen

  • Sie läuft nur für Empfänger, die dieser Host bedient, und versucht es bei allem anderen gar nicht erst. Entschlüsseln schreibt den Nachrichtentext um, was die DKIM-Signatur des Absenders entwertet — harmlos bei einer Nachricht, die gleich hier in ein Postfach abgelegt wird, nicht bei einer weitergeleiteten. Eine Nachricht mit Empfängern beider Art wird aufgeteilt, sodass die weitergeleitete Kopie diejenige ist, die ankam.

  • Ein Urteil, das das Wesentliche unterscheidet. valid bedeutet, die Signatur ist einwandfrei und der Schlüssel war verankert; valid-untrusted bedeutet einwandfrei mit einem Schlüssel, der sich an nichts binden ließ (ein erstmals gesehener Schlüssel, eine CA ohne Anker hier) — was der Großteil des signierten Mailverkehrs der Welt ist und was nie als valid gemeldet wird. invalid, unverifiable und none vervollständigen die Menge, und eine Nachricht mit mehreren Signaturen nimmt das schlechteste Urteil derjenigen, die den Klartext abdecken; eine Signatur, die um Chiffrat gelegt ist, kann eine Nachricht nie valid machen.

  • Beide Fehlerpfade stellen standardmäßig zu. ON_DECRYPT_FAILURE = passthrough — der Benutzer hält den Schlüssel womöglich in seinem eigenen Client, und für Mail, die wir bloß nicht öffnen konnten, einen Bounce zu erzeugen hilft niemandem. ON_BAD_SIGNATURE = record — Mailinglisten, die Nachrichtentexte umschreiben, Weiterleiter und Clients mit kaputter Kanonisierung erzeugen alle schlechte Signaturen an legitimer Mail. quarantine und bounce stehen für beide zur Verfügung.

  • Gefälschte Indikatoren werden bedingungslos entfernt. Jeder X-Pepsi-*-Header verschwindet aus jeder eingehenden Nachricht, und die eigenen Betreffmarkierungen dieser Stage verschwinden vom Anfang des Subject, bevor unsere hinzugefügt werden. X-Pepsi-Crypto ist ein privater Header und damit definitionsgemäß fälschbar; die Entfernung ist die gesamte Grundlage dafür, dass ein Client ihm glauben darf. (Pepsi-Origin liegt bewusst nicht im Namensraum und überlebt.)

  • Ein Signal, das der Benutzer tatsächlich sieht. [decrypted][verified], dem Subject in Schachtelungsreihenfolge vorangestellt — für die meisten Benutzer das einzige Signal, das sie je sehen werden, denn niemand, der Mail in einem Webmail-Client liest, sieht sich Header an. Es kann abgeschaltet werden, und der Wortlaut ist konfigurierbar.

  • Zertifikate, die die Nachricht mitführt. S/MIME-Signiererzertifikate und application/pgp-keys-Teile werden aus der Nachricht gelesen und dem Verifizierer angeboten — noch vor der Entscheidung, auf einen Schlüssel zu warten, weil die meiste signierte Mail das Zertifikat mitführt, das sie signiert hat. Sie werden benutzt und verworfen: Das Speichern dessen, was eine eingehende Nachricht lehrt, ist Sache von pepsi-stage-autocrypt-learn, das später läuft, nach den Stages, die entscheiden, ob die Nachricht Spam ist. Ein solches Zertifikat kann das Ansehen eines Urteils nur senken, nie heben — eine dagegen geprüfte Signatur ist valid-untrusted und setzt nie state.signature_verified.

  • Zwei Tatsachen, die für die Lern-Stage festgehalten werden. Das Entschlüsseln committet den Klartext über die angekommenen Bytes, sodass state.crypto.in encrypted (es gab Chiffrat) und outer_gossip (der ankommende Header-Block hatte bereits ein Autocrypt-Gossip:-Feld, das alles auf dem Weg geschrieben haben könnte) trägt. Beides sind Voraussetzungen dafür, dem Gossip einer Nachricht zu glauben, und keines ist beantwortbar, sobald der Klartext im Datensatz steht.

  • Post für den eigenen Schlüssel des Benutzers bleibt seinem Client überlassen. Eine Nachricht, die an den registrierten MUA-Schlüssel eines Empfängers verschlüsselt ist (custody = client, ein Schlüssel, dessen private Hälfte nur im Mail-Client liegt), wird an den Empfängerkennungen des Chiffrats erkannt, ohne sie zu öffnen, und ungeöffnet weitergereicht – selbst wenn einer unserer eigenen Schlüssel sie ebenfalls öffnen könnte. Sie wird als decryption = for-client festgehalten, ist kein Entschlüsselungsfehler und löst daher nie ON_DECRYPT_FAILURE aus.

  • Jeder nicht widerrufene Schlüssel wird versucht, auch abgelaufene, ausgewählt nach Fähigkeit (purpose encrypt oder both) statt nach Form. Alte Mail muss lesbar bleiben, weshalb ein Entschlüsselungsschlüssel seinen eigenen Ablauf überlebt.

34.3. Wo sie sitzt

ingress → arc → decrypt → aliases → check-whitelist → anti-spam →
detect-language → local delivery

Alles, was den Nachrichtentext liest, will Klartext und bekommt ihn, weil das Entschlüsseln früh kommt. Alles, was die Nachricht so, wie sie ankam, authentifiziert — ARC —, muss davor kommen.

Die Platzierung ist auch eine Leistungsfrage. Die Stage deklariert Load::Full, sodass jede Nachricht, die durch sie hindurchgeht, ihren gesamten Nachrichtentext aus der Datenbank lädt, selbst eine, die sich als gewöhnliche Mail herausstellt: Ob eine Nachricht geschützt ist, lässt sich den Umschlagspalten nicht ansehen, und Load ist je Stage fest. Auf einem eingehenden Pfad, der in lokaler Zustellung endet, ist das vertretbar, und es ist keine Stage, die man vor Massen-Relay-Verkehr stellt.

34.4. Auf einen Schlüssel warten

Wenn der Schlüssel des Signierenden weder in der Nachricht noch im peer_key-Cache liegt, wird die Nachricht geparkt: Eine Entdeckungsanfrage wird eingereiht, und ein pepsi-keydisc-Dienst gibt die Nachricht frei, wenn sie sich erledigt, gefunden oder nicht. So bekommt die erste Nachricht eines neuen Korrespondenten ein echtes Urteil statt unverifiable. Ein frischer Negativ-Cache-Eintrag kürzt das Warten ganz ab, sodass nur diese erste Nachricht je wartet.

Ob eine geparkte Nachricht entschlüsselt gespeichert wird, hängt von ihrer Form ab, und der Unterschied ist nicht kosmetisch. Eine in einem Umschlag geschachtelte S/MIME-Signatur überlebt das Entschlüsseln als gewöhnliche MIME-Schicht, sodass die Nachricht mit committetem Klartext geparkt und genau einmal entschlüsselt wird. Eine OpenPGP-Signatur lebt nur innerhalb des Paketstroms und ist fort, sobald der Klartext heraus ist, sodass das Committen des Klartexts genau den Beleg zerstören würde, für dessen Prüfung der Schlüssel geholt wird; eine solche Nachricht wird unverändert geparkt und beim Fortsetzen erneut entschlüsselt.

34.5. Konfiguration

[stage-<name>]: PROGRAM = pepsi-stage-decrypt, NEXT_STAGE (erforderlich) und BOUNCE_STAGE, dazu ENABLED, LOCAL_DOMAINS / TARGETS / RECIPIENT_DELIMITER / REQUIRE_ACCOUNT, ON_DECRYPT_FAILURE, ON_BAD_SIGNATURE, QUARANTINE_STAGE, SUBJECT_TAGS, TAG_DECRYPTED, TAG_VERIFIED, TAG_BAD_SIGNATURE, STRIP_SUBJECT_TAGS, STRIP_SUBJECT_KEYWORDS, ADD_RESULT_HEADER, MAX_LAYERS, TRUST_ANCHOR_TTL, DISCOVERY und DISCOVERY_TIMEOUT. Alle sind in pepsi.conf(5) dokumentiert.

Das sind Verhaltens-Optionen und je Adresse über die Tabelle pepsi.settings überschreibbar (bei eingehender Mail mit einem Umschlagempfänger als Schlüssel). Die kryptographische Richtlinie liegt in den CRYPTO_*-Optionen von [pepsi] und in [pepsi-crypto], ist ausschließlich Sache des Systemadministrators und ist bewusst aus pepsi.settings nicht erreichbar.

Eine davon gilt in dieser Richtung nicht: CRYPTO_ALLOW_DOWNGRADE regelt, was ausgegeben werden darf. SEIPDv1+MDC und AES-CBC-EnvelopedData sind immer lesbar, denn sie eingehend abzulehnen würde diesen Host unfähig machen, Mail aus dem größten Teil der Welt zu empfangen, ohne irgendjemanden zu schützen.

34.6. Privilegien

Installiert setuid pepsi-crypto, Modus 4750 pepsi-crypto:pepsi, und daher eigenständig statt in das vereinheitlichte pepsi-Binärprogramm eingefaltet — dieselbe Anordnung wie bei pepsi-stage-encrypt und aus denselben zwei Gründen: Die Datenbankrolle pepsi-crypto ist die einzige, die die Berechtigung auf crypto_identity.private_wrapped hat, und die Peer-Authentifizierung von PostgreSQL richtet sich nach der effektiven uid, und der Schlüsselverschlüsselungsschlüssel ist ein 0640-Fragment, das demselben Konto gehört. Siehe Schlüsselverwaltung für das Verwahrungsmodell.

34.7. State

Schreibt state.crypto.in: ob die Nachricht verschlüsselt ankam, was aus dem Chiffrat wurde (not-encrypted, decrypted, failed oder for-client), welche Identität sie geöffnet hat, das Signatururteil mit Signierendem, Fingerabdruck, Schlüsselquelle, Vertrauensrang und covers_plaintext, sowie die geordnete Schichtenliste. Setzt state.encrypted = true für eine verschlüsselt angekommene Nachricht und state.signature_verified = true nur für das Urteil valid — die beiden Schlüssel, die pepsi-stage-check-whitelist und pepsi-stage-auto-whitelist lesen. Bei einem Richtlinien-Bounce schreibt sie state.bounce mit dem erweiterten Status 5.7.0.

34.8. Siehe auch

pepsi-stage-encrypt (die ausgehende Hälfte), pepsi-stage-arc, pepsi-keys, pepsi-keydisc (der Dienst, der die von dieser Stage erzeugten Parkvorgänge erledigt), pepsi-stage-check-whitelist (die einen Datensatz der weißen Liste an dem state.signature_verified misst, das diese Stage setzt), Schlüsselverwaltung, Interoperabilität mit Clients, RFC-Index, pepsi.conf(5), pepsi.state(7)