Einige Erfahrungen zum Aktivieren von HTTPS

Da sich die heimische Netzwerkumgebung immer weiter verschlechtert, kommt es immer häufiger zu Manipulationen und Datendiebstählen, und immer mehr Websites entscheiden sich dafür, HTTPS für die gesamte Site zu verwenden. Heute bietet Let’s Encrypt kostenlose Zertifikatsdienste an.   Das Projekt ist auch offiziell eröffnet und HTTPS wird bald ein Muss für das WEB sein. HTTPS bietet drei Hauptfunktionen: Inhaltsverschlüsselung, Identitätsauthentifizierung und Datenintegrität durch die TLS-Schicht und den Zertifikatmechanismus. Es kann effektiv verhindern, dass Daten angezeigt oder manipuliert werden, und verhindert, dass sich Mittelsmänner als Betrüger ausgeben. In diesem Artikel werden einige Erfahrungen mit der Aktivierung von HTTPS dargelegt, wobei der Schwerpunkt auf der Verwendung mit einigen neuen Sicherheitsspezifikationen liegt. Über die Bereitstellung und Optimierung von HTTPS habe ich bereits viel geschrieben, deshalb werde ich es in diesem Artikel nicht wiederholen.

Gemischten Inhalt verstehen

In HTTPS-Webseiten geladene HTTP-Ressourcen werden als gemischte Inhalte bezeichnet. Verschiedene Browser haben unterschiedliche Verarbeitungsregeln für gemischte Inhalte.

Früherer Internet Explorer

Wenn frühere Versionen des Internet Explorers eine Anfrage für gemischte Inhalte fanden, wurde ein modales Dialogfeld mit der Frage angezeigt: „Möchten Sie nur sicher übertragene Webseiteninhalte anzeigen?“ Wenn der Benutzer „Ja“ auswählte, wurden alle Ressourcen für gemischte Inhalte nicht geladen. Wenn er „Nein“ auswählte, wurden alle Ressourcen geladen.

Neuerer IE

Neuere Internet Explorer-Versionen ändern das modale Dialogfeld in einen Tooltip am unteren Seitenrand, der für Benutzer weniger aufdringlich ist als zuvor. Darüber hinaus werden gemischte Inhalte vom Typ „Bild“ standardmäßig geladen und andere Ressourcen wie JavaScript, CSS usw. werden weiterhin basierend auf der Benutzerauswahl geladen.

Moderne Browser

Moderne Browser (Chrome, Firefox, Safari, Microsoft Edge) entsprechen grundsätzlich den W3C-   Gemischter Inhalt   Standardisiert gemischte Inhalte in   Optional blockierbar   und blockierbar   Zwei Kategorien:

Optional blockierbar   Die Klasse „Gemischter Inhalt“ enthält Ressourcen, die weniger gefährlich sind und von einem Mittelsmann manipuliert werden können. Moderne Browser laden solche Ressourcen standardmäßig und geben eine Warnmeldung in der Konsole aus. Zu diesen Ressourcen gehören:

• passieren   <Bild>   Vom Tag geladene Bilder (einschließlich SVG-Bilder);
• passieren   <Video>   /   <Audio>   Und   <Quelle>   Das vom Tag geladene Video oder Audio;
• Vorab abgerufene Ressourcen;

Darüber hinaus sind alle Mixed Content   Blockierbar, der Browser muss das Laden solcher Ressourcen verbieten. Daher werden in modernen Browsern HTTP-Ressourcen wie JavaScript und CSS in HTTPS-Seiten überhaupt nicht geladen und Fehlerinformationen werden direkt in der Konsole ausgegeben.

Mobiler Browser

Das bisher Gesagte betrifft alles Verhaltensweisen von Desktop-Browsern. Auf mobilen Endgeräten ist die Situation komplizierter. Derzeit erlauben die meisten mobilen Browser standardmäßig das Laden von gemischten Inhalten. Das bedeutet, dass für mobile Browser HTTP-Ressourcen in HTTPS standardmäßig geladen werden, egal ob es sich um Bilder oder JavaScript und CSS handelt.

Wenn Sie HTTPS für die gesamte Site wählen, müssen Sie gemischte Inhalte grundsätzlich vermeiden. Alle Ressourcenanforderungen auf der Seite müssen das HTTPS-Protokoll verwenden, um sicherzustellen, dass auf allen Plattformen und allen Browsern keine Probleme auftreten.

Sinnvoller Einsatz von CSP

CSP, der vollständige Name lautet Content Security Policy, enthält zahlreiche Anweisungen, die zur Implementierung verschiedener Funktionen im Zusammenhang mit der Seiteninhaltssicherheit verwendet werden. Hier stellen wir nur zwei HTTPS-bezogene Anweisungen vor. Weitere Informationen finden Sie in meinem vorherigen Artikel „Einführung in die Content Security Policy Level 2“.

Blockiere alle gemischten Inhalte

