Der aktuelle Stand der Websicherheit (Ein Interview mit Anselm Hannemann)

Anselm Hannemann hat kürzlich einen Beitrag über einige der Missverständnisse veröffentlicht, die Frontend-Entwickler über Websicherheit haben könnten. Da ich viele Fragen zu diesen Themen hatte, dachte ich, ich interviewe Anselm, um seine Meinung zur überraschenden Komplexität der Einrichtung von HTTPS zu erfahren. Wir sprechen über Dinge wie das Generieren von Zertifikaten und wie wir die widersprüchlichen Meinungen vieler Entwickler, einschließlich meiner selbst, zu Drittanbieterdiensten wie Cloudflare am besten verstehen können.

Für diejenigen, die mit Websicherheit nicht vertraut sind, könnten Sie bitte die Unterschiede zwischen HTTP und HTTPS erläutern?

Sicher! Der allgemeine Unterschied zwischen HTTP und HTTPS ist einfach: HTTP oder Hypertext Transfer Protocol ist das Standardprotokoll, das wir zum Bereitstellen von Websites und zum Übertragen von Daten verwenden. Diese Informationen werden jedoch ungeschützt und unverschlüsselt gesendet. HTTPS hingegen kombiniert HTTP und TLS (ein kryptografisches Protokoll), um Daten, die über ein Netzwerk gesendet werden, durch Verschlüsselung zu schützen.

Sie fragen sich vielleicht, warum Sie die Verbindung zu Ihrer Website verschlüsseln müssen, wenn die Inhalte ohnehin öffentlich sind. Nehmen wir an, Sie verwenden ein CMS wie WordPress oder Craft für Ihre Website. Wenn Sie sich über HTTP in Ihr Backend einloggen, werden Ihre Anmeldedaten im Klartext an den Server gesendet. Jeder, der Ihre WLAN- oder Internetverbindung abfängt, hat nun Zugriff auf Ihr CMS (das ist wirklich super einfach – denken Sie nur an öffentliche WLANs in Cafés). Aber nicht nur das, HTTPS kann Sie auch davor schützen, falsche Inhalte zu erhalten. Wenn HTTPS richtig eingerichtet ist, können Hacker die DNS-Auflösung nicht mehr überwinden, um unterschiedliche Inhalte für Ihre Domain bereitzustellen. Mit HTTPS ist es auch nicht möglich, dass Software auf Ihrem Computer Anzeigen oder Malware in Webseiten einfügt.

Sie können sich HTTPS als die sicherere Version von HTTP vorstellen, die Sie vor Datenlecks an die Öffentlichkeit schützt und auch davor bewahrt, auf Phishing hereinzufallen.

Warum benötigen wir SSL-Zertifikate, damit der Browser weiß, dass die Verbindung sicher ist?

Erstens, obwohl viele Leute immer noch von „SSL“ sprechen, verwenden wir heute „TLS“ als Verschlüsselungsmethode, wenn wir Informationen über HTTPS senden. „SSL“ ist eine alte Methode, die nicht mehr verwendet werden sollte. HTTPS im Allgemeinen funktioniert mit Zertifikaten, die Sie von Ihrem Hosting-Unternehmen erhalten können, um einen sicheren, verschlüsselten Kanal im HTTP-Protokoll zur Datenübertragung zu erstellen. Um die Daten zu verschlüsseln, benötigen Sie einen privaten und einen öffentlichen Schlüssel.

Damit dies funktioniert, benötigen Sie auf Ihrem Server ein sogenanntes „X.509“-Zertifikat, das die Informationen über die Authentizität der Website enthält und von einer Stammzertifizierungsstelle (Let’s Encrypt, StartSSL oder ähnliche) genehmigt wurde.

Alle Browser haben dagegen eine Reihe bekannter und vertrauenswürdiger Stammzertifizierungsstellen integriert. Dies geschieht für eine bequemere Benutzererfahrung – der Benutzer muss das Zertifikat nicht überprüfen und genehmigen, um die Verbindung zur Website herzustellen. Irgendwann haben Sie wahrscheinlich eine Popup-Meldung des Browsers gesehen, die Sie fragt, ob Sie der Websiteverbindung vertrauen möchten, da sie eine unbekannte Identität verwendet. Dies geschieht, wenn das Zertifikat nicht von einer offiziellen, vertrauenswürdigen Stelle erstellt wurde. Natürlich gibt es hier viele komplexe Punkte, die ich vereinfache, also stellen Sie sicher, dass Sie detailliertere Ressourcen lesen, wenn Sie mehr Informationen zu einer bestimmten Funktion oder Technologie wünschen (einige davon verlinken wir am Ende dieses Artikels).

Ein Browser benötigt diese Zertifikate, um zu überprüfen, ob die Schlüssel übereinstimmen. Dies stellt sicher, dass weder der Server, der Client noch irgendetwas dazwischen Ihre wertvollen Daten abgefangen und (versehentlich oder anderweitig) preisgegeben hat. Das klingt ziemlich sicher, aber es gibt ein paar Probleme im Detail, die Angreifer immer noch zulassen könnten, die Verbindung zwischen Client und Server abzufangen. HTTPS ist keine magische Lösung, aber es macht den Zugriff auf Ihre Informationen erheblich schwieriger.

