Warum benötigen wir HTTPS für statische Inhalte? Wenn wir am Ende eine vom privaten Schlüssel signierte Prüfsumme haben können, wird dies dann nicht die Gültigkeit beweisen?

Ich denke, Sie richten mit dieser Frage einen Strohmann ein. Wir brauchen kein HTTPS für statische Inhalte, und der Zweck von HTTPS besteht nicht nur darin, die Gültigkeit des Inhalts zu beweisen. Das ist nur einer von mehreren Zwecken. Der Schritt, eine große Anzahl von Websites auf HTTPS umzustellen (auch solche, die harmlose statische Inhalte wie Wikipedia bereitstellen), erfolgte in den letzten Jahren nicht in erster Linie, weil die Leute besorgt waren, die falschen Inhalte zu erhalten. Das liegt daran, dass die Leute sich Sorgen machten, dass Drei-Buchstaben-Agenturen Benutzer ausspionieren könnten. z.B. Die groß angelegte Umstellung auf HTTPS erfolgte hauptsächlich aus Datenschutzgründen (siehe zum Beispiel RFC 7258, Pervasive Monitoring ist ein Angriff - danke an Michael Kjörling für den Hinweis).

Ihr Die Idee, eine signierte Prüfsumme zu verwenden, wird bereits im gesamten Internet produziert: Software, die Sie herunterladen, wird häufig so überprüft. Paketmanager / Update-Systeme der meisten Betriebssysteme tun dies, und einzelne Softwareprojekte tun dies in kleinerem Maßstab, indem sie pgp / gpg-Signaturen zusammen mit ihren Software-Downloads veröffentlichen.

Dies alles funktioniert unabhängig davon, ob diese Downloads sind Wird über https geliefert oder nicht, obwohl https häufig zusätzlich verwendet wird.

Sie schlagen vor, neben http und https ein drittes Protokoll hinzuzufügen, möglicherweise eines mit dem Namen httpv für "verifiziert". , das die Inhaltsüberprüfung in das Protokoll einbaut, aber den Rest von ssl weglässt.

Ich stimme zu, dass es von Vorteil wäre, statischen Inhalt im Klartext bereitzustellen, damit er zwischengespeichert werden kann. Dies ist jedoch keine Option, wenn Sie sich angesichts der Programme der Geheimdienste, mit denen Sie unsere gesamte Kommunikation ausspionieren möchten, Sorgen über Datenschutzprobleme machen.

Gibt es einen bestimmten Grund, warum diese Semi-HTTPs nicht berücksichtigt werden?

Ich würde also davon ausgehen, dass Ihr drittes Protokoll nicht viel Dampf sammeln kann, da

bereits Lösungen vorhanden sind, die funktionieren, wenn wir den Inhalt wirklich überprüfen müssen, und

1. Da so viel Internet verschlüsselt wird, um unsere Privatsphäre zu schützen, scheint es, als würde ein anderes Protokoll, das nicht em nicht verwendet, nicht viel Verwendung finden > vor Spionage schützen.

ol>

Ihr Vorschlag ist, HTTPS grundsätzlich in zwei Teile aufzuteilen: Nur Signieren und Verschlüsselung: Nur Signieren verhindert, dass ein aktiver Mann in der Mitte seinen eigenen Inhalt - wie z. B. Skript-Tags - einfügt, und die Verschlüsselung schützt vertrauliche Daten.

Aber wer würde entscheiden, was sensible Daten sind und was nicht? Dies scheint zeitaufwändig und fehleranfällig zu sein.

Sie können Bilder, CSS, Videos und JS-Dateien natürlich automatisch als nicht vertraulich deklarieren. Aber sind sie?

Ihre Idee würde auch einige andere Änderungen erfordern:

