HTTP Sec-WebSocket-Key Header

Der HTTP-Header Sec-WebSocket-Key ist ein Request-Header im WebSocket-Handshake, der einen zufälligen Nonce vom Client zum Server sendet. Er enthält eine Base64-kodierte 16-Byte Zufallszahl und wird vom Server zur Berechnung von Sec-WebSocket-Accept verwendet nach RFC 6455.

Typ

Request-Header

Syntax

Der Header gibt einen Base64-kodierten Nonce als String an.

http 
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

Direktiven

Die Direktiven definieren den kryptographischen Nonce für WebSocket-Handshake.

<nonce-value>
Base64-kodierte 16-Byte (128-Bit) Zufallszahl. Muss bei jedem Handshake neu generiert werden. Client darf nicht vorhersehbare oder wiederverwendete Werte senden.
Security Requirement
Browser generiert Nonce automatisch, JavaScript kann Wert nicht setzen. Verhindert Scripting-Attacks die Handshake manipulieren.

Beispiele

Nachfolgend finden Sie praktische Anwendungsbeispiele für den Sec-WebSocket-Key-Header.

Beispiel 1 WebSocket Handshake Initiierung

http 
GET /chat HTTP/1.1
Host: websocket.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://app.example.com

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Browser generiert zufälligen Key, Server berechnet Accept-Hash als SHA-1(Key + Magic GUID), Client validiert korrekte Berechnung.

Beispiel 2 Mehrere gleichzeitige Connections

http 
GET /stream1 HTTP/1.1
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==

GET /stream2 HTTP/1.1
Sec-WebSocket-Key: AQIDBAUGBwgJCgsMDQ4PEA==

Zwei parallele WebSocket-Connections vom gleichen Client haben unterschiedliche Keys, verhindert Connection-Confusion und Replay-Attacks.

Beispiel 3 Server validiert Key Format

http 
GET /ws HTTP/1.1
Sec-WebSocket-Key: invalid-key

HTTP/1.1 400 Bad Request
Content-Type: text/plain

Invalid Sec-WebSocket-Key format. Must be base64-encoded 16 bytes.

Server validiert Key-Format vor Handshake-Processing, lehnt ungültige Keys mit 400 Bad Request ab.

WebSocket Key Generation Flow

Sec-WebSocket-Key Handshake Ablauf

Vorteile für die Systemarchitektur

  • Prevent Caching Issues: Zufälliger Nonce verhindert, dass Caching-Proxies WebSocket-Handshake-Responses cachen und wiederverwenden
  • Protocol Confirmation: Accept-Hash beweist, dass Server WebSocket-Protocol versteht und Request nicht als HTTP-GET misinterpretiert
  • Replay Protection: Jeder Handshake hat einzigartigen Key, verhindert Replay-Attacks von aufgezeichneten Handshake-Sequenzen

Spezifikation

RFC 6455, Section 4.1 – WebSocket Protocol https://www.rfc-editor.org/rfc/rfc6455.html#section-4.1

Weitere Spezifikationen

Sec-WebSocket-Accept Header, Upgrade Header