10.11. HTTPS – Transportverschlüsselung für den Server

Bisher war alles einfaches HTTP auf Port 80. Jeder, der einen Paketmitschnitt zwischen Browser und Kamera anfertigt, kann das Passwort des Login-Formulars, das daraufhin zurückkommende Sitzungs-Cookie, das JWT im Authorization-Header und die JPEG-Bytes jedes erfassten Einzelbilds lesen. HTTPS verschlüsselt die Leitung Ende zu Ende.

Der Zertifikats-Workflow selbst – das Erzeugen eines selbstsignierten Zertifikats für die Entwicklung, das Beschaffen eines CA-signierten Zertifikats für die Produktion, das Kopieren der Dateien im richtigen Format auf die Kamera – wird in Arbeiten mit TLS-Zertifikaten behandelt. Auf dieser Seite geht es darum, ein bereits geladenes Zertifikat in microdot einzubinden.

10.11.1. Aufbau des SSL-Kontexts

ssl.SSLContext ist der Container der Standardbibliothek für Zertifikat, Schlüssel und Protokolloptionen. Für einen Server möchten Sie PROTOCOL_TLS_SERVER und eine vom Dateisystem der Kamera geladene Zertifikatskette:

import ssl

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ctx.load_cert_chain('/flash/cert.der', '/flash/key.der')

Die DER-Pfade stammen aus dem Workflow, den Sie im TLS-Abschnitt ausgeführt haben – selbstsigniert für die Entwicklung, CA-signiert für die Produktion. Die Dateien müssen nicht auf /flash liegen; /sdcard funktioniert ebenso gut.

10.11.2. Den Kontext an start_server übergeben

Der einzige Unterschied zum früheren start_server()-Aufruf ist das Argument ssl=ctx und die Portnummer. Port 443 ist der HTTPS-Standard, was bedeutet, dass Browser kein :443 eingeben müssen – https://yard-cam.local/ funktioniert einfach:

async def main():
    await asyncio.gather(
        capture_loop(),
        motion_detector(),
        app.start_server(host='0.0.0.0', port=443, ssl=ctx),
    )

asyncio.run(main())

Das war es für die Serverseite. Jede vorhandene Route – /status, /snapshot.jpg, /stream.jpg, /config, /events, /control, das statische Dashboard – läuft nun über TLS, ohne dass weitere Codeänderungen nötig sind.

10.11.3. Das Sitzungs-Cookie absichern

Das Sitzungs-Cookie wurde als Platzhalter mit secure=False erstellt. Mit eingerichtetem HTTPS stellen Sie es auf True um, sodass das Cookie niemals über einfaches HTTP gesendet wird – selbst wenn ein falsch konfigurierter Client oder ein veralteter Link es versucht:

Session(app, secret_key=SECRET,
        cookie_options={'http_only': True, 'secure': True})

Dasselbe gilt für das _remember-Cookie, das login_user() schreibt, wenn remember=True gesetzt ist – microdot übernimmt das secure-Flag aus demselben cookie_options-dict.

10.11.4. Was hier nicht behandelt wird

HTTP Strict Transport Security (HSTS), die automatische Zertifikatserneuerung, die CA-Vertrauenskette auf der Kameraseite für ausgehende Anfragen und die Wahl der Cipher Suites finden sich alle im TLS-Abschnitt. Das Einbinden hier – ein SSLContext, ein ssl=ctx – ist der einzige Teil, der spezifisch für microdot ist.

Die URL-Leiste des Dashboards wechselt nun von http:// zu https:// und der WebSocket von ws:// zu wss:// – das JavaScript des Dashboards hat das richtige Schema bereits anhand von location.protocol gewählt, sodass keine Client-Änderungen nötig sind.

Die Kamera liefert über HTTPS aus. Das Login-Formular, das JWT und die erfassten Einzelbilder sind während der Übertragung verschlüsselt.