Let's Encrypt: Erste Erfahrungen mit dem HTTPS für jedermann

Ferdinand Thommes
146 Kommentare
Let's Encrypt: Erste Erfahrungen mit dem HTTPS für jedermann
Bild: Let's Encrypt

Einleitung

Das Projekt Let's Encrypt hat sich auf die Fahnen geschrieben, HTTPS bei der Auslieferung von Webinhalten zum Standard zu machen. HTTPS stellt die Vertraulichkeit und Integrität der übertragenen Daten sicher, indem es den Webserver authentifiziert und die zwischen Browser und Webserver übertragenen Daten verschlüsselt. Auch wenn es einem Man-in-the-Middle gelingt, die übertragenen Daten abzuhören, kann er sie dann weder entziffern noch ändern.

HTTPS ist bereits über 20 Jahre alt. Es wurde ursprünglich bei Netscape entwickelt und 1994 veröffentlicht. Im Gegensatz zu HTTP erfolgt die Datenübertragung nicht über Port 80, sondern über den eigens für HTTPS reservierten Port 443. HTTPS greift auf das Verschlüsselungsprotokoll SSL/TLS zurück, das beispielsweise auch von SMTP für den verschlüsselten E-Mail-Versand genutzt wird.

Bei SSL/TLS wird zunächst unter Verwendung der asymmetrischen Verschlüsselung ein Schlüssel ausgetauscht, der fortan zum symmetrischen Verschlüsseln der Nutzdaten verwendet wird. Die symmetrische Verschlüsselung ist deutlich effizienter als die asymmetrische Verschlüsselung.

HTTPS ist ohne Autorisierung nutzlos

Ein SSL-Zertifikat zum Anbieten von HTTPS auf einer bestimmten Domain kann grundsätzlich jeder erzeugen. Damit es aber von den Browsern akzeptiert wird, muss es von einer bekannten Zertifizierungsstelle (Certificate Authority, CA) signiert sein, die vom jeweiligen Browser bzw. dessen Betriebssystem als vertrauenswürdig eingestuft ist. Beim Signieren eines Zertifikats besteht eine zentrale Aufgabe der CA darin, sicherzustellen, dass es sich bei dem Antragsteller um den legitimen Inhaber der im Zertifikat genannten Domain(s) handelt.

Let's Encrypt ist eine solche CA, die Zertifikate obendrein kostenlos ausstellt und eine vollständige Automatisierbarkeit erreichen möchte.

HTTPS wird bisher kaum genutzt

Da es HTTPS seit über 20 Jahren gibt, verwundert die Tatsache, dass es nicht weiter verbreitet ist, obwohl HTTP offen wie eine Postkarte ist. Laut HTTP Archive liegt die Zahl der Seiten, die per HTTPS aufgerufen werden, bei nur 23 Prozent. Dafür sind mehrere Faktoren verantwortlich.

Zum Einen spielt Unwissen und Gleichgültigkeit eine Rolle. Zum Anderen sind die Kosten für ein Zertifikat nicht in jedem Fall rentabel für Privatanwender: Ein einfaches Zertifikat, das eine einzige Domain absichert, kostet ab rund 5 Euro pro Jahr – mit viel Luft nach oben, falls mehrere Domains abgesichert werden sollen. Kostenlose Zertifikate sind zwar vereinzelt verfügbar, aber selbst dann verbleibt die technische Hürde, das Zertifikat korrekt in die Struktur des Webservers einzubinden.

Warnung bei selbst signiertem Zertifikat
Warnung bei selbst signiertem Zertifikat

Einige Serverbetreiber greifen auch zu selbstsignierten Zertifikaten, die nicht von einer bekannten CA signiert wurden. Entsprechend zeigen die gängigen Browser beim Aufrufen solcher Seiten Warnhinweise an. Zwar ist die Verbindung verschlüsselt, aber mangels Authentifizierung ist unklar, mit wem man die (verschlüsselten) Daten austauscht. Der Browser-Nutzer kann dann eine Ausnahmeregel erstellen, was aber nur Sinn macht, wenn er nicht nur dem Seitenbetreiber vertraut, sondern sich darüber hinaus sicher ist, gerade nicht Opfer eines Man-in-the-Middle-Angriffs zu sein.

Auch externe Inhalte können HTTPS verhindern

Auch technische Aspekte sprechen dagegen, sie betreffen konkret auch ComputerBase: So lange einzelne Inhalte der Webseite von externer Quelle, die kein HTTPS bietet, geladen werden, würden Browser eine Warnung aussprechen, auch wenn HTTPS von ComputerBase selbst geboten wird. Für im Forum eingebundene externe Inhalte hat ComputerBase mittlerweile eine technische Lösung implementiert, für die Anzeigen steht das noch aus. Deshalb gibt es HTTPS bisher nur für Abonennten von ComputerBase Pro.