Zusammenfassung

  • Unmittelbar nach dem CRLF der Antwort 206 galt Kompression in beiden Richtungen und blieb bis zum Ende der Verbindung aktiv.
  • Danach waren STARTTLS, AUTHINFO und MODE READER ausgeschlossen; TLS, Authentisierung und Kompression konnten nur in genau dieser Reihenfolge zusammenkommen.
  • Weil die Kompression vor SASL und TLS arbeitete, wurden Wörterbuchgrenzen, sichtbare Längen, Flush und Streamschäden zu Sicherheits- und Betriebsfragen.

Eine Capability, die nach Gebrauch verschwand

Vor der Anfrage nennt der Server COMPRESS DEFLATE. Nach dem Erfolg fehlt das Label. Auch STARTTLS ist verschwunden. Eine aktuelle Capability-Liste erzählt damit nicht bloß, was die Software grundsätzlich kennt, sondern welche Übergänge diese konkrete Verbindung noch erreichen kann.

RFC 3977 lässt Capability-Antworten innerhalb einer Sitzung wechseln. RFC 8054 verbietet für die sicherheitsrelevante Kompression ausdrücklich, eine Liste aus einer früheren Verbindung als heutige Zusage zu behandeln.

Ein Client, der an seinem Cache festhält, kann daher eine syntaktisch richtige, aber zustandswidrige Sequenz planen. Der Server antwortet dann 502. Der gegenwärtige Stream besitzt mehr Autorität als die frühere Werbung.

Die Umschaltung lag hinter dem CRLF

206 Compression active wird noch unkomprimiert übertragen. Direkt nach dem abschließenden CRLF beginnt die neue Schicht für Client und Server. Ab dem nächsten Byte müssen beide denselben Kompressionszustand anwenden.

Darum darf COMPRESS nicht gepipelined werden. Der Client wartet auf die Entscheidung, bevor er den nächsten Befehl schreibt. Bei Ablehnung bleibt es bei normalen NNTP-Zeilen; bei Erfolg gehört alles Folgende zum komprimierten Strom.

Fehlerhafte Syntax, ein unbekannter Algorithmus und fehlende Aktivierungsressourcen führen über verschiedene Antworten zurück in den alten Zustand. Nur Erfolg überschreitet die Grenze und verändert die verbleibende Lebenszeit der Verbindung.

Eine Verbindungsschicht ersetzte Sonderbefehle

Nicht standardisierte Vorläufer komprimierten einzelne Serverantworten. Sie erfassten nicht die Gegenrichtung und machten Kompression zur Eigenschaft vieler Kommandovarianten. RFC 8054 legte stattdessen eine verlustfreie Schicht unter alle späteren Befehle und Antworten.

Wiederholte Clientbefehle, lange Listen, Artikelheader und Textkörper konnten dieselbe Technik nutzen. Der informative Leistungsteil beschreibt je nach Datentyp sehr unterschiedliche Wirkungen: Mehrzeilenantworten können stark profitieren, kurze Antworten oder bereits codierte Anhänge wenig. Daraus folgt weder ein heutiger Messwert noch ein universeller Vorteil.

DEFLATE aus RFC 1951 war der einzige definierte und verpflichtend zu implementierende Algorithmus. Jeder Sender durfte für seine Richtung eine vernünftige Stufe wählen; der Empfänger musste sich darauf einstellen. Zwei Richtungen teilten den Vertrag, nicht zwingend die Einstellung.

Der Erfolg war nicht rückgängig zu machen

Nach der Aktivierung waren eine zweite Kompression und eine spätere TLS-Aushandlung untersagt. Der Server bewarb beide nicht mehr und wies gültige Befehle ab. Auch MODE READER durfte der Client nicht nachschieben.

Einen Gegenbefehl gab es nicht. Wer die Kompression beenden wollte, schickte QUIT und baute eine neue Verbindung auf. Das verhinderte, dass eine Seite schon rohe Zeilen sendet, während die andere noch einen DEFLATE-Block erwartet.

Der harte Schnitt war außerdem eine Recovery-Regel. Ein neuer Anfang erzeugt eindeutigen Zustand. Ein Versuch, innerhalb des alten Stroms den Umschaltpunkt zu erraten, kann keine verlorene Wörterbuchhistorie beweisen.

Ein Passwort durfte dem Kompressor nicht folgen

