Transportsicherheit

Die Ende-zu-Ende-Verschlüsselung von Sealed Mail schützt die Inhalte von Nachrichten zwischen Owlat-Workspaces. Diese Seite behandelt die ergänzende Schicht: die Härtung des SMTP-Transports, sodass Mail an und von gewöhnlichen (Nicht-Owlat-)Mailservern unterwegs verschlüsselt ist und nicht stillschweigend herabgestuft werden kann — dazu die Secrets, die alles im Ruhezustand versiegelt halten.

Die eingehende Zustellung ist standardmäßig sicher: Owlat weist SMTP-Transaktionen ab, die nicht mit STARTTLS aufgewertet wurden. Die Steuerungen für ausgehenden Verkehr und Veröffentlichung bleiben bewusste Betreiberentscheidungen.

TLS für eingehende Zustellung verlangen

Einstellungen → Sealed Mail → TLS für eingehende Mail verlangen steuert die SMTP-Annahmeschwelle. Sie ist standardmäßig eingeschaltet. Solange sie aktiv ist, prüft der MTA die laufende Verbindung, bevor er MAIL FROM annimmt; ein Klartext-Absender erhält 550 5.7.10 Encryption needed, und Owlat nimmt oder speichert kein einziges Byte der Nachricht.

Konfigurieren Sie BOUNCE_TLS_CERT und BOUNCE_TLS_KEY, damit der eingehende SMTP-Server STARTTLS anbieten kann. Ohne Zertifikat und Schlüssel weist die standardmäßig aktive Schwelle jede eingehende Zustellung ab, weil Absender keinen verschlüsselten Weg haben; deaktivieren Sie die Schwelle nur als vorübergehende Notfallmaßnahme.

Eigentümer und Admins können die Schwelle für einen Alt-Absender deaktivieren, der STARTTLS nicht aushandeln kann. Ein Deaktivieren erlaubt Klartextzustellung an jede Adresse der Instanz und sollte daher eine vorübergehende Kompatibilitätsmaßnahme bleiben. Die Wahl wird mit dem Redis-gestützten SMTP-Gate des MTA synchronisiert; fehlender oder unlesbarer Policy-Zustand fällt geschlossen aus und verlangt weiterhin TLS.

Diese Annahmeschwelle verlangt Verschlüsselung, keine Zertifikatsauthentifizierung. MTA-STS im Modus enforce zu veröffentlichen ergänzt sie, indem es kompatiblen Absendern vorab mitteilt, eine zertifikatsgeprüfte TLS-Verbindung zum erwarteten MX zu verlangen.

MTA-STS veröffentlichen (eingehend)

MTA-STS (RFC 8461) erlaubt Absendern, die Mail an Ihr Deployment zustellen, eine verschlüsselte, zertifikatsgeprüfte Zustellung zu verlangen — Schutz gegen STARTTLS-Stripping-Angriffe. Sie veröffentlichen es unter Zustellung → Provider-Konfiguration („Eingehende TLS-Richtlinie (MTA-STS)“), was Eigentümern/Admins vorbehalten ist. Die Haltung wird in den Workspace-Einstellungen als mtaStsMode gespeichert und kennt drei Stufen aufsteigender Strenge:

Eine Richtlinie zu veröffentlichen hat zwei DNS-/HTTPS-Hälften, die beide auf der Seite Domains erscheinen, sobald Sie none verlassen:

1. Ein TXT-Record unter _mta-sts.<domain>, der die Richtlinie und eine kurze id ankündigt, die sich bei jeder Richtlinienänderung ändert (damit Absender neu laden).
2. Die Richtliniendatei selbst, über HTTPS unter https://mta-sts.<domain>/.well-known/mta-sts.txt ausgeliefert. Owlat liefert sie für einen konfigurierten Mail-Host automatisch aus; Sie veröffentlichen lediglich den mta-sts-DNS-Record, der darauf zeigt.

Die veröffentlichte Richtlinie verwendet ein max_age von einer Woche (der weit verbreitete Standard). Beginnen Sie bei testing, beobachten Sie das TLS-RPT-Dashboard, bis die Berichte sauber aussehen, und gehen Sie dann auf enforce.

Ausgehende TLS-Haltung (OUTBOUND_TLS_MODE)

