Zusammenfassung

  • RFC 2384 vereinte Host, Port, Postfachidentität und Authentisierungswahl in einer POP-URL, schloss aber das Klartextpasswort aus der Zeichenfolge aus.
  • Die URL war dennoch keine Vollmacht für ein gespeichertes Geheimnis: Erst vertrauenswürdige Herkunft, lokale Richtlinie, Bestätigung, Serverprüfung oder ein nicht wiederverwendbares Verfahren erlaubte den nächsten Schritt.

Eine vollständige Adresse war noch kein vollständiger Vorgang

Ein POP3-Programm brauchte mehrere Konfigurationswerte: Server, womöglich einen besonderen Port, die Identität des Postfachs und ein Authentisierungsverfahren. RFC 2384 fasste sie in pop://<user>;auth=<auth>@<host>:<port> zusammen.

Nur der Host war zwingend. Ohne Port galt 110. Identität und Verfahren konnten fehlen. Ungeeignete Zeichen ließen sich kodieren. Die Konfiguration konnte damit als eine einzige Zeichenfolge gespeichert oder weitergegeben werden.

Doch die URL war lediglich genug, um einen Versuch zu beginnen. Sie bewies weder die Vertrauenswürdigkeit ihrer Quelle noch die Berechtigung des Hosts, ein Geheimnis zu erhalten. Sie bewies keine erfolgreiche Authentisierung und keinen Zugriff auf das beabsichtigte Postfach. RFC 2384 ist deshalb auch eine frühe Lektion über Beweisschichten: Eine vollständig interpretierbare Anweisung ist noch kein Beleg für ihre Berechtigung oder Wirkung.

Das Passwort fehlte in der URL, nicht unbedingt im Ablauf

Klartextpasswörter waren in der POP-URL verboten. Das begrenzte eine offensichtliche Gefahr, denn URLs gelangen in Dokumente, Protokolle, Konfigurationsspeicher und Benutzeroberflächen.

Ein Client konnte das Passwort jedoch bereits gespeichert haben oder es nach dem Öffnen der URL abfragen. Er konnte APOP oder über AUTH ein SASL-Verfahren einsetzen. Eine passwortlose URL konnte also sehr wohl den Versand eines Passworts oder anderer Zugangsdaten auslösen.

Der RFC warnte, dass URLs leicht aus nicht vertrauenswürdigen Quellen stammen können. Zugangsdaten an den falschen Server gefährdeten das Konto. Für Clients mit gespeichertem Klartextpasswort galt deshalb eine strikte Grenze: Sie durften es aufgrund einer POP-URL nicht verwenden, wenn der Benutzer nicht ausdrücklich erlaubt hatte, es genau an den bezeichneten Hostnamen zu übermitteln.

Das Problem lag nicht nur im Inhalt der Referenz. Es lag in der Verfügungsmacht, die Software einer empfangenen Referenz über bereits vorhandene Geheimnisse einräumte.

Autorisierung und Authentisierung teilten sich ein Wort

Das Dokument sprach vereinfachend vom Benutzernamen, unterschied aber zwei Funktionen. Die Autorisierungsidentität bestimmte das zu öffnende Postfach. Die Authentisierungsidentität bestimmte, wessen Geheimnis geprüft wurde. Gleiche Schreibweise bedeutete nicht gleiche Rolle.

Auch das Verfahren blieb eine eigene Entscheidung. Eine URL konnte SASL, APOP oder eine Erweiterung verlangen. War ein bestimmtes Verfahren genannt, sollte der Client nicht ohne ausdrückliche Zustimmung ein anderes einsetzen. Die Referenz beschrieb einen begrenzten Vorschlag, keine Erlaubnis zur stillen Abweichung.

AUTH=* öffnete dagegen die Auswahl. Der Client sollte ein geeignetes vom Server unterstütztes Verfahren bestimmen. Bemerkenswert war die Voreinstellung: Stand ein Benutzername ohne Verfahren in der URL, wurde dieser Platzhalter angenommen. Die scheinbar kürzere Konfiguration konnte damit mehr unausgesprochene Politik enthalten.

RFC 2384 verlangte besondere Vorsicht, weil der Platzhalter auf ein schwächeres Verfahren zurückfallen konnte. Die damalige Erwähnung von mehr als 56 Bit Verschlüsselung ist historisch, keine heutige Empfehlung. Bestand hat die Struktur: Auslassung verschiebt Entscheidungsmacht, und Fallback ist Sicherheitsverhalten.

Fünf verschiedene Grundlagen für die Freigabe

Die Grammatik sollte Vertrauen nicht vortäuschen. Stattdessen nannte RFC 2384 fünf Bedingungen; mindestens eine sollte erfüllt sein, bevor eine URL den Einsatz von Zugangsdaten bewirkte.

