Zusammenfassung

  • STARTTLS setzte TLS in eine bestehende SMTP-Verbindung ein, übernahm aber nicht die Autorität des ersten Klartextdialogs: Nach dem Handshake verwarfen beide Seiten dieses Wissen, und der Client sandte EHLO erneut.
  • Der Neustart hielt veränderbare Vorbehauptungen aus dem geschützten Kanal heraus. Er erzwang weder Verschlüsselung noch Ende-zu-Ende-Authentisierung; DANE und MTA-STS lieferten später externe Regeln gegen stillen Rückfall.

Eine Verbindung begann zweimal

Ein SMTP-Server begrüßt den Client mit 220. Der Client stellt sich per EHLO vor, der Server nennt seine Erweiterungen. STARTTLS ergänzte diese Grammatik 1999 um ein parameterloses Wort. Der Client sendete STARTTLS; ein weiteres 220 beendete die Klartextphase und leitete den TLS-Handshake ein.

Damit blieben Port und MX-System erhalten. Alte Clients konnten weiterarbeiten, neue entdeckten Verschlüsselung auf der bereits geöffneten Verbindung. Die Mail-Infrastruktur musste für die Migration nicht geteilt werden.

Doch die Entdeckung fand vor dem Schutz statt. Ein Angreifer auf dem Pfad konnte den ersten EHLO-Namen ändern, Fähigkeiten entfernen oder die STARTTLS-Zeile löschen. Die ersten Bytes führten zur kryptografischen Grenze, waren aber kein Beleg für Entscheidungen dahinter.

Verschlüsselung verlangte Vergessen

Nach erfolgreichem TLS kehrt SMTP in seinen Anfangszustand zurück. Der Server verwirft den ersten EHLO-Parameter; der Client verwirft die erste Erweiterungsliste. Danach grüßt der Client erneut.

Das zweite EHLO ist kein Ritual. Es gehört in einen anderen Beweiskontext. Ein Server kann ein Authentisierungsverfahren erst nach einem geeigneten Client-Zertifikat bekanntgeben. Ein Client kann Funktionen erst nach der Prüfung des Servernamens akzeptieren. Der Handshake beglaubigt frühere Aussagen nicht rückwirkend; er lässt sie ablaufen.

Die Grenze ordnet auch die Bytes. Nach 220 muss TLS beginnen, bevor ein weiterer SMTP-Befehl gesendet wird. In einer PIPELINING-Gruppe steht STARTTLS zuletzt. So wird weder ein Klartextbefehl als Handshake gelesen noch eine Entscheidung aus dem alten Zustand in den neuen verschoben.

Ein geschützter Kanal brauchte weiterhin ein Urteil

TLS kann Vertraulichkeit, Integrität und Peer-Authentisierung liefern. Ein abgeschlossener Handshake entscheidet jedoch nicht, ob das Ergebnis genügt. Erwarteter Name, Vertrauensanker, Algorithmen und Client-Nachweise bleiben lokale Richtlinie. Beide Seiten dürfen abbrechen.

Diese Trennung begrenzt das Versprechen. Schutz vor passivem Mithören authentisiert nicht zwingend den beabsichtigten MX. Ein authentisierter Relay-Server beweist nicht den menschlichen Autor. Ein geschützter SMTP-Hop sagt nichts Verlässliches über vorherige und folgende Hops.

Die Antwort 454 macht die Wahl sichtbar. Ist TLS vorübergehend nicht verfügbar, kann der Sender im Klartext fortfahren, warten oder scheitern. Die Erweiterung liefert einen Mechanismus, aber keine automatische Erlaubnis zur Offenlegung.

Interoperabilität begrenzte das erste Gebot

Ein öffentlicher MX musste Nachrichten nicht aktualisierter Sender annehmen können. RFC 3207 verbot daher einem öffentlich referenzierten Server auf Port 25, STARTTLS generell für lokale Zustellung zu verlangen. Private Systeme und Relay-Richtlinien durften strenger sein.

Der Kompromiss bewahrte Erreichbarkeit und erleichterte die schrittweise Einführung. Zugleich blieb die STARTTLS-Anzeige ohne dauerhaftes Gebot. Löschte ein Angreifer sie, konnte ein opportunistischer Client einen gewöhnlichen Nicht-TLS-Server vermuten und Klartext zustellen.

Nicht TLS versagte. Die Pflicht, TLS zu benutzen, wurde in genau dem ungeschützten Dialog mitgeteilt, den der Angreifer bearbeiten konnte.

Die Richtlinie wanderte aus dem Gespräch

DANE für SMTP band die TLS-Verpflichtung und Authentisierungsdaten des Ziels an DNSSEC-validierte TLSA-Einträge. Existiert ein sicherer, anwendbarer Eintrag, erlaubt eine fehlende STARTTLS-Zeile keinen Klartext mehr. Ohne den geforderten Kanal wird die Nachricht verzögert.

MTA-STS wählte einen anderen Vertrauenspfad. Der Empfänger signalisiert eine Richtlinie und stellt sie per HTTPS bereit. Der Sender speichert zulässige MX-Muster, PKIX-Anforderungen und eine Gültigkeitsdauer. Im Erzwingungsmodus führen fehlendes STARTTLS oder ein ungültiges Zertifikat zur Warteschlange. Die erste Entdeckung bleibt anders verwundbar als eine DNSSEC-gesicherte Negation; der Cache verkleinert spätere Angriffsfenster.

Beide Verfahren behalten STARTTLS als Übergang im SMTP-Dialog. Nach außen verlegt wird die Autorität über die Frage, ob ohne diesen Übergang zugestellt werden darf.

Die dauerhafte Erfindung war die zweite Begrüßung

STARTTLS nur als Wechsel von Klartext zu Chiffre zu erinnern, verfehlt die wichtigste Lehre. Der alte Zustand erhielt ein Verfallsdatum. Fähigkeiten wurden neu entdeckt, Identität nach benannter Richtlinie geprüft und ein Rückfall von einer gewöhnlichen Störung getrennt.

Jedes alte Protokoll mit neuer Sicherheitsschicht trägt dieselbe Schuld. Neue Kryptografie reinigt keine Entscheidungen, die bereits auf veränderbaren Eingaben beruhten. Das System muss bestimmen, welcher Zustand die Grenze überschreiten darf, welcher gelöscht wird und wer schwächeren Betrieb genehmigen kann.

Quellen und Grenzen

Der ursprüngliche Entwurf und die Warnung vor gelöschter Anzeige stehen in RFC 2487; überarbeitete Regeln, Zustandsreset und Interoperabilitätsgrenze in RFC 3207. RFC 7672 definiert DANE für SMTP, RFC 8461 MTA-STS. Diese Normen messen weder heutige Verbreitung noch weltweite Angriffszahlen.