Kompression spart Bytes, indem sie neue Zeichenfolgen mit gespeicherten Mustern vergleicht. Verschlüsselung verdeckt den Inhalt, aber nicht notwendig die Länge des komprimierten Ergebnisses. Kann ein Angreifer bekannte Eingabe beeinflussen und Längen beobachten, werden Übereinstimmungen mit einem Geheimnis messbar. RFC 8054 nennt CRIME und BREACH als Beispiele.

Anmeldedaten waren das klarste vermeidbare Geheimnis. Nach erfolgreichem COMPRESS durfte ein nicht authentisierter Client kein AUTHINFO mehr versuchen. Der Server ließ nutzbare Argumente aus der Capability verschwinden und antwortete auf den Befehl mit 502.

RFC 4643 definiert die NNTP-Authentisierung. Die Kompression übernimmt sie nicht. Sie setzt nur die Zustandsgrenze, nach der Zugangsdaten nicht mehr in eine bereits beobachtbare Kompressionsgeschichte eingebracht werden dürfen.

Die einzige Reihenfolge für alle drei Eigenschaften

Sollte eine Verbindung TLS, Kontoidentität und Anwendungskompression erhalten, verlangte RFC 8054 die Folge STARTTLS, AUTHINFO, COMPRESS. Zuerst entstand nach RFC 4642 der geschützte Transport, dann wurde die Identität bestätigt, zuletzt die Kompressionsentscheidung getroffen.

Die drei Beweise blieben getrennt. TLS authentisiert nicht automatisch das Benutzerkonto. AUTHINFO verschlüsselt keinen Transport. COMPRESS erteilt keine Berechtigung. Reihenfolge ordnet unterschiedliche Zuständigkeiten, sie verschmilzt sie nicht.

Beim Senden folgte daraus eine feste Schichtung: zuerst COMPRESS, dann eine vorhandene SASL-Sicherheitsschicht, zuletzt TLS. Beim Empfang lief die Verarbeitung rückwärts. Der Kompressor sah Muster, bevor Verschlüsselung sie unkenntlich machte.

Wörterbuchumfang wurde Datenpolitik

Öffentliche und vertrauliche Artikel sollten unter einer aktiven Sicherheitsschicht nicht dieselbe Kompressionsgeschichte teilen. Bekanntes oder beeinflussbares öffentliches Material kann sonst eine Vergleichsbasis für die Länge vertraulicher Daten liefern.

Auch unterschiedliche vertrauliche Artikel sollten nach Möglichkeit getrennte Wörterbücher erhalten. Das Leeren des DEFLATE-Zustands ist eine genannte Gegenmaßnahme. Sie wechselt weder Schlüssel noch Identität, sondern begrenzt, welche Vergangenheit eine künftige Länge beeinflussen darf.

Die Spezifikation verbietet verschlüsselte Kompression nicht pauschal. Sie rät davon ab, sie unter einer Sicherheitsschicht automatisch einzuschalten, solange der Benutzer die Konsequenz nicht bewusst gewählt hat.

Beschädigter Zustand beendete die Sitzung

Alle an den Kompressor übergebenen Daten mussten in der Ausgabe erscheinen und so geflusht werden, dass die Gegenstelle sie vollständig dekomprimieren konnte. Der Sender konnte die Stufe um schlecht komprimierbare Inhalte ändern, durfte aber Interaktion nicht im Puffer verstecken.

Ungültige oder beschädigte komprimierte Daten führten zum sofortigen Schließen. Die Gegenstelle suchte nicht nach einer plausiblen nächsten NNTP-Zeile. Nach einer Wörterbuchabweichung ist Syntax allein kein Beweis für gemeinsame Bedeutung.

Abbruch und Neuaufbau machten den Zustand wieder zurechenbar. Das Protokoll opferte die Verbindung, statt eine Kontinuität zu behaupten, deren gemeinsame Vorgeschichte verloren war.

Weniger Verkehr brauchte eine verantwortete Reihenfolge

Das IANA-Register der NNTP-Parameter verzeichnet COMPRESS und DEFLATE. Es schafft gemeinsame Namen und Referenzen, bestätigt aber weder Einsatz, Leistung noch sichere Konfiguration eines Servers.

Die allgemeine Schicht reduzierte Redundanz in beiden Richtungen und vermied einen Katalog von Sonderbefehlen. Dafür wurde ihr Erfolg zu einer dauerhaften Zustandsentscheidung, die spätere Sicherheitswege schloss.

Der historische Punkt liegt somit nicht in einer Kompressionsquote. Eine Optimierung mit Erinnerung verändert, was danach noch sicher verhandelt werden kann. Schutz und Identität mussten zuerst kommen; die Schicht, die sich den Klartext merkt, musste zuletzt folgen.

Quellen