Wie bereits erwähnt, für Bilder in HTTPS,   Optional blockierbar   HTTP-ähnliche Ressourcen, die moderne Browser standardmäßig laden. Das Entführen von Bildressourcen verursacht normalerweise nicht allzu viele Probleme, birgt jedoch einige Risiken. Beispielsweise werden viele Webseitenschaltflächen mit Bildern implementiert. Wenn der Mittelsmann diese Bilder ändert, beeinträchtigt dies auch die Benutzernutzung.

Durch CSP   Blockiere alle gemischten Inhalte   Anweisung, die es der Seite ermöglicht, in den strengen Modus zur Überprüfung gemischter Inhalte zu wechseln. In diesem Modus dürfen alle Nicht-HTTPS-Ressourcen nicht geladen werden. Wie alle anderen CSP-Regeln kann diese Direktive auf zwei Arten aktiviert werden:

HTTP-Antwortheadermethode:

Content-Security-Policy: block-all-mixed-content

<Meta>   Beschriftungsmethode:

< meta http-equiv = "Content-Security-Policy" content = "block-all-mixed-content" >

Upgrade-unsichere-Anfragen

Der Arbeitsaufwand großer Websites mit einer langen Migrationshistorie zu HTTPS ist oft sehr groß, insbesondere beim Schritt des Ersetzens aller Ressourcen durch HTTPS, bei dem leicht Auslassungen auftreten können. Auch wenn die Richtigkeit des gesamten Codes überprüft wird, besteht eine gute Chance, dass einige aus der Datenbank gelesene Felder HTTP-Links enthalten.

Und durch   Upgrade-unsichere-Anfragen   Mit dieser CSP-Anweisung kann der Browser bei dieser Konvertierung helfen. Nach der Aktivierung dieser Richtlinie gibt es zwei Änderungen:

• Alle HTTP-Ressourcen auf der Seite werden vor dem Senden von Anfragen durch HTTPS-Adressen ersetzt.
• Alle Links auf der Seite werden durch HTTPS-Adressen ersetzt und nach dem Anklicken umgeleitet;

Wie alle anderen CSP-Regeln kann diese Anweisung auf zwei Arten aktiviert werden. Das spezifische Format finden Sie im vorherigen Abschnitt. Es ist zu beachten, dass   Upgrade-unsichere-Anfragen   Es wird nur der Protokollteil ersetzt, daher ist es nur auf Szenarien anwendbar, in denen der HTTP/HTTPS-Domänenname und der Pfad genau identisch sind.

Richtiger Einsatz von HSTS

Nachdem die gesamte Website HTTPS ist, kann der Benutzer, wenn er die HTTP-Adresse der Website manuell eingibt oder von anderen Orten aus auf den HTTP-Link der Website klickt, den HTTPS-Dienst nur nutzen, indem er sich auf die 301/302-Weiterleitung des Servers verlässt. Die erste HTTP-Anfrage kann entführt werden, sodass die Anfrage den Server nicht erreichen kann. Somit handelt es sich um einen HTTPS-Downgrade-Hijack.

Grundlegende Verwendung von HSTS

Dieses Problem kann durch HSTS (HTTP Strict Transport Security, RFC6797) gelöst werden. HSTS ist ein Antwortheader mit folgendem Format:

Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]

„max-age“ (in Sekunden) wird verwendet, um dem Browser mitzuteilen, dass innerhalb einer angegebenen Zeit über das HTTPS-Protokoll auf diese Website zugegriffen werden muss. Das heißt, für die HTTP-Adresse dieser Website muss der Browser sie vor dem Senden der Anforderung lokal durch HTTPS ersetzen.

includeSubDomains, ein optionaler Parameter. Wenn dieser Parameter angegeben wird, bedeutet dies, dass alle Subdomains dieser Website auch über das HTTPS-Protokoll aufgerufen werden müssen.

Vorlast, ein optionaler Parameter, seine Funktion wird später vorgestellt.

Der HSTS-Antwortheader kann nur für HTTPS-Antworten verwendet werden; die Website muss den Standardport 443 verwenden; und es muss der Domänenname verwendet werden, nicht die IP. Darüber hinaus können Benutzer den Website-Zertifikatfehler nach der Aktivierung von HSTS nicht ignorieren.

HSTS-Vorladeliste

Es ist ersichtlich, dass HSTS den HTTPS-Downgrade-Angriff effektiv lösen kann, aber die erste HTTP-Anforderung, bevor HSTS wirksam wird, kann nicht verhindert werden, dass sie entführt wird. Um dieses Problem zu lösen, haben Browserhersteller die HSTS-Preload-List-Lösung vorgeschlagen: Es wird eine integrierte Liste erstellt und für die Domänennamen in der Liste wird das HTTPS-Protokoll verwendet, auch wenn der Benutzer sie zuvor nicht besucht hat; die Liste kann regelmäßig aktualisiert werden.

Derzeit wird diese Preload-Liste von Google Chrome verwaltet und von Chrome, Firefox, Safari, IE 11 und Microsoft Edge verwendet. Wenn Sie Ihren Domänennamen zu dieser Liste hinzufügen möchten, müssen Sie zunächst die folgenden Bedingungen erfüllen:

