Zusammenfassung

  • IMAP COMPRESS aktivierte DEFLATE erst nach einem getaggten OK: Der Server komprimierte direkt nach dessen abschließendem CRLF, der Client ab seinem nächsten Befehl.
  • Die Historie, die wiederkehrende Befehle, Kopfzeilen und Text verkürzte, band alle späteren Bytes an verborgenen Zustand. Spätere Sicherheitsregeln erklärten das Risiko beobachtbarer Längen, belegten aber keinen speziellen IMAP-COMPRESS-Angriff.

Ein CRLF trennte zwei Lesarten desselben Stroms

IMAP ordnete das Gespräch bereits durch getaggte Befehle, ungetaggte Daten und ein Endergebnis mit dem Tag des Clients. RFC 4978 erfand keine neue Antwortart. Der Server bot COMPRESS=DEFLATE an, der Client bat mit COMPRESS DEFLATE darum, und bekannte Ergebnisse wie OK, NO oder BAD verkündeten die Entscheidung.

Die gewöhnliche Form verbarg eine strenge Pause. Vor dem Ergebnis durfte der Client keinen weiteren Befehl senden. Nach OK musste sein erster folgender Befehl komprimiert sein. Der Server übertrug die erfolgreiche Antwort selbst noch unkomprimiert und aktivierte den Encoder unmittelbar nach ihrem abschließenden CRLF. Eine Ablehnung ließ beide Richtungen unverändert.

Damit erhielt eine einzelne Byteposition Autorität. Schaltete der Client zu früh um, gelangte Klartext in den Dekompressor. Wartete der Server eine Antwort zu lange, deutete der Client komprimierte Bits als IMAP-Grammatik. TCP konnte jedes Byte vollständig und geordnet liefern; die Sitzung scheiterte trotzdem, wenn die Endpunkte seinen Inhalt unterschiedlich verstanden.

Eine Capability versprach keine Ersparnis

Die Anzeige bestätigte nur, dass der Server den Algorithmus verstand. Sie versprach weder eine kleinere Mailboxübertragung noch vertretbare CPU-Kosten oder Vertraulichkeit. Jeder Sender bestimmte die Kompressionsarbeit seiner Richtung; die Gegenseite musste den erzeugten Strom entschlüsseln können.

Die Ablehnungsregeln hielten diese Aussage eng. War derselbe Mechanismus schon in einer anderen Schicht aktiv, konnte der Server NO mit COMPRESSIONACTIVE melden. Eine zweite Aktivierung der Erweiterung war ungültig. Zwei Verhandlungsflächen gaben kein Recht, denselben zustandsbehafteten Vorgang doppelt zu stapeln.

Auch teilten beide Richtungen kein einziges magisches Wörterbuch. Wiederkehrende Clientbefehle bauten die Historie zum Server auf. Antwortformen, Feldnamen und Nachrichten bildeten die Historie zurück zum Client. Jeder Sender erinnerte seine eigenen Ausgaben.

Die Schichten folgten nicht der Reihenfolge der Befehle

Eine Sitzung konnte zusätzlich eine SASL-Sicherheitsschicht oder TLS erhalten. Für den Versand galt eine feste Folge: zuerst COMPRESS, danach gegebenenfalls SASL-Signatur oder -Verschlüsselung, schließlich TLS. Beim Empfang wurden die Schritte rückwärts ausgeführt.

Diese Ordnung blieb bestehen, auch wenn der Client die Funktionen in einer anderen zeitlichen Reihenfolge angefordert hatte. Verhandlungschronik und Datentransformation waren verschiedene Tatsachen. COMPRESS musste den IMAP-Zustand kennen und war kein unsichtbares Rohr unterhalb des Protokolls.

Der heutige IMAP4rev2-Kern wahrt dieselbe allgemeine Disziplin bei Sicherheitsübergängen: Das Ende der Erfolgsantwort bestimmt den Beginn der neuen Schicht. Eine langlebige Verbindung darf Darstellung oder Schutz nur ändern, wenn beide Seiten dieselbe Grenze anerkennen.

