Zusammenfassung

  • WebSocket-Maskierung ist keine Vertraulichkeit: Der vier Byte lange Schlüssel steht im Frame, doch seine Unvorhersehbarkeit entzieht der Anwendung die vorherige Wahl des exakten Leitungsbilds.
  • Die Regel reagierte auf einen konkreten Fehler von Vermittlern: Client-Frames brauchen jeweils einen neuen Schlüssel, Server-Frames dürfen nicht maskiert sein, und die Anwendung darf einen Frame nach Sendebeginn nicht mehr verändern.

Die ersten Frames vertrauten ihren Grenzen

Der IETF-Entwurf vom Mai 2010 beschrieb einen bidirektionalen Browserkanal nach einer HTTP-Eröffnung. Sein frühes Drahtformat war bewusst klein: 0x00 eröffnete einen Text-Frame, 0xff beendete ihn; eine andere Form trug eine Länge. Für zwei korrekte WebSocket-Endpunkte genügten diese Grenzen.

Sie beherrschten jedoch nicht jedes bereits installierte Gerät im Pfad. Ein Interception-Proxy konnte Upgrade weiterreichen und danach trotzdem nach einer weiteren HTTP-Anfrage in den folgenden Bytes suchen. Die Endpunkte hatten die Grammatik gewechselt, der Parser dazwischen nicht.

Der Vermittler musste dafür nicht bösartig sein. Browser und Server konnten ihre Vereinbarung erfüllen. Es genügte, dass ein dritter Beteiligter den nächsten Bytes das falsche Protokoll zuordnete und dadurch einen Cache-Effekt erzeugte, den keine der beiden Seiten genehmigt hatte.

Eine feste Verkleidung ließ die Auswahl beim Absender

Im Januar 2011 verlangte Entwurf -04 bereits die Maskierung jedes Frames vom Client zum Server. Der Schlüssel wurde jedoch aus Werten der Eröffnung abgeleitet und blieb für die gesamte Verbindung gleich.

Eine stabile Transformation ändert das Aussehen, aber nicht die Ergebniskontrolle eines Senders, der sie kennt. Die Anwendung kann einen Eingang berechnen, der einen gewünschten Ausgang erzeugt. Verwirrend ist die Darstellung dann nur für jemanden, der die Regel noch nicht gelernt hat.

Die benötigte Eigenschaft war präziser: Pro Frame durfte die Anwendung den logischen Inhalt bestimmen oder die nächste Transformation kennen, nicht aber beides vor der Festlegung der Leitungsbytes. Jeder Frame brauchte einen neuen Bindungsmoment.

Ein Proxy gab der Antwort den falschen Namen

Die Studie von 2011 Talking to Yourself for Fun and Profit untersuchte Browser-Socket-Verfahren im Beisein transparenter, genauer gesagt eingreifender Proxys. Manche Geräte leiteten Zustimmung oder Upgrade weiter, ohne den Zustandswechsel zu verstehen, und lasen spätere, vom Angreifer kontrollierte Daten als HTTP-Anfrage.

Die Schadenskette durchquerte mehrere Zuständigkeiten. Eine bösartige Website veranlasste den Browser zu einer Verbindung mit dem Angreiferserver. Der verwirrte Vermittler deutete spätere Bytes als Anfrage nach einer anderen Ressource. Der Angreiferserver lieferte antwortähnliche Daten. Der Cache speicherte diese unter der falschen Identität, sodass spätere Nutzer Inhalte erhielten, die nicht vom genannten Ursprung stammten.

Im Werbeexperiment vom März 2011 fanden die Forscher Cache-Poisoning-Bedingungen in einem kleinen, aber nicht nullgroßen Anteil der gemessenen Java- und Flash-Pfade. Unter 47.338 Upgrade-basierten WebSocket-Strohmann-Handshakes, die den Test erreichten, waren acht Fälle erfolgreich. Diese Zahlen gehören zu jenem Experiment und Zeitpunkt; sie sind keine Bestandsaufnahme heutiger Proxys.