Die URL konnte von einer validierten, nach Standortregeln vertrauenswürdigen Verweisquelle stammen. Eine ausdrückliche lokale Richtlinie konnte den Server zulassen. Der Benutzer konnte die Verwendung von Zugangsdaten oder Verfahren für die konkrete Domäne bestätigen. Das Verfahren konnte den Server prüfen, bevor kompromittierendes Material übertragen wurde. Oder es konnte so beschaffen sein, dass der Empfänger nichts zur Gefährdung künftiger Verbindungen erhielt.

Diese Wege waren keine austauschbaren Vertrauenssätze. Der erste belegte Herkunft, der zweite administrative Delegation, der dritte eine situative menschliche Entscheidung, der vierte die Identität der Gegenstelle. Der fünfte senkte den möglichen Schaden einer falschen Gegenstelle.

Wer die URL schrieb, bestimmte einen vorgeschlagenen Weg. Daraus entstand kein automatisches Recht auf den Passwortspeicher des Clients.

Absolut hieß nicht vertrauenswürdig

Relative POP-URLs waren untersagt. Eine Postfachreferenz durfte ihren Host nicht aus einer umgebenden Basisadresse beziehen. Das Ziel musste in einer absoluten URL stehen.

Damit verschwand eine Auflösungsmehrdeutigkeit, nicht das Autorisierungsproblem. Auch ein Angreifer kann einen vollständigen Hostnamen schreiben. Korrekte Kodierung kann zum falschen Betreiber führen. Eine breite Suffixregel kann mehr Hosts erfassen als beabsichtigt. Syntaktische Vollständigkeit ist ein Beleg für Interpretierbarkeit, nicht für Befugnis.

Deshalb braucht es zwei getrennte Nachweise: welche Bestandteile der Parser las und warum Zugangsdaten an dieses Ziel gehen durften. Der erste darf den zweiten nicht ersetzen.

Zwei Beispiele scheiterten an ihren eigenen Bytes

Die Errata machen diesen Unterschied messbar. Im APOP-Beispiel stimmte der gedruckte Digest nicht mit der gezeigten Server-Challenge und dem Beispielpasswort überein. Das verifizierte Erratum 2943 lieferte den korrigierten Wert. Ein weiteres Beispiel nannte SCRAM-MD5, obwohl das einschlägige Verfahren damals CRAM-MD5 war. Erratum 2942 wurde für eine Dokumentaktualisierung zurückgestellt, weil mit dem Namen auch der kodierte Austausch geändert werden musste.

Das sind keine Berichte über einen Produktivvorfall und keine Widerlegung des Schemas. Sie belegen etwas Engeres: Ein protokollartig aussehendes Transkript kann bei der Ausführung falsch sein. Verfahrensname, Antwortberechnung, Authentisierungserfolg und Postfachzugriff sind verschiedene Tatsachen.

Laufender Code akzeptiert keine bloße Ähnlichkeit. Ein Digest passt zu seinen Eingaben oder nicht. Eine Implementierung kennt ein Verfahren unter seinem richtigen Namen oder kann es nicht ausführen. Die Wirklichkeit entsteht an der Berechnungs- und Interaktionsgrenze, nicht durch überzeugende Typografie.

Eine dünne gemeinsame Schicht

POP3 blieb bewusst einfach. RFC 1939 trennte Autorisierungs-, Transaktions- und Aktualisierungszustand. RFC 1734 definierte AUTH, RFC 2222 den SASL-Rahmen, RFC 2449 später die Fähigkeitsanzeige. RFC 2384 machte aus der URL keinen Ersatz für diese Protokollteile.

Die gemeinsame Spezifikation blieb minimal: Ressource und vorgeschlagenes Verfahren transportierbar darstellen. Herkunftsvertrauen, Zielberechtigung, Benutzerentscheidung, Serverprüfung und Freigabe des Geheimnisses blieben lokal, wo Belege tatsächlich bewertet werden konnten.

So wurde Konfiguration portabel, ohne Autorität mitzuliefern. Unterschiedliche Clients konnten dasselbe Format verstehen und dennoch ihre eigenen Sicherheitsgrenzen behalten.

Auch nach der Verbindung blieben die Ergebnisse getrennt. Erreichbarkeit bewies keine Freigabe des Geheimnisses. Erfolgreiche Authentisierung bewies nicht das richtige Postfach. Ein geöffnetes Postfach bewies nicht den Abruf der beabsichtigten Nachricht. Empfangene Bytes bewiesen keine korrekte Speicherung oder Anzeige.

RFC 2384 erleichterte das Benennen eines Postfachs. Seine größere Leistung bestand darin, aus dem Namen keinen Anspruch auf den Schlüssel zu machen.

Quellen