Zusammenfassung

  • Nach erfolgreicher TLS- und SASL-Aushandlung ersetzte XMPP den aktuellen XML-Stream, ohne das normale </stream> zu senden und ohne die darunterliegende TCP-Verbindung zu beenden.
  • Der neue Header, die neue Stream-ID und die aktualisierten Merkmale beschrieben den neuen Stand. TCP-Lebenszeichen, Verschlüsselung, Peer-Prüfung, SASL-Erfolg, Ressourcenbindung und Stanza-Zustellung blieben getrennte Tatsachen.

Der sicherere Kanal durfte die alte Aussage nicht adeln

Ein Client öffnet einen XMPP-Stream. Der Server bietet STARTTLS an, der Client stimmt zu, der TLS-Handshake gelingt. Technisch könnte man sich vorstellen, den bisherigen XML-Stream nun einfach verschlüsselt fortzusetzen. Genau das schließt der Standard aus.

Der Initiator sendet auf der bereits verschlüsselten TCP-Verbindung einen neuen Anfangs-Header. Den alten Stream beendet er vorher nicht mit dem üblichen Schlusstag. Der Empfänger antwortet mit einem neuen Header, erzeugt eine neue Stream-ID und nennt die Merkmale, die nach TLS gelten.

Auch SASL-Erfolg führt an eine solche Grenze. <success/> bestätigt das Ergebnis der Authentisierung und macht zugleich den Stream, der den Austausch getragen hat, unbrauchbar. Ein weiterer Stream beginnt auf demselben TCP. Erst dort kann der Server die Möglichkeiten nach erfolgreicher Authentisierung anbieten.

Das ist keine widersprüchliche Definition von Erfolg. Ein Verhandlungsschritt ist erfolgreich, gerade weil er den Kontext so stark verändert, dass der alte nicht weiterverwendet werden darf.

Verbindung und Stream folgten verschiedenen Lebensläufen

RFC 6120 behandelt TCP und XML-Stream als getrennte Objekte. TCP überträgt in beide Richtungen. Ein einzelner XMPP-Stream ist streng genommen gerichtet; zwei Gegenrichtungen bilden den Dialog.

Erfordert eine Funktion einen Neustart, gelten die bisherigen Streams als ersetzt. Die Parteien senden keinen normalen Abschluss und trennen TCP nicht. Sie nutzen die bestehende Verbindung weiter, die durch TLS oder eine SASL-Sicherheitsschicht bereits einen anderen Zustand haben kann. Der Initiator eröffnet neu, der Empfänger vergibt eine frische ID.

„Neu verbinden“ wäre daher die falsche Beschreibung. Eine TCP-Neuverbindung würde eine neue Transportassoziation schaffen. Der XMPP-Neustart bewahrt sie und verwirft nur den XML-Verhandlungskontext. Er ist ebenso wenig eine Wiederaufnahme früherer Nachrichten: Aus ihm folgt weder deren Empfang noch ein Replay oder eine Anwendungswirkung.

Auf einem Socket liefen mehrere Uhren: TCP-Laufzeit, Beginn des TLS-Schutzes, SASL-Ergebnis und Lebensdauer jeder Stream-Generation. Eine Oberfläche, die all das auf „verbunden“ reduziert, kann keinen belastbaren Zeitpunkt nennen.

Merkmale waren ein Angebot für diesen Moment

Stream features enthielten obligatorische und freiwillige Verhandlungsschritte. Solange eine Pflichtfunktion vorhanden war, war die Aushandlung nicht abgeschlossen und der Initiator noch nicht generell für normale Stanzas freigegeben. Eine leere Liste oder ausschließlich freiwillige Funktionen zeigte dagegen die mögliche Fertigstellung.

Die Schichtenfolge TCP, TLS, SASL, XMPP bestimmte das Angebot. Welche SASL-Mechanismen ein Server zeigt, kann von TLS abhängen. Ressourcenbindung für einen Client erscheint erst nach erfolgreicher Authentisierung.

Nach jedem Neustart musste der Empfänger die Merkmale aktualisiert senden. Die Liste war also kein dauerhaftes Datenblatt des Servers. Sie beschrieb, was dieser Peer unter den gegenwärtigen Bedingungen noch tun muss oder darf.

Auch das Fehlen einer Funktion ist relativ. Sie kann noch nicht zulässig, bereits erledigt oder durch Richtlinien ausgeblendet sein. RFC 7590 weist außerdem darauf hin, dass ein Angreifer STARTTLS oder den required-Hinweis entfernen kann. Ein Mitschnitt belegt die sichtbare Antwort auf diesem Weg, nicht das gesamte Können der Gegenstelle.

TLS zwang beide Seiten, unsicher Gelerntes wegzuwerfen

Nach erfolgreichem TLS verlangt RFC 6120, Informationen zu verwerfen, die oberhalb von TCP vor der Verschlüsselung unsicher empfangen wurden. Beispiele sind eine from-Adresse, die alte Stream-ID und die zuvor genannten Merkmale.