Die dauerhafte Erkenntnis lag nicht in der Quote. Ein nicht nach HTTP aussehendes Präfix konnte nie beweisen, dass jeder unbekannte fehlerhafte Parser es beachten würde; einer konnte es überspringen und an der Nutzlast neu beginnen. Robuster war es, feindlichem Anwendungscode die gezielte Kontrolle über die Darstellung der Nutzlast auf der Leitung zu nehmen.

Der Schlüssel wanderte in jeden Frame

Der Entwurf -05 vom Februar 2011 vollzog den entscheidenden Schritt. Jeder Client-Frame erhielt einen eigenen 32-Bit-Schlüssel aus einer starken Entropiequelle; aus früheren Schlüsseln durfte der nächste nicht vorhersagbar sein. RFC 4086 erklärt die Vorsicht: Ausgaben können statistisch unregelmäßig wirken und für einen Gegner dennoch vorhersehbar bleiben, etwa bei Uhren, Zählern oder einem zu kleinen Startwertraum.

Die endgültige RFC 6455 behielt das Frame-Modell. Das MASK-Bit zeigt vier Schlüsseloktette an. Nutzlastoktett i wird per XOR mit Schlüsseloktett i mod 4 kombiniert. Die Nutzlastlänge bleibt gleich und zählt den Schlüssel nicht mit.

Jeder Empfänger kann das XOR rückgängig machen. Das ist beabsichtigt. Die Anwendung muss den Inhalt festlegen, bevor sie den unvorhersehbaren Schlüssel kennt; der Server muss den Schlüssel empfangen, um den Inhalt wiederherzustellen. Die Reihenfolge der Entscheidungen trägt die Sicherheitseigenschaft, nicht Geheimhaltung.

Mit dem Sendebeginn wurde der Frame unveränderlich

Ein neuer Schlüssel genügt nicht, wenn eine Anwendung ihn aus dem bekannten Anfang eines langen Frames ableiten und den noch nicht gesendeten Rest umschreiben darf. Der Anfang verrät die wiederholte Vier-Byte-Transformation; ein veränderliches Ende könnte anschließend so gewählt werden, dass es maskiert wie eine HTTP-Anfrage aussieht.

RFC 6455 zieht deshalb eine zeitliche Grenze. Sobald die Übertragung eines Client-Frames beginnt, darf die Anwendung dessen Nutzlast nicht mehr verändern. Neue oder geänderte Daten gehören in einen anderen Frame, der einen weiteren frischen Schlüssel erhält.

Das ist mehr als die Anweisung, Zufall zu verwenden. Vor dem Start kontrolliert die Anwendung die Bedeutung. Danach verwahrt die Client-Implementierung eine festgelegte Bytefolge. Ohne diese Übergabe ließe sich die Beobachtung des Anfangs wieder in Kontrolle über das Ende verwandeln.

Die Richtung beschrieb das Bedrohungsmodell

Jeder Frame vom Client zum Server muss maskiert sein; ein Server darf Frames zum Client nicht maskieren. Der Server muss bei einem unmaskierten Client-Frame schließen, der Client bei einem maskierten Server-Frame. Fehlercode 1002 kann den Protokollverstoß benennen.

Die Asymmetrie folgt der Angriffskette. Für eine falsche Cache-Identität brauchte sie anfrageähnliche Bytes in Richtung Browser zu Server. Ein bösartiger Server kann ohnehin antwortähnliche Daten wählen; ohne die gefälschte Anfrage fehlt dem verwirrten Cache aber der falsche Ressourcenname, der die Vergiftung vollendet.

Serverdaten werden dadurch nicht vertrauenswürdig. Authentifizierung, Autorisierung, Origin-Regeln, Inhaltsprüfung und Kanalschutz behalten eigene Aufgaben. Maskierung in Gegenrichtung war lediglich nicht die Kontrolle für diesen Infrastrukturfehler.