Wie in Ihrem Artikel steht, ging ich auch naiv davon aus, dass ich nur meine Website in meiner Serverkonfigurationsdatei auf https umleiten und Cloudflare dann anweisen müsste, auf HTTPS umzuschalten. Können Sie erklären, warum das nicht der Fall ist?

Das ist nicht ganz falsch. Bei einem Dienst wie Cloudflare sind die Dinge etwas komplexer. Sie bieten eine Reihe von Diensten an, zum Beispiel: DNS-Hosting, Leistungsoptimierung und Sicherheitsverbesserungen. Aber viele Leute melden sich bei Cloudflare an, weil sie „kostenloses SSL“ anbieten. Das ist tatsächlich eine großartige Funktion, die absolut Sinn ergibt, da Sie alle Ihre Inhalte über HTTPS bereitstellen möchten, sodass Ihr CDN auch HTTPS unterstützen sollte.

Leider, und das verstehen die meisten Leute nicht, können sie dies nur für ihren Teil der Verbindung tun. Das bedeutet, dass sie HTTPS auf ihren Servern verwenden und Inhalte von dort an den Client ausliefern. Wenn Ihre Website (der sogenannte Origin-Host) kein HTTPS unterstützt, bedeutet dies, dass die Daten zwischen Ihrem Ursprung und Cloudflare völlig ungeschützt sind. Schlimmer noch, dies erweckt beim Benutzer den Eindruck, dass die Website und die eingegebenen Daten verschlüsselt und geschützt sind, obwohl dies tatsächlich nicht der Fall ist. Cloudflare kann keine Einstellungen auf Ihrem Server ändern, daher können sie nur ihren Teil tun, um die Dinge sicherer zu machen. Sie müssen immer noch sicherstellen, dass Sie die Daten auf Ihrem Ursprungsserver sichern. Das ist es, was die meisten Leute nicht verstehen.

Wenn Sie das erste richtig gemacht haben – HTTPS auf Ihrem Ursprungsserver aktiviert haben – dann ist die Situation etwas besser. In diesem Fall können Sie Cloudflare anweisen, sich nur über HTTPS mit Ihrem Ursprung zu verbinden und Inhalte nur über HTTPS an den Client auszuliefern. Jetzt haben wir ein weiteres Problem: Cloudflare’s Full SSL validiert das Ursprungszertifikat nicht – es verwendet es einfach, daher kann es ungültig, selbstsigniert oder bösartig sein. Zumindest bedeutet dies, dass die Verbindung zwischen den Servern immer durch HTTPS gesichert ist. Es gibt etwas, das Cloudflare „Full SSL strict“ nennt, das das Zertifikat selbst validiert, aber es ist eher wie „Basic SSL“, da Sie nicht sicherstellen können, dass die Daten Ihres Kunden verschlüsselt und sicher sind.

Cloudflare (oder jeder andere Drittanbieterdienst) sitzt zwischen Browser und Server und optimiert (d. h. ändert) Inhalte für die Auslieferung oder um Angriffe auf Ihren Server zu verhindern. Das Problem ist, dass die Daten unverschlüsselt sind, solange sie sich bei Cloudflare befinden. HTTPS funktioniert für die Übertragung, ist aber keine End-to-End-Verschlüsselung der tatsächlich gesendeten Daten. Das bedeutet, dass alle Inhalte vorübergehend auf der Maschine des Drittanbieters unverschlüsselt sind. Selbst wenn Sie dem Unternehmen selbst mit Ihren (und den Daten Ihres Kunden) voll vertrauen, besteht das Problem darin, dass ein weiterer Dritter Zugang zu solchen Traffic-optimierenden Servern erhalten und Daten lesen oder modifizieren könnte, was dazu führt, dass entweder der Ursprung oder der Client modifizierte Inhalte erhält.

Wenn Sie können, sollten Sie zusätzlich HSTS oder HTTP Strict Transport Security aktivieren. Dies tun Sie, indem Sie eine Regel zu Ihrer Serverkonfiguration hinzufügen, die dieses Flag setzt. Wenn Sie dieses Flag setzen, verbindet sich ein Browser für den angegebenen Zeitraum nur über HTTPS mit der angegebenen Domain. Der Zeitraum sollte sehr lang eingestellt werden, Twitter setzt ihn zum Beispiel auf 20 Jahre, um zu verhindern, dass diese Regel im Falle eines Angriffs auf seine Server geändert wird. Sie können auch Subdomains in diese Regel aufnehmen.

