Certificate Transparency: Expect-CT HTTP-Security-Header
Wofür benötigen wir Certificate-Transparency? Vereinfacht: Der Datenverkehr zu jeder Webseite, die HTTPS verwendet, wird verschlüsselt und die Identität des Servers wird überprüft. Dazu benötigt euer Webserver ein Zertifikat. Das Zertifikat gilt als Beweis, dass der Client wirklich mit der von ihm erwarteten Domain kommuniziert und nicht mit einem Angreifer (bspw. Man-In-The-Middle-Angriff). Diese Sicherheit wird allerdings ausgehebelt, wenn ein Angreifer ein Zertifikat für eine Domain erhalten bzw. fälschen kann, die er angreifen möchte. Um dies zu verhindern, benötigen wir Certificate-Transparency.
Certificate-Transparency ist allerdings nur dann sinnvoll, wenn wir Verstöße erkennen, protokollieren und darauf reagieren können. Dafür gibt es einen HTTP-Header, der genau dies in nginx, Apache oder einem anderen Webserver ermöglicht. Sofern eine Webseite den Expect-CT-Header gesetzt hat, wird der Browser zur Prüfung aufgefordert, ob das ausgelieferte Zertifikat einer Webseite in den öffentlichen Certificate-Transparency-Logs enthalten ist. Ob eure Seite in den Logs enthalten ist könnt ihr über folgende Seite prüfen: Zertifikatstransparenz – da der HTTP-Header maßgeblich von Google entwickelt wird, führt der Link zu einer Google-Seite.
Aktuell sieht mein Expect-CT-Header folgendermaßen aus:
Expect-CT: enforce, max-age=21600
Das bedeutet:
- enforce: Signalisiert dem Browser, dass Certificate-Transparency durchgesetzt werden sollte. Falsch ausgegebene Zertifikate (keine Übereinstimmung in den Certificate-Transparency-Logs) führen zu einem Abbruch der Verbindung.
- max-age: Der Browser speichert die empfangene Richtlinie für 6 Stunden (21600 Sekunden) in einem Cache. Ist die Zeit abgelaufen, wird der Browser erneut eine CT-Richtlinie (bei einer Webseite) anfragen.
Aktuell fehlt mir noch die optionale Direktive »report-uri«. Diese legt fest, wohin der Browser eine Meldung schicken soll, falls er keine gültigen CT-Informationen für die aufgerufene Domain erhält. Das gibt dem Betreiber einer Webseite die Möglichkeit, auf mögliche Angriffe auf seine Infrastruktur bzw. das TLS-Zertifikat zu reagieren. Für diesen Zweck existiert der Dienst bzw. die Webseite Report URI, die allerdings nicht gerade datenschutzfreundlich (Clouflare, Google-APIs etc.) ist. Daher bin ich aktuell am überlegen, ob und wie ich diese Report-URI umsetze.
Insgesamt wird das Certificate-Transparency-System dafür sorgen, dass Angriffe mittels fälschlicherweise ausgestellten Zertifikaten unwahrscheinlicher werden.
Hinweis
Aktuell wird der Expect-CT-Header nur von Google Chrome (ab Version 61) und Opera (ab Version 48) unterstützt. Erwartungsgemäß werden weitere Browser-Hersteller folgen.
Der TC-String des Interactive Advertising Bureau (IAB) – Teil2
Microsoft Edge: Datensendeverhalten Desktop-Version – Browser-Check Teil4
HTTP Security Header prüfen
Online-Werbung: Real Time Bidding und IAB-Standards – Teil1