TLS machte die Maske nicht überflüssig

Client-Maskierung gilt für ws ebenso wie innerhalb von TLS für wss. Unter Verschlüsselung wirkt sie unnötig, weil ein Gerät im Pfad einen korrekt geschützten TLS-Strom nicht lesen kann. Die Verträge unterscheiden sich jedoch: TLS schützt Vertraulichkeit und Integrität zwischen seinen Endpunkten. Maskierung beschränkt, welche Frame-Nutzlastbytes nicht vertrauenswürdiger Browsercode einen konformen WebSocket-Client ausgeben lassen kann.

Die einheitliche Regel verhindert zudem, dass Frame-Gültigkeit davon abhängt, wo TLS endet. Ein Gateway kann TLS vor einem weiteren internen Hop terminieren, und eine Bereitstellung kann sich ändern. Der Schutz einer Schicht erteilt der Grammatik einer anderen keine stillschweigende Ausnahme.

Neue HTTP-Transporte behielten die alte Pflicht

RFC 8441 startete WebSocket später mit Extended CONNECT in einem HTTP/2-Stream. Weil :protocol den Übergang signalisiert, entfielen dort die HTTP/1.1-Verarbeitung von Sec-WebSocket-Key und Sec-WebSocket-Accept. Die Frame-Maskierung blieb: Die Sicherheitsbetrachtungen von RFC 6455 gelten weiter, ausgenommen die handshake-spezifische SHA-1-Diskussion in Abschnitt 10.8.

RFC 9220 übertrug Extended CONNECT auf HTTP/3, ohne eine neue Sicherheitsausnahme einzuführen. Die äußere Eröffnung änderte sich vom Wechsel einer ganzen HTTP/1.1-Verbindung zu einem ausgewählten HTTP/2-Stream und dann zu einem QUIC-Stream. Der WebSocket-Frame behielt denselben Richtungsnachweis.

Diese Kontinuität zeigt: Die Maske war kein Notbehelf für die Schreibweise eines Upgrade-Headers. Sie kodierte das Verhältnis zwischen Anwendungswahl, Client-Bindung und Vermittlerverwirrung, das den Wechsel des umgebenden Transports überdauerte.

Was der öffentliche Schlüssel belegt — und was nicht

Ein frischer Schlüssel belegt keine Identität, keine Origin-Zulassung, keine Autorisierung und keine Integrität außerhalb eines geschützten Transports. Einen Schlüssel im Mitschnitt zu sehen ist normal. Wiederverwendung oder Vorhersagbarkeit sind dagegen Anzeichen für eine gebrochene Annahme.

Konforme Maskierung repariert auch nicht jeden Vermittler. RFC 6455 weist darauf hin, dass nicht konforme Clients und Server verwundbare Proxys weiterhin derselben Angriffsklasse aussetzen können. Das Protokoll begrenzte, wozu sich ein konformer Browserpfad verleiten lässt; es übernahm nicht die Kontrolle über jeden Cache im Internet.

Die historische Lehre ist eng und beständig: Wenn alte Infrastruktur Bytes unter der falschen Grammatik lesen könnte, darf ein neues Protokoll nicht nur seinen eigenen korrekten Wechsel verkünden. Es muss unter Umständen auch begrenzen, welche gefährlichen Muster ein nicht vertrauenswürdiger Teilnehmer absichtlich auf den gemeinsamen Pfad legen kann.

Quellen und Grenzen der Evidenz

Entwürfe und RFCs belegen die Designentwicklung und das normative Verhalten. Die Studie beschreibt ein begrenztes Experiment von 2011, keine gegenwärtige Schwachstelle oder Marktverteilung. Keine Quelle belegt das Verhalten eines bestimmten modernen Browsers, Proxys, CDN oder Gateways. Maskierung ist weder Verschlüsselung noch Integritätsschutz, Endpunktauthentifizierung oder Beweis für die Herkunft einer Cache-Antwort.