Um schließlich zu verhindern, dass Ihre Website aufgrund einer kompromittierten Stammzertifizierungsstelle ausgenutzt wird, können Sie HPKP oder HTTP Public Key Pinning einrichten, das die letzte Sicherheitslücke für HTTPS schließt. Leider, wenn Sie hier etwas falsch machen, sind die Konsequenzen sehr schlimm und könnten bedeuten, dass Ihre Website für den von Ihnen festgelegten Zeitraum (der nicht zu kurz sein sollte) nicht mehr verfügbar ist. Mehr dazu und wie HPKP eingerichtet wird, können Sie in diesem großartigen Artikel von Scott Helme lesen.

Let’s Encrypt scheint ein großer Schritt in die richtige Richtung in Bezug auf die Generierung von Zertifikaten zu sein, aber dies erfordert immer noch Kenntnisse der Kommandozeile. Warum ist grundlegende Websicherheit so komplex? Warum gibt es keine einfacheren Lösungen für diese Probleme?

Oh ja, es ist großartig, endlich Fortschritte bei Let’s Encrypt zu sehen. HTTPS gibt es seit 1994 und daher bin ich ziemlich glücklich, dass endlich Leute daran arbeiten, den Prozess der Einrichtung von HTTPS zu vereinfachen. Ich sehe Let’s Encrypt nur als den Anfang.

Zu diesem speziellen Dienst. Er hat gerade den öffentlichen Beta-Status erreicht. Derzeit funktioniert er nur auf der CLI und ist stark eingeschränkt, wenn er ohne Root-Privilegien ausgeführt wird. Obwohl es also großartig ist zu sehen, dass die Dinge einfacher werden, gibt es noch zu viele Hürden zu überwinden.

Ich warte gespannt auf den Zeitpunkt, an dem alle Hosting-Unternehmen HTTPS kostenlos mit einer super einfachen und automatisierten Einrichtung für jede beliebige Domain anbieten. Denn ehrlich gesagt ist die Einrichtung von HTTPS heute viel zu komplex, selbst für technisch versierte Personen.

Wer sollte Ihrer Meinung nach für die Websicherheit verantwortlich sein? Sollten sich Frontend-Entwickler mehr Zeit mit dem Erlernen dieser Dinge nehmen? Oder ist es die Aufgabe von Hosting-Unternehmen, eine elegantere technische Lösung für das Problem zu finden – wie z. B. überhaupt keinen HTTP-Zugang anzubieten?

Das ist eine komplexe Frage, die nicht so einfach zu beantworten ist. Im Idealfall wäre die ordnungsgemäße Einrichtung von HTTPS für eine Domain so einfach wie ein Klick in der Benutzeroberfläche eines Webhosters oder ein einzelner Befehl auf einem Server für einen Serveradministrator. Es ist noch ein langer Weg, bis wir diesen Punkt erreichen. Bis dahin müssen wir Entwickler uns darum kümmern.

Als Full-Stack- oder Backend-Entwickler sollten Sie sich um die Einrichtung des Zertifikats auf dem Server kümmern. Als Frontend- oder Full-Stack-Entwickler sollten Sie HSTS aktivieren und HTTPS standardmäßig erzwingen, sich um eine ordnungsgemäße Content Security Policy und andere Sicherheitsmaßnahmen kümmern. Jeder Entwickler, unabhängig von seinem Titel, hat die Pflicht, sicherzustellen, dass das entwickelte Projekt eine sichere und verschlüsselte Umgebung für seine Benutzer schafft.

Was das Nicht-Anbieten von HTTP überhaupt mehr betrifft – lassen Sie uns darüber sprechen, wenn wir die noch verbleibenden Probleme gelöst haben, die oben beschrieben wurden. Bis dahin glaube ich nicht, dass wir generell darauf abzielen sollten, HTTP zu „veraltet“ zu erklären, insbesondere da wir weltweit noch viel Altes in Bezug auf Hardware, Cipher-Unterstützung und Software haben, das für eine reine HTTPS-Welt verschwinden müsste.

Welche Ressourcen würden Sie empfehlen, damit ich mehr über Websicherheit erfahren kann?

Glücklicherweise sind diese Themen gut mit vielen hilfreichen Blogbeiträgen abgedeckt. Im Allgemeinen sollten Sie die von Scott Helme verfassten Artikel lesen, um sich mit den Details spezifischer Sicherheitsfunktionen und deren Aktivierung auf Ihrer Website vertraut zu machen. Er hat auch securityheaders.io erstellt, ein Tool, das Ihre Website auf Sicherheit prüft und Verbesserungsvorschläge macht.

Wenn Sie Let’s Encrypt für Ihr HTTPS verwenden möchten, ist der Einleitungsbeitrag von Tim Kadlec eine gute Idee, ebenso wie sein Beitrag darüber, wie HSTS damit aktiviert wird.

Schließlich, wenn Sie mehr wissen möchten, schauen Sie sich diese Liste von Sicherheitslinks von Troy Hunt an. Und wenn Sie einen Überblick über die grundlegenden Technologien erhalten möchten, finden Sie gute Erklärungen auch auf Wikipedia.

Danke Anselm!