• Was ist mit HSTS? Es erzwingt den gesamten Datenverkehr über HTTPS und wird dringend empfohlen. Würde Ihr Nur-Zeichen-HTTP zählen? Wie würde das in der Praxis funktionieren?
• Was ist mit Usability? Die Browser-Oberfläche müsste dem Benutzer anzeigen, welcher "Modus" derzeit verwendet wird. Und es würde eine weitere Schulung des Benutzers darüber erfordern, was die Modi bedeuten und wann welcher Modus geeignet ist. Dies führt zu großer Verwirrung (Benutzer verstehen nicht einmal alle Elemente der aktuellen Benutzeroberfläche, wie z. B. das Vorhängeschloss oder die verschiedenen Warnungen).
• Sie müssten dem ISP-Caching-Server irgendwie ein Signal geben dass Sie diese Datei anfordern. Sie können die Anfrage nicht einfach über HTTP an den Server senden, da dadurch Cookies und andere vertrauliche Daten verloren gehen. Oder Sie müssen angeben, dass Cookies niemals an diese nicht sensiblen Dateien gesendet werden dürfen. Aber wie würden Sie das zuverlässig machen? Sicher, sie könnten von einer anderen Domain aus bedient werden, aber das erfordert eine umfassende Neugestaltung bestehender Websites. Und was ist, wenn diese nicht vertraulichen Dateien durch eine Art Authentifizierung geschützt werden sollen?

Abgesehen davon scheinen die Vorteile dieses Ansatzes gering zu sein. Nach dem, was ich lese, zwischenspeichern ISPs selten mehr etwas, weil CDNs sich bereits darum kümmern.

tl; dr : Der Ansatz würde die Privatsphäre der Benutzer verletzen und Sicherheitsprobleme aufgrund von Usability-Problemen sowohl für den Endbenutzer als auch für den Entwickler verursachen.

Das Implementieren einer Prüfsumme würde funktionieren, ja. Die Verwendung von TLS ist jedoch viel einfacher.

Es wird im Allgemeinen auch empfohlen, Standardprotokolle zu verwenden, es sei denn, Sie haben einen guten Grund, dies nicht zu tun.

Schließlich bietet https eine Reihe weiterer Vorteile. Innerhalb der Grenzen des CA-Systems wissen Sie, dass Sie die Datei erhalten, von der Sie glauben, dass Sie sie sind. Und es bietet Ihren Benutzern Datenschutz und verhindert, dass Beobachter sehen, welche spezifischen URLs sie anfordern.

Es gibt einige Sicherheitsprobleme, an die ich denken kann.

Wiedergabe und Ersetzung

Nichts hindert einen Mann in der Mitte daran, eine signierte Ressource durch eine andere signierte Ressource zu ersetzen ( zuvor erfasst). Zum Beispiel kann ich möglicherweise eine grüne GO-Taste dort anzeigen lassen, wo sich eine STOP-Taste befinden sollte, sodass Sie von einer Klippe fahren. Oder ich könnte den Eindruck erwecken, dass Ihre Geldüberweisung fehlgeschlagen ist, sodass Sie sie immer wieder einreichen und ich mehrmals bezahlt werde.

Wenn ein Teil des statischen Inhalts einer Website eine Javascript-Datei ist, kann ich sie möglicherweise austauschen mit einer anderen Javascript-Datei die gleiche Seite. Wenn ich schlau bin, kann ich vielleicht einen finden, der die gleichen Funktionsnamen hat, aber unterschiedliche Aufgaben ausführt oder bestimmte Validierungen fehlt.

Umleitung

Ich könnte Ihre Anfrage nach einem Bild abfangen und Antworten Sie mit einer 302-Weiterleitung an eine URL, deren Querystring-Parameter einen XSRF-Angriff umfassen.

Verlust der Privatsphäre

Ein Hacker, der Ihren Datenverkehr überwacht, kann möglicherweise anhand der Prüfung feststellen, welche Seiten Sie besuchen Das Muster der http-Anforderungen für statische Ressourcen.

DoS über Cache-Vergiftung

Ein Hacker, der einen Mann in der Mitte beschäftigt, ersetzt eine der Antworten durch eine ungültige Datei. Der Proxy speichert die Datei zwischen. Browser, die versuchen, die zwischengespeicherte Ressource zu verwenden, stellen fest, dass die Validierung fehlschlägt und ein Fehler angezeigt wird, ohne dass das Problem auf einfache Weise umgangen werden kann.