OUTBOUND_TLS_MODE regelt die Direct-to-MX-Zustellung des eingebauten MTA — wie streng Owlat beim Versand von Mail in Sachen TLS ist. Es ist einer von drei Werten (Standard opportunistic):

Der MTA liest dies aus seiner eigenen Konfiguration; der Wert wird zusätzlich schreibgeschützt im Transport-Editor der Zustellung angezeigt, damit das erneute Anwenden einer Bearbeitung die gewählte Schwelle erhält. Ein Tippfehler (zum Beispiel require_verified mit Unterstrich) lässt den MTA-Boot sofort scheitern, statt still auf opportunistic abzufallen.

Unabhängig von dieser globalen Schwelle erzwingt Owlat bereits die veröffentlichten MTA-STS-Richtlinien anderer Domains, wenn es an sie sendet — ein Empfänger, der geprüftes TLS verlangt, bekommt es also unabhängig von Ihrem ausgehenden Modus.

DANE-Haltung (DANE_MODE)

DANE (RFC 7672) authentifiziert das TLS-Zertifikat eines Empfängers gegen einen DNSSEC-signierten TLSA-Record und schließt damit die Vertrauenslücke, die reines WebPKI lässt. Es wird über DANE_MODE am MTA geregelt, einer von drei Werten:

Der Standard ist off, passend zur festgelegten Entscheidung D6. Wählen Sie report, um DANE-Sichtbarkeit im TLS-RPT-Dashboard zu sammeln, ohne Zustellergebnisse zu verändern. Heben Sie eine Domain erst dann auf enforce, wenn der Report-only-Betrieb zeigt, dass ihre TLSA-Records sauber validieren — exakt der Weg von testing zu enforce, den Sie auch bei MTA-STS gehen.

DANE benötigt einen validierenden DoH-Resolver (DNS-over-HTTPS, RFC 8484), konfiguriert über DANE_RESOLVER_URL:

Die gesamte Sicherheit von DANE ruht auf dem DNSSEC-AD-Bit (Authenticated Data) des Resolvers, weshalb der Kanal zum Resolver einer sein muss, den ein On-Path-Angreifer nicht fälschen kann. Wenn eine Resolver-URL gesetzt ist, validiert der MTA sie beim Boot (in jedem Modus, damit ein Fehler auffällt, bevor Sie DANE aktivieren, und nicht erst am Tag der Aktivierung):

• Eine fehlerhafte DANE_RESOLVER_URL → der Boot scheitert.
• Ein entfernter Resolver ohne https: → der Boot scheitert. http: ist nur für einen Loopback-Resolver erlaubt (localhost, 127.0.0.1, ::1, *.localhost), wo es kein On-Path-Netz zum Angreifen gibt.

Wenn DANE aktiviert ist, übernimmt derselbe validierende Resolver neben der TLSA-Abfrage auch die Zielermittlung. Der MTA behält den DNSSEC-Zustand der MX- und Adressantworten, weigert sich, DANE über eine nicht authentifizierte Adresskette anzuwenden, und behandelt Resolver-Fehler im Modus enforce als temporäre Zustellfehler, statt still ohne DANE erneut zu versuchen.

Beide interoperablen SMTP-Verwendungen werden unterstützt. DANE-EE(3) authentifiziert den Leaf-Schlüssel bzw. das Leaf-Zertifikat direkt, weshalb WebPKI-Vertrauen, Zertifikatsnamen und Zertifikatsdaten bewusst ignoriert werden. DANE-TA(2) validiert die vorgelegte Kette bis zur TLSA-assoziierten CA und erzwingt weiterhin Zertifikatsgültigkeit, CA-/Signaturkette und die MX-Referenznamensregeln aus RFC 7672. Während einer Zertifikatsrotation darf jede gültige Assoziation in einem gemischten EE/TA-RRset die Gegenstelle authentifizieren. Wiederverwendbare SMTP-Verbindungen werden nach einem Fingerprint des vollständigen TLSA-RRsets und seiner Referenznamen partitioniert, sodass eine unter einer älteren Richtlinie authentifizierte Verbindung nie unter einer geänderten Richtlinie wiederverwendet wird.

Das TLS-RPT-Dashboard lesen

