HTTP-Sicherheit einfach gemacht

Vielleicht dem einen oder anderen bekannt, Let’s Encrypt ist eine Organisation, die es einfach und günstig (eigentlich sogar kostenlos) macht, HTTPS-Zertifikate für Webserver zu erhalten. Doch der Reihe nach und wozu das alles?

Dass sensible Daten wie Usernamen, Passwörter oder andere persönliche Informationen geheim und verschlüsselt über das Internet kommuniziert werden sollten, bedarf eigentlich keiner weiteren Diskussion. Aber selbst für wenig sensible Daten, die man sich beispielsweise beim Surfen im Internet ansieht, ist eine Verschlüsselung des Internetverkehrs durchaus sinnvoll. Denn Cybergauner können durch die Beobachtung von unverschlüsseltem Internetverkehr viel über den Nutzer erfahren. Und warum sollte man es den Gangstern leicht machen und die Chance geben, beispielsweise einen Download mit einem gefälschten Nachrichtendokument auszutauschen oder Malware über eine vermeintlich harmlose App einzuschleusen?

HTTPS ist eine der besten Sicherheitsmaßnahmen. Und es sollte ein durchgängiger Standard für alle Websitzungen sein, auch für die Sitzungen, die man für belanglos hält – ähnlich dem Sicherheitsgurt, den man grundsätzlich zu Beginn einer Fahrt anlegt und nicht erst dann, wenn man glaubt, dass die Straßenbedingungen am gefährlichsten sind.

Kleiner Ausflug ins Prinzip und die Historie von HTTPS

HTTPS, die Abkürzung für sicheres HTTP, basiert auf dem Verschlüsselungsprotokoll Transport Layer Security, kurz TLS. TLS verschlüsselt und schützt die Daten, die während einer Netzwerksitzung hin- und hergeschickt werden, so dass diese während der Übertragung nicht einfach ausgespäht und nicht heimlich verändert werden können.

Aufgrund dieser Funktionen, die sowohl die Vertraulichkeit des Surfens als auch die Integrität der heruntergeladenen Daten schützen, sind sich die meisten Sicherheitsexperten heutzutage einig, dass HTTPS bei der Nutzung des Internets von entscheidender Bedeutung ist.

Allerdings war HTTPS vor nicht allzu langer Zeit noch eine eher „lästige“ Angelegenheit. Vor etwa einem Jahrzehnt war HTTPS noch kaum verbreitet und dafür gab es zwei Gründe:

Erstens waren TLS-Zertifikate umständlich zu erwerben und zu verwenden und sie kosteten Geld. Kleinere Organisationen und Unternehmen oder Internet-Hobbyisten ärgerten sich darüber, dass sie eine „Websteuer“ zahlen sollten, zumal die Zertifikate regelmäßig erneuert werden mussten.

Zweitens galten TLS-Netzwerkverbindungen als langsamer im Vergleich zu unverschlüsselten Verbindungen. Viele Website-Betreiber mit hohem Datenverkehr scheuten sich vor HTTPS, weil der „kryptografische Tanz“, den das Protokoll jedes Mal erfordert, wenn ein Besucher auf die Website zugreift, zusätzliche Zeit in Anspruch nimmt und weil jedes Byte, das danach gesendet und empfangen wird, ver- und entschlüsselt werden muss.

Insgesamt sah man die Notwendigkeit für HTTPS bis etwa 2010 deutlich laxer als heute. Selbst Mainstream-Websites wie soziale Medien, Webmail und Online-Shopping setzten TLS nur in so genannten „kritischen Momenten“ ein – etwa bei Passwortabfragen oder dem Einsatz von Kreditkartendaten. Der größte Teil des Surfens erfolgte ohne HTTPS, da ein schnelles Surferlebnis als viel wichtiger angesehen wurde als ein sicheres.

Die Kehrtwende

Im Jahr 2010 jedoch änderte sich die kollektiv nachlässige Einstellung plötzlich, was nicht zuletzt auf ein Firefox-Plugin namens Firesheep zurückzuführen war. Mit Firesheep konnte sich jeder, der Lust dazu hatte, als Netzwerkhacker versuchen, beispielsweise in öffentlich zugänglichen Internet-Zugängen im Cafe. Mit Firesheep war es möglich, Datenströme zu beobachten, die zwischen den Nutzern, die sich beispielsweise vermeintlich „sicher“ bei einer Website wie Facebook oder Twitter angemeldet hatten, im Netzwerk hin- und hergehen. Diese unverschlüsselten Netzwerkpakete verrieten zwar nicht das Passwort des Benutzers, aber sie enthüllten das aktuelle Authentifizierungs-Token oder den geheimen Sitzungs-Cookie, der zu jeder Anfrage hinzugefügt wurde, um zu beweisen, dass der Benutzer bereits angemeldet war. Firesheep schürfte diese Authentifizierungs-Token automatisch und fügte sie in den gefälschten Facebook- und Twitter-Datenverkehr ein, um die Konten anderer Personen zu kompromittieren. Dies und einige weitere Gründe führten sehr schnell zu immer lauteren Rufen nach HTTPS und so wurde es zunehmend mehr eingesetzt.