• Sie müssen über ein gültiges Zertifikat verfügen (bei Verwendung eines SHA-1-Zertifikats muss das Ablaufdatum vor 2016 liegen);
• Leiten Sie den gesamten HTTP-Verkehr auf HTTPS um.
• Stellen Sie sicher, dass HTTPS auf allen Subdomains aktiviert ist;
• Ausgabe-HSTS-Antwortheader:
  • Das Höchstalter darf nicht weniger als 18 Wochen (10886400 Sekunden) betragen.
  • Der Parameter „includeSubdomains“ muss angegeben werden;
  • Der Preload-Parameter muss angegeben werden;

Auch wenn alle oben genannten Bedingungen erfüllt sind, wird es möglicherweise nicht unbedingt in die HSTS-Preload-Liste aufgenommen. Weitere Informationen finden Sie hier. Über Chrome   chrome://net-internals/#hsts   Mit diesem Tool können Sie prüfen, ob sich eine Website in der Preload-Liste befindet. Sie können der lokalen Preload-Liste auch manuell einen Domänennamen hinzufügen.

Bezüglich HSTS und HSTS Preload List rate ich Ihnen, diese nicht zu aktivieren, es sei denn, Sie können sicherstellen, dass immer HTTPS-Dienste bereitgestellt werden. Denn sobald HSTS in Kraft tritt, werden die alten Benutzer unendlich oft umgeleitet, wenn Sie die Website auf HTTP umleiten möchten. Die einzige Möglichkeit besteht darin, den Domänennamen zu ändern.

CDN-Sicherheit

Bei großen Websites müssen Sie nach der Migration der gesamten Website auf HTTPS weiterhin ein CDN verwenden, aber Sie müssen ein CDN auswählen, das HTTPS unterstützt. Wenn Sie ein CDN eines Drittanbieters verwenden, müssen Sie einige Sicherheitsaspekte berücksichtigen.

Richtiger Einsatz von SRI

HTTPS kann verhindern, dass Daten während der Übertragung manipuliert werden, und ein gültiges Zertifikat kann auch die Identität des Servers bestätigen. Wenn der CDN-Server jedoch gehackt wird und statische Dateien auf dem Server manipuliert werden, ist HTTPS machtlos.

W3C   Zur Lösung dieses Problems kann die SRI-Spezifikation (Subresource Integrity) verwendet werden. SRI ermöglicht dem Browser, zu überprüfen, ob die Ressource manipuliert wurde, indem die Digest-Signatur der Ressource angegeben wird, wenn die Seite auf die Ressource verweist. Solange die Seite nicht manipuliert wird, ist die SRI-Richtlinie zuverlässig.

Weitere Informationen zu SRI finden Sie in meinem vorherigen Artikel „Einführung in die Subresource-Integrität“. SRI ist nicht spezifisch für HTTPS, aber wenn die Hauptseite gekapert wird, kann der Angreifer die Ressourcenübersicht leicht entfernen und so den SRI-Verifizierungsmechanismus des Browsers verlieren.

Grundlegendes zu Keyless SSL

Ein weiteres Problem besteht darin, dass Sie bei Verwendung des HTTPS-Dienstes eines CDN eines Drittanbieters, wenn Sie Ihren eigenen Domänennamen verwenden möchten, den entsprechenden privaten Zertifikatsschlüssel an den Drittanbieter weitergeben müssen, was ebenfalls sehr riskant ist.

CloudFlare hat für dieses Szenario die Keyless SSL-Technologie entwickelt. Anstatt den privaten Zertifikatsschlüssel an Dritte weiterzugeben, können Sie einen Schlüsselserver für Echtzeitberechnungen bereitstellen. Wenn CDN den privaten Schlüssel verwenden muss, überträgt es die erforderlichen Parameter über einen verschlüsselten Kanal an den Schlüsselserver. Der Schlüsselserver berechnet das Ergebnis und gibt es zurück. Während des gesamten Vorgangs wird der private Schlüssel auf einem eigenen Schlüsselserver gespeichert und keinem Dritten zugänglich gemacht.

Der Mechanismus von CloudFlare ist Open Source. Weitere Informationen finden Sie in diesem Artikel auf dem offiziellen Blog: Keyless SSL: Die wichtigsten technischen Details.

Nun, dieser Artikel endet hier. Es ist zu beachten, dass die in diesem Artikel erwähnten CSP-, HSTS- und SRI-Strategien nur von den neuesten Browsern unterstützt werden. Detaillierte Unterstützung finden Sie unter   Kann ich verwenden   überprüfen. Nach der Umstellung auf HTTPS gibt es bei der Leistungsoptimierung viel zu tun. Ich habe in meinem vorherigen Blog viel über diesen Teil geschrieben, deshalb werde ich es hier nicht wiederholen. Ich werde nur den wichtigsten Punkt erwähnen: Da es sich um HTTPS handelt, ist der richtige Weg, schnell auf HTTP/2 umzusteigen.

Originaltext: https://imququ.com/post/sth-about-switch-to-https.html