Zusammenfassung

  • STARTTLS ließ die TCP-Verbindung bestehen, setzte NNTP aber nahezu auf den Zustand nach der Begrüßung zurück.
  • Der Server vergaß aktuelle Gruppe und Artikelnummer; der Client durfte der alten Fähigkeitsliste nicht mehr vertrauen.
  • TLS schützte einen Abschnitt und war weder automatische NNTP-Anmeldung noch Beweis für Autor oder gesamte Relay-Kette.

Eine Leitung mit zwei Vertrauensgeschichten

RFC 977 beschrieb NNTP als zustandsbehaftetes Gespräch aus Begrüßung, Befehlen und Antworten. RFC 4642 setzte mitten hinein eine Grenze. Nach 382 gehörte das nächste Oktett bereits zum TLS-Handshake. Der Befehl durfte nicht in einer Pipeline stehen; ein Fehlschlag konnte beide Seiten in einem unbestimmten Zustand lassen und sollte zum Schließen führen.

Bei Erfolg blieb dieselbe Verbindung erhalten. Das Anwendungsprotokoll kehrte dennoch fast an den Punkt nach der ersten Begrüßung zurück. Der Server musste vor TLS gewonnenes Wissen über den Client verwerfen, darunter Gruppe und Artikelnummer. Der Client durfte die zuvor gelesene Fähigkeitsliste nicht weiterverwenden.

Verschlüsselung wirkt nicht rückwärts. Ein aktiver Angreifer konnte Klartext verändern. Würde dessen Auswahl nach TLS fortgelten, schützte der Kanal lediglich die Ausführung einer manipulierten Voraussetzung.

Fähigkeiten gelten für einen Zeitpunkt

RFC 3977 definiert CAPABILITIES als Auskunft für genau diesen Sitzungszustand. Die Liste kann sich ändern. Nach TLS wird sie neu abgefragt; STARTTLS verschwindet, zertifikatsabhängige Authentisierungsverfahren können hinzukommen.

Ein Cache aus einer früheren Sitzung reicht für die Sicherheitsentscheidung nicht. Ein Angreifer kann das STARTTLS-Angebot löschen. Umgekehrt kann der Client sich merken, dass ein Server TLS früher anbot, und beim Verschwinden warnen. Innerhalb der Sitzung verhindert Vergessen Kontamination; zwischen Sitzungen hilft Erinnerung gegen Herabstufung.

Die Wirkung eines früheren MODE READER bleibt bestehen. Diese Ausnahme zeigt: Der Reset war kein blindes Löschen, sondern eine definierte Rückkehr, die unsicher erworbenem Wissen seine Autorität nahm.

Zertifikat ist noch kein NNTP-Konto

Auch mit Clientzertifikat bleibt der Server im nicht authentisierten NNTP-Zustand. RFC 4643 zeigt nach TLS eine neue Fähigkeitsabfrage und anschließend AUTHINFO SASL. EXTERNAL kann die Zertifikatsidentität nutzen, doch die Anwendung entscheidet separat. STARTTLS verpflichtet nicht zur Unterstützung dieses Mechanismus.

TLS schützt Bytes, ein Zertifikat bindet Namen und Schlüssel, NNTP vergibt Rechte. Diese Ebenen dürfen sich nicht gegenseitig Autorität unterschieben.

Dasselbe gilt für die Reichweite. Ein Netnews-Artikel kann mehrere Server passieren. TLS schützt nur das jeweilige Paar. Ein authentisiertes Relay beweist weder den Autor noch den Empfangsweg davor. Der IANA-Eintrag bestätigt STARTTLS als standardisierte Transportsicherheitsfähigkeit, nicht eine konkrete Ende-zu-Ende-Verbindung.

NNTP bewahrte also den Anschluss und verwarf die falsche Gewissheit. Es fragte neu, baute Zustand neu auf und ließ Anmeldung eine eigene Entscheidung bleiben. Sicherheit begann dort, wo Klartextwissen nicht nachträglich geadelt wurde.

Quellen