it-swarm.com.de

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

Diese Methode, über die ich spreche, kann das Caching von Bildern, Videos und CSS durch den ISP verbessern, anstatt nur vom Browser-Cache abhängig zu sein. Und es beweist auch die Gültigkeit des Absenders. Gibt es einen Grund, warum diese Semi-HTTPs nicht berücksichtigt werden?

Die Kosten für das asymmetrische Signieren sind eine Sache, an die ich denken kann. Wenn wir jedoch Teile statischen Inhalts gruppieren und die sha256-Prüfsumme stapelweise berechnen, kann die Überprüfung der Signatur im Browser ein besserer Kompromiss sein als die End-to-End-Netzwerkkosten für jede Anforderung, die sich nicht im Browser-Cache befindet.

26
kalyan

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

Ich denke, Sie stellen mit dieser Frage einen Strohmann auf. 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. Der groß angelegte Wechsel zu HTTPS erfolgte hauptsächlich aus Datenschutzgründen (siehe zum Beispiel RFC 7258, Pervasive Monitoring ist ein Angriff - danke an Michael Kjörling für diesen Hinweis).

Ihre Idee, eine signierte Prüfsumme zu verwenden, wird bereits im gesamten Internet produziert: Software, die Sie herunterladen, wird häufig auf diese Weise ü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 über https bereitgestellt werden 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 integriert, den Rest von ssl jedoch weglässt.

Ich bin damit einverstanden, dass es von Vorteil wäre, statische Inhalte im Klartext bereitzustellen, damit sie zwischengespeichert werden können. 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 Steam sammeln kann, weil

  1. es gibt bereits Lösungen, die funktionieren, wenn wir den Inhalt wirklich überprüfen müssen

  2. da so viel Internet jetzt verschlüsselt wird, um unsere Privatsphäre zu schützen, scheint es, als würde ein anderes Protokoll, das nicht nicht geschützt hat, nicht viel Verwendung finden gegen Spionage.

54
Out of Band

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?

  • JS-Dateien werden zum Datenaustausch verwendet
  • Bilder und Videos können hochsensible Daten enthalten
  • CSS-Dateien bieten möglicherweise einen Einblick in die bestimmte Seite, die eine Person anzeigt
  • Alle Anforderungen können vertrauliche Daten in der Antwort des HTTP-Headers enthalten (z. B. gesetzte Cookies).

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 Aufklärung 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 signalisieren, 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 gründliche Neugestaltung bestehender Websites. Und was ist, wenn diese nicht sensiblen 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.

16
tim

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

Es wird auch allgemein empfohlen, Standardprotokolle zu verwenden, es sei denn, Sie haben einen wirklich 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.

Wiederholung und Ersetzung

Nichts hindert einen Mann in der Mitte daran, eine signierte Ressource durch eine andere signierte Ressource (zuvor erfasst) zu ersetzen. 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 es so aussehen lassen, als ob Ihre Geldüberweisung fehlgeschlagen ist, sodass Sie es immer wieder einreichen und ich mehrmals bezahlt werde.

Wenn ein Teil des statischen Inhalts einer Site eine Javascript-Datei ist, kann ich ihn möglicherweise mit einer anderen Javascript-Datei derselben Site austauschen. Wenn ich schlau bin, kann ich vielleicht einen finden, der die gleichen Funktionsnamen hat, aber verschiedene Dinge tut oder bestimmte Validierungen fehlt.

Umleitung

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

Verlust der Privatsphäre

Ein Hacker, der Ihren Datenverkehr überwacht, kann möglicherweise feststellen, welche Seiten Sie besuchen, indem er das Muster der http-Anforderungen für statische Ressourcen untersucht.

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. So erscheinen Ihre Bilder langsamer und Ihr Film startet erst, wenn das Ganze die Pipe durchlaufen hat.

13
John Wu

Dies wird teilweise durch Subressourcenintegrität gelöst. Sie stellen die Hauptseite über HTTPS bereit. Dazu gehören die 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 gepusht wird, darin, dass Websitebesitzer ein CDN für das Edge-Netzwerk-Caching einrichten. Daher werden Edge-Caches vom Websitebesitzer 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 das 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.

12
Lie Ryan

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 irgendetwas in der Richtung Ihrer Idee jemals angenommen wird.

1
zwol

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

Solche Initiativen sind noch nicht populär geworden. Ich vermute, das 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) steckte noch in den Kinderschuhen, als sie erstmals vorgeschlagen wurden.
  • 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 eine solche Signatur statischer Webressourcen universell wäre, hätte die Implementierung von HTTPS dennoch 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.)

1
sampablokuper