it-swarm.com.de

Warum HTTPS Everywhere verwenden, wenn wir HSTS-unterstützte Browser haben?

Ich weiß, dass das Standardprotokoll des Browsers für den Zugriff auf eine Site http:// Ist, wenn https:// Explizit nicht erwähnt wird, aber selbst dann, wenn wir zu einer Website navigieren, sagen wir www.facebook.com, Den Antwortheader von den Facebook-Servern hätte HSTS erwähnt und unser Browser würde uns von http:// nach https:// leiten. Warum brauchen wir das? ein anderes Plugin, um dies zu tun, wenn der Browser dies für den Benutzer selbst tut? Was ist der Zweck von HTTPS Everywhere , wenn unser Browser seine Aufgabe standardmäßig erledigt?.

66
GypsyCosmonaut

selbst dann, wenn wir zu einer Website mit dem Namen www.facebook.com navigieren, hätte der Antwortheader von den Facebook-Servern HSTS erwähnt

Ich habe eine curl Anfrage an http://www.facebook.com und das habe ich bekommen:

< HTTP/1.1 302 Found
< Location: https://www.facebook.com/
< Content-Type: text/html
< X-FB-Debug: zgK/A+8XSlghi/vWvAivsZ04gawpdr+3BuO7yuQaKDdrP/+B14oSVDSreHh0GbchyNPnav39pQq9Zgw5mSXX5A==
< Date: Sat, 29 Apr 2017 19:23:25 GMT
< Connection: keep-alive
< Content-Length: 0

Wie Sie sehen, gibt es hier keinen HSTS-Header, da gemäß seiner Spezifikation (RFC6797) :

Ein HSTS-Host darf das STS-Headerfeld NICHT in HTTP-Antworten enthalten, die über einen nicht sicheren Transport übertragen werden.

Webbrowser ignorieren auch HSTS-Header in HTTP-Antworten:

Hinweis: Der Header "Strict-Transport-Security" wird vom Browser ignoriert, wenn auf Ihre Site über HTTP zugegriffen wird. Dies liegt daran, dass ein Angreifer möglicherweise HTTP-Verbindungen abfängt und den Header einfügt oder entfernt. Wenn auf Ihre Site über HTTPS ohne Zertifikatfehler zugegriffen wird, weiß der Browser, dass Ihre Site HTTPS-fähig ist, und berücksichtigt den Strict-Transport-Security-Header.

Der Zweck von HSTS besteht darin, den Client anzuweisen, NICHT zu HTTP zu wechseln, sobald er über HTTPS auf eine Website zugegriffen hat, und nicht umgekehrt. Von Wikipedia :

HTTP Strict Transport Security (HSTS) ist ein Mechanismus für Web-Sicherheitsrichtlinien, mit dem Websites vor Angriffen durch Protokoll-Downgrade und Cookie-Hijacking geschützt werden können.

Protokoll-Downgrade-Angriff :

Ein Downgrade-Angriff ist eine Form des Angriffs auf ein Computersystem oder ein Kommunikationsprotokoll, bei der ein qualitativ hochwertiger Betriebsmodus (z. B. eine verschlüsselte Verbindung) zugunsten eines alten Betriebsmodus mit geringerer Qualität (z. B. Klartext) aufgegeben wird dient der Abwärtskompatibilität mit älteren Systemen.

Ein HSTS-Header wird also nicht verwendet, um eine neue HTTP-Verbindung zu HTTPS umzuleiten, sondern um zu verhindern, dass ein Browser HTTP-Anforderungen an eine vorhandene HTTPS-Site sendet.

Das Plugin HTTPS Everywhere stellt andererseits sicher, dass der Webbrowser HTTPS-Verbindungen zu Websites herstellt, die HTTPS unterstützen, aber auch über HTTP zugänglich sind.

Viele Websites im Web bieten eine eingeschränkte Unterstützung für die Verschlüsselung über HTTPS, erschweren jedoch die Verwendung. Beispielsweise können sie standardmäßig unverschlüsseltes HTTP verwenden oder verschlüsselte Seiten mit Links füllen, die auf die unverschlüsselte Site zurückgehen. Die HTTPS Everywhere-Erweiterung behebt diese Probleme, indem sie mithilfe cleverer Technologie Anforderungen an diese Sites in HTTPS umschreibt.

22
A.Jesin

HSTS verwendet ein Trust on First Use Modell. Wenn Ihre erste Verbindung zur Site bereits gefährdet war, wird bei nachfolgenden Anforderungen möglicherweise kein HSTS-Fehler angezeigt.

Das HTTPS Everywhere schließt diese Lücke, indem es Ihrem Browser von der ersten Verbindung an mitteilt, dass es sich bei der Site um eine reine HTTPS-Site handelt.

