Zusammenfassung

  • RFC 8314 empfiehlt implizites TLS für Mailzugriff und -übermittlung: Auf den Ports 465, 993 und 995 beginnt der TLS-Handshake unmittelbar nach dem TCP-Verbindungsaufbau und vor Anwendungsbefehlen.
  • Dieser Start schützt den Kanal. Er beweist allein weder den erwarteten Dienst noch Benutzerauthentisierung, Konto- oder Absenderrechte, Nachrichtenannahme oder endgültige Zustellung.

Im Betriebsprotokoll standen vier erfolgreiche Schritte und danach eine Ablehnung. Der Client hatte Port 465 erreicht, TLS ausgehandelt, ein Zertifikat geprüft und gültige Zugangsdaten präsentiert. Dennoch durfte das Konto die gewählte Envelope-Adresse nicht verwenden. Der Server widersprach sich nicht. Er beantwortete nacheinander Fragen über Transport, Dienst, Zugangsdaten und eine konkrete Berechtigung.

Mailprogramme machen daraus gern ein einziges Schloss. Hinter dem Symbol liegen jedoch Konfiguration, Dienstentdeckung, Netzwerkadresse, Port, TLS-Transcript, Zertifikat, Namensabgleich, Anmeldeverfahren, Kontozuordnung und Richtlinie. Ein positives Ergebnis schafft die Voraussetzung für den nächsten Schritt. Es übernimmt dessen Aussage nicht.

Keith Moore und Chris Newman veröffentlichten RFC 8314 im Jahr 2018. Das Dokument betrachtet Klartext zwischen Mail User Agent und Zugriffs- oder Submission-Server nicht mehr als angemessenen Normalfall. Für POP, IMAP und SMTP Submission empfiehlt es implizites TLS statt einer zunächst ungeschützten Anwendungssitzung, die später durch STARTTLS oder einen ähnlichen Befehl hochgestuft wird.

„Implizit“ bezeichnet den Zeitpunkt. Beim Dienst submissions auf Standardport 465 beginnt TLS direkt nach dem TCP-Aufbau. Für IMAP gilt Port 993, für POP Port 995. Erst nach erfolgreicher Aushandlung folgt das Mailprotokoll innerhalb des geschützten Kanals. Bei STARTTLS beginnt der Client mit Klartextbefehlen, liest Fähigkeiten, fordert die Hochstufung an und startet danach den Handshake.

Damit entfällt auf dem impliziten Pfad die Anwendungsphase vor TLS. Port 465 wird dadurch nicht zum kryptografischen Beweis. Die Zahl in einer Konfiguration sagt nicht, welche Adresse tatsächlich aufgelöst wurde, welcher Prozess antwortete, welches Zertifikat erschien oder ob der Client den erwarteten Namen prüfte. Beobachteter Handshake und validierte Identität müssen hinzukommen.

RFC 8314 berücksichtigt die installierte Basis. Das Dokument nennt den verbreiteten Einsatz von STARTTLS auf Port 587 und empfiehlt in einer Übergangszeit sowohl 587/STARTTLS als auch 465/implizites TLS. Es wäre falsch, daraus ein pauschales Urteil gegen jedes STARTTLS abzuleiten. Entscheidend ist, ob der Client Schutz verlangt und bei fehlender Fähigkeit oder gescheiterter Hochstufung abbricht.

RFC 2595 hatte STARTTLS für IMAP, POP3 und ACAP definiert und beschrieben, wie ein Angreifer die Fähigkeit aus dem Angebot entfernen oder den Befehl scheitern lassen kann. Ein fehlender Eintrag allein beweist keinen Angriff; Konfiguration und Softwareversion können ebenfalls die Ursache sein. Für eine Downgrade-Analyse braucht man Serverantwort, lokale Pflichtregel und Folgeaktion.

Auch TLS benötigt einen Bezugsnamen. RFC 8314 verlangt Zertifikatsvalidierung für die betreffenden Clients. RFC 9525, ein späteres Dokument anderer Autoren, beschreibt das heutige allgemeine Modell der Dienstidentität. Der Client bildet Referenzidentifikatoren aus vertrauenswürdiger Eingabe oder Konfiguration, validiert den Zertifizierungspfad und vergleicht sie mit den präsentierten Identifikatoren. Ein bei der DNS-Auflösung auftauchender Zwischenname ist nicht automatisch die ursprünglich zu prüfende Identität.

Ein erfolgreicher Vergleich authentisiert den Anwendungsdienst in diesem Geltungsbereich. Er authentisiert nicht die Person am Client, garantiert keinen fehlerfreien oder gutartigen Server und verleiht keine Autorität über Namen außerhalb des geprüften Satzes. Vor allem gewährt er keinen Zugriff auf ein Postfach. Server- und Benutzeridentität sind verschiedene Subjekte.

Ein Clientzertifikat hebt die Trennung nicht auf. RFC 8314 erlaubt dessen Einsatz, lässt den Server aber zusätzlich eine Authentisierung auf Anwendungsebene verlangen. Selbst gegenseitiges TLS belegt eine autorisierte Operation erst dann, wenn die Zuordnung vom Zertifikat zum Konto und die dazugehörige Richtlinie dokumentiert sind.

SASL benennt die Rollen ausdrücklich. RFC 4422 unterscheidet die an Zugangsdaten gebundene authentication identity von der authorization identity, als die der Client handeln möchte. Der Server prüft die Zugangsdaten und entscheidet, ob die erste Identität die zweite vertreten darf. Scheitert eines davon, scheitert der Austausch. Eine leere separate Berechtigungsidentität fordert gewöhnlich Handeln als die eigene authentisierte Identität an; die Serverrichtlinie bleibt nötig.

Submission bringt eigene Rechte mit. RFC 6409 trennt Nachrichteneinlieferung von Relay und reserviert Port 587. Ein Message Submission Agent kann nur autorisierte Benutzer zulassen und ein MAIL FROM zurückweisen, wenn die Adresse nicht ausreichend berechtigt oder mit der Authentisierung unvereinbar ist. Der TLS-geschützte Weg zum MSA genehmigt weder Absender noch Empfänger, Größe oder Inhalt vorab.

Selbst eine Annahme durch den MSA ist keine endgültige Zustellung. Sie dokumentiert die übernommene Verantwortung an diesem Punkt. Danach folgen Transfer, Antwort des Empfängersystems, Filter, Postfachablage und menschliches Lesen. „TLS erfolgreich“, „Dienst validiert“, „Benutzer authentisiert“, „Befehl autorisiert“, „Nachricht angenommen“ und „zugestellt“ benötigen getrennte Belege.

Eine reproduzierbare Kette hält deshalb erwarteten Dienstnamen und Entdeckungseingabe, aufgelöste Adresse und kontaktierten Port fest. Es folgen TLS-Startart, Transcript, Version, Zertifikat, Vertrauenspfad, Referenznamen und Abgleich. Danach werden SASL-Verfahren, Authentisierungs- und Berechtigungsidentität, Richtlinie, Befehl und genaue Antwort aufgezeichnet. Transfer- und Zustellbelege schließen später an.

Newman und Moore zogen den Schutz an den Anfang der Verbindung. Sie gaben dem Port nicht die Befugnis, alle späteren Entscheidungen zu treffen. Implizites TLS errichtet den Kanal; Benutzerrechte vergibt der Dienst.

Quellen