HTTP jetzt auch einfach mit S

Für den gemeinen Datenreisenden gibt es wohl kaum eine Maßnahme, die dessen Privatsphäre müheloser stärkt, als beim Abrufen von Webinhalten dem Protokollbezeichner HTTP ein kleines S zur Seite zu stellen.

Mit der Verwendung des Protokolls HTTPS ist nämlich sichergestellt, dass Daten abhörsicher1 zwischen dem Webserver und dem Endgerät des Nutzers übertragen werden.

Was für den Verbraucher so einfach funktioniert, bedeutete für den Inhalteanbieter jedoch bislang einen gewissen Aufwand und/oder war mit Kosten verbunden.
HTTPS basiert auf SSL bzw. TLS und ist damit den asymmetrischen Kryptosystemen zuzuordnen. Damit eine Webseite also via HTTPS erreichbar ist, muss ein kryptographisches Schlüsselpaar – im Idealfall von dessen Urheber – generiert und auf dem betreffenden Webserver konfiguriert bzw. hinterlegt werden.

Passkontrolle

Das Erzeugen und Hinterlegen von kryptographischen Schlüsseln ist uneingeschränkt jeder Person oder Maschine mit entsprechenden Kenntnissen bzw. Anweisungen, Berechtigungen und Werkzeugen möglichen. Um diesem Problem, also die Frage nach Authentizität und Integrität des öffentlichen Schlüssels, zu begegnen, wurde das Konzept der CA s entwickelt. Bestimmte zentrale Stellen sollen durch eine digitale Signierung des öffentlichen Schlüssels mit Hilfe ihrer Root-Zertifikate durchführen. Diese Dienstleistungen erbringen CAs in der Regel auf Nachweis der Identität des Schlüsselinhabers und gegen Geld. Die öffentlichen Schlüssel der CAs wiederum werden als Bestandteil der meisten Webbrowser von den Herstellern verwaltet und mit ausgeliefert.

Webseiten, deren öffentlicher Schlüssel für eine HTTPS Verbindung nicht von einer offiziellen CA signiert wurde, rufen normalerweise im Browser des Besuchers eine Warnmeldung hervor. Dies bedeutet nicht, dass die Verbindung weniger gut verschlüsselt ist, jedoch ist die Authentizität und Integrität des Schlüssels nicht bestätigt. Auf den durchschnittlichen Facetuber wirkt ein solcher Warnhinweis oft abschreckend und stört die User Experience.

Über die Effektivität und die daraus folgende Frage nach der Sinnhaftigkeit von CAs kann und sollte an anderer Stelle diskutiert werden.

Game changer

Grundsätzlich sollte es jedem Datenanbieter und jedem Datenkonsumenten daran gelegen sein, möglichst viel der verursachten Datenströme im WWW gegen einfaches Mitlesen zu schützen. Es soll Akteure abseits der genannten Interessengruppen geben, die da anderer Ansicht sind. Diese möchte ich an dieser Stelle jedoch bewusst vernachlässigen.

Das Projekt Let’s Encrypt der ISRG hat sich eine möglichst starke Verbreitung von HTTPS zum Ziel gesetzt. Zum einen wollen die Beteiligten das Erstellen von kryptographischen Schlüsseln und das entsprechende Konfigurieren der Webservers vereinfachen. Zum anderen soll Let’s Encrypt auch als offiziell anerkannte CA fungieren und die generierten öffentlichen Schlüssel signieren. Die dafür notwendigen Werkzeuge sollen open source sein und der gesamte Prozess von der Entwicklung der Software bis hin zur Signierung der Schlüssel transparent gestaltet und auditiert werden.

Los geht’s

Seit Oktober 2015 ist Let’s Encrypt eine offizielle CA und durch die Signierung des eigenen Root-Zertifikats (sog. Cross-Sign) durch die bereits anerkannte CA IdenTrust SSL als »vertrauenswürdig« eingestuft.
IdenTrust SSL ist den Browsern bereits bekannt, so dass alle von Let’s Encrypt signierten Schlüssel auch akzeptiert werden.
Darauf hin wurden die ersten Schlüssel mit den auf GitHub hinterlegten Tools für ausgewählte Webseiten generiert und signiert23. Seit 03.12.2015 läuft nun die öffentliche Beta-Phase. Das für Dezember 2015 angekündigte Ergebnis eines unabhängigen Audits steht allerdings noch aus4.

Einschränkungen

Bislang lassen sich keine Wildcard-Zertifikate erstellen. Jede Subdomain muss daher noch explizit im Zertifikat unter Subject Alternative Names vermerkt werden.
Das Zertifikat ist zur Zeit 90 Tage lang gültig. Angedacht ist hier eine Reduzierung der Gültigkeit auf 30 Tage. Eine Erneuerung mit Hilfe der in Python geschriebenen Tools ist jedoch ohne Weiteres und unkompliziert möglich. Durch die geringe Gültigkeit verspricht man sich einen einfacheren Umgang mit unberechtigt erstellten und signierten Zertifikaten.
Damit der gesamte Prozess möglichst automatisiert ablaufen kann, hat sich Let’s Encrypt ein Protokoll namens ACME ausgedacht. Dieses liegt der IETF bereits als Internet Draft vor.5

In eigener Sache

Da mein Webhoster Uberspace die Anforderungen von Let’s Encrypt bereits erfüllt, habe ich für diese Seite bereits Schlüssel und Zertifikat erstellt und eingebunden. Auch alle Assets werden nun via HTTPS ausgeliefert.

Ohne in den Erstellungsprozess eingegriffen zu haben, bringt die Konfiguration des Webservers im SSL Server Test6 von QUALYS SSL LABS das zweitbeste Ergebnis A.
Hauptsächlich die auf Seiten des Browsers erforderliche Unterstützung von SNI wird bemängelt. Die Shared Hosting Umgebung meiner Webseite macht diese TLS Erweiterung jedoch erforderlich.
Außerdem erreicht das Ergebnis in Sachen Schlüssellänge nicht die volle Punktzahl.

Die Handhabung des Tools ist, auch dank der Vorkonfiguration des Webhosters, erstaunlich einfach und die gesamte Umstellung hat nur wenige Minuten Zeit in Anspruch genommen. Doch wie immer gilt: Automatisierung und mehr verschlüsselter Datenverkehr ist gut, Kontrolle und Verstehen ist besser.

tl;dr

Mehr Verschlüsselung ist mehr gut. Das gilt vor allem für Datenströme die, wie es häufig im WWW der Fall ist, öffentlich einsehbar sind. Um als Webseitenbetreiber dem Nutzer eine gesicherte Verbindung mittels HTTPS anbieten zu können, musste bisher Zeit und Geld investiert werden.

Let’s Encrypt bringt seit 2015 Bewegung in das Verschlüsselungs-Spiel, in dem das Projekt zum Einen ein einfach zu bedienendes Tool zur Erzeugung der notwendigen kryptographischen Schlüssel und das Konfigurieren des Webservers bereit stellt. Und zum Anderen, in der Rolle als autorisierte CA, die Vertrauenswürdigkeit des öffentlichen Schlüssels bekräftigt.

Eine kleine Webseite, wie diese es ist, lässt sich so in wenigen Minuten für den verschlüsselten Aufruf vorbereiten.