Den Accept-Wert berechnen

Dein Parser übergibt dem Server jetzt ein Dictionary, und darin enthält headers["sec-websocket-key"] den Schlüssel des Clients als String ohne Leerzeichen drumherum. Bevor der Server Ja sagen kann, braucht er den einen Wert, den sein Ja tragen muss: Sec-WebSocket-Accept, berechnet aus diesem Schlüssel. Diese Lektion berechnet ihn, und RFC 6455 gibt dir ein genaues Ergebnis, mit dem du vergleichen kannst.

Was der Wert beweist

RFC 6455, Abschnitt 1.3, erklärt, warum der Server überhaupt etwas berechnen muss. Der Server muss dem Client zeigen, dass er diesen WebSocket-Handshake empfangen und als solchen verstanden hat. Ein Server, der kein WebSocket spricht, oder ein Cache zwischen den beiden, der aus einer gespeicherten Antwort antwortet, hat keinen Grund, aus einem Header namens Sec-WebSocket-Key irgendetwas zu berechnen. Weil der Client für jede Anfrage einen neuen Schlüssel wählt, passt keine gespeicherte oder erfundene Antwort. Wenn der Wert in der Antwort also der ist, den der Client erwartet, weiß der Client, dass seine Anfrage etwas erreicht hat, das sie verstanden hat.

Mehr beweist er nicht. Das Rezept unten ist öffentlich und verwendet nichts Geheimes, also kann jeder den Wert für jeden Schlüssel berechnen. Er zeigt nicht, wer den Server betreibt, er verschlüsselt nichts, und er ist kein Passwort. Er ist eine Prüfung, dass beide Seiten dasselbe Protokoll sprechen.

Das Rezept

Der RFC legt noch eine Zutat fest, einen 36 Zeichen langen String, den jeder WebSocket-Server der Welt verwendet, notiert in Abschnitt 1.3 des RFC:

258EAFA5-E914-47DA-95CA-C5AB0DC85B11

Er steht in ws_handshake.py als Konstante GUID. Der RFC hat ihn gewählt, weil Programme, die WebSockets nicht verstehen, ihn wahrscheinlich nicht verwenden, und genau das macht das Ergebnis aussagekräftig. Der Accept-Wert ist:

1. der Schlüsseltext, mit angehängtem GUID;

2. mit "ascii" in Bytes kodiert, da jedes Zeichen in beiden ASCII ist;

3. mit SHA-1 gehasht, was einen 20 Byte langen Digest ergibt;

4. in base64 geschrieben, was 28 Zeichen ergibt;

5. zurück in einen str dekodiert, weil er als Text in einen Header kommt.

Beide Werkzeuge kennst du aus HTTP with Python. hashlib hat in Kapitel 8 aus einem Body einen Fingerabdruck gemacht, dort mit SHA-256. SHA-1 funktioniert über hashlib.sha1 genauso: Es nimmt Bytes und gibt ein Hash-Objekt zurück, dessen .digest() die rohen Bytes sind und dessen .hexdigest() derselbe Wert als hexadezimaler Text ist, zwei Zeichen pro Byte. SHA-1 gilt für Sicherheitszwecke nicht mehr als vertrauenswürdig, aber der RFC verwendet es nicht für Sicherheit; er verwendet es als festes Rezept, dem beide Seiten folgen können. base64 hat in Kapitel 7 Bytes als Header-Text transportiert.

Der Digest und der Hex-Text sind leicht zu verwechseln, also vergleiche sie an einem Wert, der nichts mit WebSockets zu tun hat:

Es gibt 20 40 v5l2ih1SSK6sFm0W6rvnBjTvc4I= aus. Die 20 Bytes des Digests werden zu 40 hexadezimalen Zeichen oder zu 28 base64-Zeichen mit einem = als Auffüllung. Der Accept-Wert ist das base64 des Digests, der dritte dieser Werte. Der 40 Zeichen lange Hex-Text ist ein anderer Wert, und ein Client, der ihn mit den 28 Zeichen vergleicht, die er erwartet, lehnt den Handshake ab.

import hashlib

sha = hashlib.sha1(b"x")
print(len(sha.digest()), len(sha.hexdigest()))

Text, keine dekodierten Bytes

Der Schlüssel ist base64, und du hast ihn in Lektion 1 dekodiert, um seine 16 Bytes zu sehen. Das verleitet dazu, die dekodierten Bytes zu hashen. Der RFC tut das nicht: Er hasht den Schlüssel genau so, wie der Client ihn gesendet hat, die 24 Zeichen des Header-Werts ohne umgebende Leerzeichen, gefolgt von der GUID. Dein Parser hat die Leerzeichen um den Wert bereits entfernt, also ist key + GUID so, wie es dasteht, der richtige Text.

Für den Beispielschlüssel des RFC, dGhlIHNhbXBsZSBub25jZQ==, ist das Ergebnis der Wert, den RFC 6455 abdruckt:

s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Wenn deine Funktion etwas anderes liefert, vergleiche ihre Schritte mit der Liste oben. Ein Wert mit falscher Länge bedeutet meist den Hex-Text statt des Digests oder einen anderen Hash als SHA-1. Ein Wert mit richtiger Länge, der trotzdem abweicht, bedeutet, dass die Eingabe falsch war: die GUID fehlt oder ist vertippt, oder der Schlüssel wurde vor dem Hashen dekodiert.

Deine Aufgabe

Schreibe in ws_handshake.py die Funktion accept_value(key): Gib den base64-Text des SHA-1-Digests von key + GUID, als ASCII kodiert, als str zurück. Zwei Zeilen genügen. Lass die Funktionen für die Lektionen 4 bis 6, wie sie sind.

Klicke auf Run. Der Abschnitt zu Lektion 3 in handshake_demo.py gibt jetzt den Accept-Wert für den Schlüssel des RFC aus, unter dem Dictionary aus Lektion 2:

Lesson 3: accept_value
s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Das ist eine Zeile aus einem lokalen Lauf der fertigen Lektion. Vergleiche sie Zeichen für Zeichen mit dem Wert des RFC oben. Wenn sie übereinstimmen, klicke auf Submit. Die Prüfung ruft accept_value mit dem Schlüssel des RFC und mit Schlüsseln auf, die du nicht gesehen hast, und sie prüft, dass das Ergebnis Text ist, keine Bytes.

Der Server kann jetzt seinen Nachweis berechnen. Die nächste Lektion entscheidet, wann er ihn sendet und was er stattdessen sendet, wenn die Anfrage keine ist, die er annehmen sollte.