P.S. Leistungsproblem

Außerdem gibt es ein Leistungsproblem: Ressourcen, die einer Prüfsumme unterliegen, können nicht schrittweise gerendert werden, da das gesamte BLOB zur Berechnung der Prüfsumme erforderlich ist. Ihre Bilder erscheinen also langsamer und Ihr Film startet erst, wenn das Ganze die Pipe durchlaufen hat.

Dies wird teilweise durch die Subressourcenintegrität gelöst. Sie bedienen die Hauptseite über HTTPS, einschließlich der Metadaten / Hashes der Unterressourcen. Die Unterressourcen können dann über HTTP abgerufen werden, um von ISP-Proxys zwischengespeichert zu werden, oder über HTTPS, um von einem CDN zwischengespeichert zu werden, und Sie können sicher sein, dass die Ressource nicht manipuliert ist von den Vermittlern, solange der Hash übereinstimmt.

Browser betrachten Subressourcen, die auf diese Weise bereitgestellt werden, jedoch weiterhin als gemischten Inhalt, da jedes Modell, das das Zwischenspeichern von ISPs ermöglicht, nicht vertraulich behandelt wird. Stattdessen besteht das Modell, das heutzutage vorangetrieben wird, darin, dass Websitebesitzer ein CDN für das Edge-Netzwerk-Caching einrichten. Daher werden Edge-Caches vom Site-Eigentümer und nicht von den Benutzern bezahlt. Dies ist auch ein gutes Zeichen für den ISP als Dummkopfmodell der Netzwerkneutralität.

Wenn wir am Ende eine vom privaten Schlüssel signierte Prüfsumme haben können, wird dies dann nicht die Gültigkeit beweisen? ... Gibt es einen bestimmten Grund, warum diese Semi-HTTPs nicht berücksichtigt werden?

Wahrscheinlich, weil es trivial ist, die Signatur zu entfernen, und Sie auf nicht signierte Inhalte zurückgreifen. Für das SRI-Modell muss im Hauptdokument angegeben werden, wann die Unterressource voraussichtlich gesichert sein wird.

Es versteht sich, dass die Browser-Anbieter nur schlechte Erfahrungen mit "Middleboxes" gemacht haben und sich für eine End-to-End-Verschlüsselung entschieden haben, um zu verhindern, dass sie stören. Aus diesem Grund lehnen sie beispielsweise die Implementierung von Klartext-HTTP / 2.0 ab. Aus dem gleichen Grund ist es sehr unwahrscheinlich, dass jemals etwas in die Richtung Ihrer Idee übernommen wird.

Es gibt Techniken zum Signieren statischer Website-Inhalte, insbesondere von HTML, z. B.:

• http://www.sanface.com/pgphtml.html
• https://web.archive.org/web/20080725190448/http://members.aol.com/EJNBell/pgp-www.html

Solche Initiativen sind noch nicht populär geworden. Ich vermute, dies hat drei Gründe:

• sie sind umständlich umzusetzen;
• der kulturelle Wandel hin zu einer sichereren Webentwicklung (von der die weit verbreitete Verwendung von HTTPS eine Facette ist) Als sie erstmals vorgeschlagen wurden, steckten sie noch in den Kinderschuhen.
• Viele Webentwickler wissen nicht, wie man OpenPGP-Tools verwendet, geschweige denn, dass sie einen sicher generierten und sicher gespeicherten OpenPGP-Signaturschlüssel besitzen.

Dennoch stellen diese Techniken im Prinzip einen hervorragenden Mechanismus zur Überprüfung der Integrität statischer Ressourcen auf Websites dar.

Selbst wenn solche statischen Webressourcen signiert werden Wenn sie universell wären, hätte die Implementierung von HTTPS jedoch immer noch einen Vorteil: Vertraulichkeit . Das Signieren allein würde dies nicht bieten, aber die von HTTPS bereitgestellte Verschlüsselung würde dies ermöglichen. (Zumindest würde HTTPS Vertraulichkeit gewährleisten, solange die für HTTPS geltende Spezifikation keine kritischen Fehler aufweist und ordnungsgemäß implementiert wurde.)