Kosten im Namen der Sicherheit

Die ersten, die HTTPS für den gesamten Datenverkehr auf Internetseiten einsetzten, bemerkten sehr schnell, dass der durch TLS verursachte Rechenaufwand auf moderner Computer-Hardware weit weniger dramatisch ist, als viele befürchtet hatten.

Allerdings war das Kostenproblem für die Zertifikate zu diesem Zeitpunkt noch nicht gelöst, zum besonderen Leidwesen von kleinen Unternehmen und Internet-Enthusiasten. Jedes Serverzertifikat konnte 100 Dollar pro Jahr kosten, und man musste sicherstellen, die Zertifikate rechtzeitig – will heißen jährlich – zu erneuern. Denn nach Ablauf der Frist erhielten die Webseitenbesucher jedes Mal eine wenig vertrauenserweckende Meldung wie etwa „Unvertrauenswürdige Website – Zertifikat ist abgelaufen“.

Zwar ist die Erstellung eines eigenen und damit kostenlosen TLS-Zertifikats nicht schwierig und es dauert auch nur wenige Sekunden. Das Problem ist allerdings, dass ein selbstsignierter Schlüssel nicht viel bringt, wenn man diesen mit einem öffentlichen Webserver betreiben will. Damit das Zertifikat wirklich funktioniert, hätte man eine Organisation, die als Zertifizierungsstelle (CA) anerkannt ist, bitten müssen, eine Prüfung durchzuführen, dass man tatsächlich der Webseitenbetreiber ist. Erst dann wird das Zertifikat signiert und dafür gebürgt. Zudem hätte man eine Zertifizierungsstelle wählen müssen, der die überwiegende Mehrheit der Browser bereits vertraut, so dass ein neu signiertes Zertifikat automatisch für die überwiegende Mehrheit der Nutzer ungehindert funktionieren würde. Und genau dies war die Grundlage für den Markt der bezahlpflichtigen Zertifikate.

Der Ruck in die sichere Freiheit

Der Zustand mit den Zertifikaten sollte sich ab dem Jahr 2014 allerdings rasch ändern. In diesem Jahr gegründete sich die gemeinnützige Organisation Let’s Encrypt. Diese wollte die HTTPS-Landschaft ändern, indem sie als Zertifizierungsstelle TLS-Zertifikate kostenlos anbot und indem sie den Prozess des Erwerbs und der Erneuerung automatisierte und damit stark vereinfachte. Zwar war Let’s Encrypt war nicht das erste Projekt dieser Art, allerdings eines der erfolgreichsten.

Natürlich geschah dies nicht über Nacht. Denn das noch neue Let’s Encrypt-Zertifikat konnte nicht einfach als CA für sich selbst fungieren. Ergo war es schwierig, das Interesse und die Akzeptanz zu gewinnen. Hilfestellung gab es von Digital Signature Trust Co., auch bekannt als IdenTrust. Dieses Unternehmen hat Let’s Encrypt enorme Starthilfe gegeben, indem es seit 2015 als CA für Newcomer agierte.

Heute vertrauen die meisten Browser und Betriebssysteme dem Zertifikat.

Warum ist das wichtig? Ganz einfach, weil wir der Meinung sind, dass diese Geschichte ein gutes Beispiel dafür ist, weshalb Kryptographie und kryptographischer Fortschritt oft so langsam sind und manchmal Jahre brauchen, um durch einen Konsens vieler Beteiligter etwas sehr sinnvolles und vor allem vertrauensvolles zu erreichen.

Daher, Glückwunsch an Let’s Encrypt für das Festhalten an einem Plan, HTTPS auch für die kleinste Website einfach und kostengünstig zu nutzen, und Dank an IdenTrust für die Unterstützung von Let’s Encrypt in den Anfangstagen.

Achja, und zum Schluss noch ein Wort an diejenigen, die immer noch behaupten, dass HTTPS ein unnötiges Übel ist, das Cyberkriminellen in die Hände spielt, weil auch sie jetzt problemlos HTTPS-Zertifikate erhalten können. Diese sollten bedenken, dass Gauner, die HTTPS nutzen wollten, dies schon lange vor dem Aufkommen von Let’s Encrypt tun konnten. Zwar mussten die Cybergangster ebenfalls die 99 Dollar für ein TLS-Zertifikat bezahlen – das taten sie aber sicher nicht mit der eigenen Kreditkarte … sondern mit Kreditkartendaten, die sie von Webseiten abgezogen haben, die eben nicht mit HTTPS geschützt waren.

Ein Kommentar von Michael Veit, Security-Evangelist bei Sophos, www.sophos.com/de-de