Einige Websites geben auch dann keinen HSTS-Header bekannt, wenn sie HTTPS unterstützen. Oder ihr HTTPS befindet sich in einer anderen Domäne/einem anderen Pfad (z. B. http://www.example.com aber https://secure.example.com), HTTPS Everywhere versucht, in diesen Situationen zu helfen, indem die URLs der Site neu geschrieben werden.

93
Lie Ryan

HTTPS Everywhere ist clientseitig und HSTS ist serverseitig.

Die Antwort lautet also, dass HTTPS Everywhere in Fällen verteidigt werden soll, in denen der Server keinen HSTS-Header festlegt.

48
tim

HSTS liegt im Ermessen des Website-Betreibers. Sie müssen entscheiden, ob die Sicherheitsvorteile von obligatorischem HTTPS die zusätzliche Serverlast wert sind, Benutzer blockieren, die HTTPS nicht verwenden können, und Caching-Proxys unwirksam machen. Obligatorisches HTTPS ist eine Voraussetzung für HSTS.

Viele Websites bieten HTTPS optional an, aber ob es verwendet werden soll oder nicht, wird normalerweise nicht vom Endbenutzer, sondern von der Person ausgewählt, die einen Link oder eine URL bereitstellt. Mit HTTPS Everywhere können Benutzer HTTPS auf solchen Websites verwenden, selbst wenn der Link oder die eingegebene URL HTTP verwendet.

Da mehr Websites HTTPS obligatorisch machen und HSTS einführen, um das Sicherheitsrisiko durch Klartextumleitungen zu verringern, wird "HTTPS Everywhere" weniger benötigt, aber bis/sofern nicht alle Websites, die HTTPS anbieten, dies tun, wird es weiterhin ein nützliches Plugin sein.

6
Peter Green

Die Frage beruht auf falschen Prämissen.

... wenn wir zu einer Website mit dem Namen www.facebook.com navigieren, wird im Antwortheader der Facebook-Server HSTS erwähnt, und unser Browser leitet uns von http:// bis https://...

ist nicht wahr*. Obwohl die Strict-Transport-Security Header ist ein HTTP-Header. Die HSTS-Spezifikation verlangt, dass Server ihn nur in Antworten einschließen, die über einen verschlüsselten Kanal gesendet werden, und dass Clients ihn ignorieren müssen, wenn er über einen nicht verschlüsselten Kanal gesendet wird. Von RFC 6797 :

HTTP Strict Transport Security Host: ist ein konformer Host, der die HTTP-Serveraspekte der HSTS-Richtlinie implementiert. Dies bedeutet, dass ein HSTS-Host das HTTP-Antwortheaderfeld "Strict-Transport-Security" in seinen HTTP-Antwortnachrichten zurückgibt, die über einen sicheren Transport gesendet werden.

...

Ein HTTP-Host deklariert sich selbst als HSTS-Host, indem er UAs eine HSTS-Richtlinie ausstellt, die durch das HTTP-Antwortheaderfeld Strict-Transport-Security über sicheren Transport (z. B. TLS) dargestellt und über dieses übertragen wird.

...

Ein HSTS-Host darf das STS-Headerfeld NICHT in HTTP-Antworten enthalten, die über einen nicht sicheren Transport übertragen werden.

...

Wenn eine HTTP-Antwort über einen unsicheren Transport empfangen wird, MUSS der UA alle vorhandenen STS-Headerfelder ignorieren.


* Ok, ich schließe die Möglichkeit aus, dass sowohl der Server von Facebook als auch Ihr Browser gegen die HSTS-Spezifikation verstoßen. Und es ist wahr, dass ein gut konfigurierter Server mit HSTS normalerweise auch so konfiguriert ist, dass er entweder Port 80 nicht überwacht oder eine permanente Umleitung an eine HTTPS-URL sendet. Siehe jedoch Abschnitt 7.2 des RFC zu den Einschränkungen.

5
Peter Taylor

Ich sehe, dass noch keine der Antworten das Vorladen von HSTS berührt hat. Zusammenfassend: die in bestehenden Antworten erwähnten Vorbehalte, wie z. B. @ Lie Ryan 's:

HSTS verwendet ein Trust on First Use Modell. Wenn Ihre erste Verbindung zur Site bereits gefährdet war, wird bei nachfolgenden Anforderungen möglicherweise kein HSTS-Fehler angezeigt.

(…)

Einige Websites geben auch dann keinen HSTS-Header bekannt, wenn sie HTTPS unterstützen.

gelten nicht für Websites, die vorinstalliert sind; Das heißt, sie befinden sich in einer Liste, die in den Webbrowser integriert ist. Websites auf dieser Liste werden wie bei HTTPS Everywhere auch beim ersten Besuch immer in HTTPS umgeschrieben.

Aus diesem Grund haben die Betreuer von HTTPS Everywhere entschieden , dass Websites in der Preload-Liste nicht zur Datenbank von HTTPS Everywhere hinzugefügt werden (und möglicherweise aus dieser entfernt werden), um sie erneut zu schreiben.

4
user2428118

In vielen Domänen ist HSTS nicht richtig konfiguriert. Zum Beispiel hat Google HSTS auf www.google.com und seinen Subdomains, aber nicht auf google.com und seinen Subdomains. Daher wird HSTS auf mail.google.com oder drive.google.com aufgrund von Besuchen von https://google.com oder https://www.google.com) nicht erzwungen

Der Grund, warum Google ein solches Setup hat, ist komplex. Die Voraussetzungen für die Aufnahme in die Chrome HSTS-Preload-Liste sind, dass Sie HSTS für eine Domain und ihre Subdomains haben. Ich gehe davon aus, dass Google einige interne und möglicherweise öffentliche hat -facing-Dienste, die nicht über HTTPS funktionieren. HSTS für alle Subdomains von Google.com würde diese Dienste also beschädigen. HSTS für alle www.google.com-Domains deckt wirklich nur www.google.com ab, da es keine gibt Subdomains unter * .www.google.com.

HTTPS Everywhere kann jedoch Regeln enthalten, die viel komplexer sind als HSTS und solche komplexen Anwendungsfälle ermöglichen.

4
seanieb

Ich verwende HTTPS Everywhere speziell für Stack Exchange. Als ich das letzte Mal (vor einigen Monaten) nachgesehen habe, wurde kein HSTS verwendet und nicht einmal von HTTP zu HTTPS umgeleitet. Es wurde jedoch HTTPS bereitgestellt, sodass das Add-On mich vor potenziellem Abhören bewahrte.

Bei Stack Exchange hat sich die Situation möglicherweise jetzt geändert.

0
Neith