Ohne diese Regel könnte ein aktiver Vermittler vor TLS eine Behauptung verändern. Wenn die Software sie nach TLS behält, würde der geschützte Kanal einer nie geschützten Aussage nachträglich Glaubwürdigkeit verleihen. Neue Header sind deshalb keine bloße Begrüßung, sondern erneuern die Provenienz.

Verschlüsselung darf trotzdem nicht mit Peer-Authentisierung zusammenfallen. TLS-Version, Parameter, Zertifikat oder anderes Prüfmittel, Zielname, Prüfergebnis und lokale Entscheidung sind verschiedene Felder. RFC 7590 verschärft die XMPP-Praxis, verlangt Client-seitige Serverprüfung und Server-seitige Clientprüfung und bevorzugt stark die Authentisierung zwischen Servern. Zugleich behandelt er verschlüsselte, aber nicht authentisierte Verbindungen als schwächere Sonderfälle.

Der post-TLS-Stream beweist einen Protokollübergang. Welche Identität dabei bestätigt wurde, muss aus der eigentlichen Prüfung hervorgehen.

SASL-Erfolg war kein Freibrief für Stanzas

RFC 4422 definiert SASL als Rahmen für austauschbare Authentisierungsmechanismen in verbindungsorientierten Protokollen. Authentisierungsidentität, Autorisierungsidentität, Ergebnis und mögliche Datensicherheitsschicht sind getrennt. Nicht jeder Mechanismus liefert denselben Schutz.

XMPP profiliert SASL in XML und fordert anschließend einen neuen Stream auf dem vorhandenen TCP. Der Server vergibt eine neue ID und bietet die Merkmale der authentisierten Phase an. <success/> besagt jedoch nicht, dass der Client jede XMPP-Vorbedingung erfüllt hat.

Für Client-Server-Verbindungen bleibt Ressourcenbindung verpflichtend. Sie ordnet dem authentisierten Konto und Stream einen resourcepart zu und unterscheidet parallele verbundene Ressourcen. Der Server zeigt <bind/> erst im post-SASL-Stream.

Sendet der Client vorher eine Stanza an eine andere Entität als den Server oder sein eigenes Konto, darf der Server sie nicht verarbeiten und muss den Stream mit not-authorized schließen. TCP kann offen, TLS geschützt und SASL erfolgreich sein, während die Anwendung noch nicht senden darf.

Damit bleiben Authentisierung und Autorisierung sichtbar getrennt. Die Stream-ID ist keine Benutzeridentität, die Ressourcenbindung kein Zustellbeleg und lokale Annahme keine Aussage über die entfernte Anwendung.

Nach der Bindung war ein weiterer Neustart verboten

RFC 6120 schreibt ausdrücklich vor, nach Ressourcenbindung nicht neu zu starten. Diese Ausnahme erklärt die Regel: XMPP setzte nicht nach jedem positiven Ergebnis reflexartig zurück.

TLS und SASL verändern die Sicherheits- oder Identitätsbedingungen, unter denen frühere Angaben entstanden. Bindung findet bereits im authentisierten neuen Stream statt und vervollständigt die Adressierung, ohne dessen Header ungültig zu machen.

Eine Implementierung braucht deshalb einen semantischen Zustandsautomaten. Kein Neustart nach TLS ist falsch. Kein Neustart nach SASL ist falsch. Ein Neustart nach Binding kann ebenfalls falsch sein. Entscheidend ist nicht das Wort Erfolg, sondern welche bisherigen Tatsachen der Schritt entwertet.

Für Beobachter entsteht eine nützliche Beweiskette: TCP offen, TLS ausgehandelt, Peer geprüft, SASL beendet, Ressource gebunden, Stanza lokal angenommen, remote zugestellt. Jede Stufe hat eigenen Urheber und eigene Unsicherheit.

2011 ordnete, was 2004 bereits vorgeschrieben war

RFC 3920 vom Oktober 2004 verlangte bereits neue Streams nach TLS und nach SASL-<success/>. Es nannte die Reihenfolge TCP, TLS, SASL und XMPP und betrachtete den alten Stream an den Erfolgspunkten ohne vorherigen Schlusstag als beendet.

RFC 6120 löste das Dokument 2011 ab und machte daraus ein allgemeineres Modell: bisherigen Stream ersetzen, Verbindung wiederverwenden, neue ID erzeugen, aktualisierte Funktionen senden. Die Neuerung war nicht der Neustart selbst, sondern seine klare Einordnung in eine mehrstufige Aushandlung.

RFC 7590 verschärfte 2015 die TLS-Empfehlungen. Damit blieb eine wichtige Grenze bestehen: Eine korrekte XMPP-Abfolge garantiert noch keine angemessene Kryptographie, Zertifikatsprüfung oder Downgrade-Abwehr.

Die historische Leistung liegt in einer nüchternen Form von Kontinuität. Ein teurer Transport darf fortbestehen, wenn er funktioniert. Ein Anwendungskontext darf nicht allein deshalb überleben, wenn sich die Bedingungen seiner Wahrheit verändert haben.

Quellen