Wiederholung machte die Historie wertvoll

IMAP bot günstiges Material. Der Client wiederholte wenige Verben. Der Server wiederholte Antwortformen und Namen von Mailkopfzeilen. Nachrichten eines Gesprächsfadens zitierten frühere Sätze. Eine fortlaufende Historie konnte solche Folgen später durch kurze Verweise ersetzen.

Anhänge störten das Muster. Ein bereits komprimiertes Archiv oder JPEG schrumpfte womöglich kaum, verdrängte nützliche IMAP-Muster aus dem Wörterbuch und verbrauchte Rechenzeit für Material, das nicht wiederkehrte. Die Spezifikation erörterte vollständige Flushes um große Literale und geringeren Aufwand für vermutlich unkomprimierbare Formate. Das waren lokale Entscheidungen, keine neuen IMAP-Befehle.

Gerade die Nähe zur Anwendung war der Vorteil. Sie wusste, ob als Nächstes Syntax, Kopfzeilen, Text oder ein Literal folgte. Dieses Wissen verbesserte die Ersparnis und machte die Anwendung zugleich für den aufgebauten Kontext verantwortlich.

Verschlüsselung beseitigte die Länge nicht

2007 verwies der Sicherheitsabschnitt von RFC 4978 in einem Satz auf damalige TLS-Kompressionsfragen. Später untersuchte Angriffe veränderten die Bewertung. CRIME und verwandte Arbeiten zeigten, dass Inhalte verschlüsselt sein können, während ihre Länge beobachtbar bleibt. Gelangen ein Geheimnis und vom Angreifer beeinflusster Text in dieselbe Historie, können wiederholte Varianten erkennen lassen, wann eine Vermutung zum Geheimnis passt.

Die von der IETF zusammengefassten Fälle betreffen TLS und das Web. Sie beweisen weder einen Angriff auf IMAP COMPRESS noch die Verwundbarkeit jeder IMAP-Sitzung. Sie zeigen jedoch, weshalb „erst komprimieren, dann verschlüsseln“ keine vollständige Vertraulichkeitsanalyse ist.

Aktuelle TLS-Praxis rät von gewöhnlicher TLS-1.2-Kompression ab, außer eine Anwendung wurde als unanfällig nachgewiesen und selbst dann nur mit äußerster Vorsicht; TLS 1.3 entfernte sie. Dieselbe Empfehlung warnt vor Lecks durch Kompression oberhalb von TLS, die TLS nicht beheben kann. Protokollwissen schafft bessere Quoten und die Pflicht zu entscheiden, welche Eingaben gemeinsam erinnert werden dürfen.

Verborgener Zustand brauchte einen Eigentümer

Die logischen IMAP-Nachrichten blieben gleich, doch ihre kodierten Bytes hingen nun von früheren Bytes ab. Der Nutzen bestand nur bei fortlaufender Einigkeit über Aktivierung, Richtung, Algorithmus und Kontext. Dekompressionsfehler, Ressourcenerschöpfung oder ein Vertraulichkeitsverdacht waren in einem verschlüsselten Mitschnitt nicht einfach sichtbar.

Die bleibende Lehre ist kein pauschales Verbot. Benenne den Kontext, die Einflussnehmer seiner Eingaben, die Beobachter seiner Ausgabelänge, seine Lebensdauer, seine Ressourcengrenzen und den sicheren Abschaltweg. Eine Optimierung mit Gedächtnis ist bereits eine Zustandsmaschine.

Quellen und Grenzen

Das DEFLATE-Format definiert RFC 1951. IMAP-Capability, Umschaltgrenze, Schichtfolge und Tuning stammen aus RFC 4978. RFC 7457 fasst die Angriffsklasse zusammen, RFC 9051 beschreibt den heutigen IMAP-Kern, RFC 9325 die aktuelle TLS-Empfehlung, und die Capability steht weiter im IANA-IMAP-Register. Diese Quellen messen keine heutige Nutzung und dokumentieren keinen konkreten IMAP-COMPRESS-Einbruch.