TLS Reporting (TLS-RPT, RFC 8460) ist die Art, wie Sie den Kreis schließen: Andere Mailserver senden Ihnen täglich aggregierte Berichte darüber, wie die TLS-Aushandlung verlief, als sie an Sie zugestellt haben. Owlat nimmt sie auf und aggregiert sie auf der Seite Zustellung → Provider-Konfiguration („Eingehende TLS-Berichte — Wie Partner uns über TLS erreichen“).

Um Berichte zu erhalten, müssen Sie einen _smtp._tls-TXT-Record veröffentlichen, der eine Berichtsadresse benennt, die Sie tatsächlich überwachen. Setzen Sie MTA_TLSRPT_RUA (zum Beispiel mailto:tls-reports@example.com oder einen https://-Collector), und Owlat gibt den Record aus — v=TLSRPTv1; rua=<address>. Ist MTA_TLSRPT_RUA nicht gesetzt, wird kein _smtp._tls-Record erzeugt (Owlat richtet kein Berichtspostfach pro Domain ein, die Berichte blieben sonst also ungelesen).

Das Dashboard zeigt über ein rollierendes 30-Tage-Fenster:

• Eine Gesamt-TLS-Erfolgsquote sowie eine Aufschlüsselung nach berichtender Organisation.
• Eine allgemeinverständliche Aufstellung etwaiger Fehlschläge — zum Beispiel „STARTTLS wurde stromaufwärts entfernt“ oder „Zertifikat passte nicht zum Servernamen“.

Die Aufnahme ist idempotent nach berichtender Organisation und report-id, sodass ein erneut zugestellter Bericht nie doppelt zählt. Beobachten Sie dieses Dashboard, solange eine Domain auf MTA-STS testing steht, bevor Sie sie auf enforce heben.

Secrets im Ruhezustand

Zwei Secrets schützen die Daten von Sealed Mail im Ruhezustand. Beide werden einmal gesetzt und müssen sicher verwahrt werden — sie zu verlieren hat echte Folgen.

MTA_SECRET

Versiegelt die eigenen Zugangsdaten des MTA im Ruhezustand: DKIM-Signierschlüssel und Relay-Zugangsdaten. Der MTA startet nicht, wenn es fehlt oder zu schwach ist, statt unter einem erratbaren Schlüssel zu versiegeln. Beschränken Sie es auf den MTA-Prozess.

INSTANCE_SECRET

Das Wurzel-Secret für alles, was Owlat auf der Convex-Seite im Ruhezustand versiegelt:

• Den Sealed-Mail-Schlüsseltresor — jeder private Versiegelungsschlüssel ist unter einer domänenseparierten Box verschlüsselt, die aus INSTANCE_SECRET abgeleitet wird.
• Nachrichtentexte im Ruhezustand — gespeicherte Bodys und Blobs sind unter separaten, domänenseparierten Schlüsseln versiegelt, die aus demselben Secret abgeleitet werden (siehe Sealed Mail im Ruhezustand).

INSTANCE_SECRET rotieren

So rotieren Sie das Instanz-Secret, ohne den Zugriff zu verlieren:

1. Setzen Sie den neuen Wert als INSTANCE_SECRET und behalten Sie den vorherigen Wert in INSTANCE_SECRET_PREVIOUS. Solange beide gesetzt sind, öffnet der Tresor jeden versiegelten Schlüssel unter dem aktuellen Secret und fällt auf das vorherige zurück, sodass Lesevorgänge mitten in der Migration weiter funktionieren.
2. Führen Sie Sealed Mail neu versiegeln unter Einstellungen → Sealed Mail („Nach dem Ändern des Instanz-Secrets“) aus. Das verschlüsselt jeden gespeicherten Schlüssel unter dem neuen Secret neu. Versiegelte Mail lässt sich durchgehend weiter öffnen.
3. Sobald das erneute Versiegeln abgeschlossen ist, entfernen Sie INSTANCE_SECRET_PREVIOUS.

Verwandt

• Sealed Mail — die Ende-zu-Ende-Verschlüsselung, die diese Transporte tragen.
• Sealed-Mail-Wiederherstellungs-Kit — die benutzergehaltenen Schlüssel, die einen Neuaufbau überdauern.
• Sealed Mail im Ruhezustand — wie gespeicherte Nachrichtentexte versiegelt werden.
• MTA-System — der eingebaute Mail Transfer Agent.