Diskussion:HTTP Strict Transport Security

Verständlichkeit

Den Satz "(...) die Limitierungen des trust on first use-Prinzips für eine definierte Liste von Domains umgangen." finde ich so nicht wirklich allgemeinverständlich, auch da das first usw Prinzip noch ein Rotlink ist. Kann man besser erklären was damit gemeint ist? Viele Grüße, Luke081515 20:11, 3. Feb. 2019 (CET)

Hi Luke, ich hoffe mit meiner Änderung konnte ich das first-use-Prinzip besser beschreiben. Grüße Tfr.didi (Diskussion) 22:20, 26. Mär. 2023 (CEST)

Thema nicht mehr aktuell? Oder doch?

Ich stolperte gerade über den Satz "Stand 2018 war das Problem für gängige Browser nicht mehr gegeben.". Aber in 2019 dann doch wieder? Also ich kam durch diesen Beitrag aus dem Jahr 2019 https://www.reddit.com/r/firefox/comments/be9av0/sitesecurityservicestatetxt_file_keeps_storing/ auf das anscheinend kritische Thema HSTS und damit zu dieser Wikipedia-Seite.

Die angegebene Quelle bezieht sich anscheinend nur auf Online-Tracking, nicht auf den eigentlichen Sinn des Inkognito-Modus des Browsers. Zumindest kommuniziert der Firefox seinen "Privaten Modus" so, dass er keinerlei Informationen über die besuchten Seiten speichern würde. Wenn meine in wenigen Minuten zusammengetragenen Informationen nun stimmen sollten (kurze Recherche zur unbekannten Datei SiteSecurityServiceState.txt), dann kann jeder durch einen Blick in die HSTS-Historie sofort sehen, welche "gesicherten" Seiten aufgerufen wurden.

Kann das bitte noch einmal richtig recherchiert und im Artikel korrigiert werden? Der aktuelle Schlusssatz stellt da wohl nicht die wirkliche Situation dar. --92.206.134.107 12:12, 5. Feb. 2023 (CET)

Verweis zu HTTP_Public_Key_Pinning hinzufügen?

Ich verwechsle die beiden immer, das Public Key Pinning wurde aber wohl aufgegeben. Wäre es okay trotzdem darauf zu verweisen, für die Verwechsler wie mich, die auf dieser Seite landen und sich fragen was denn nun aufgegeben wurde und was aktuell noch genutzt wird? --David-ri93 (Diskussion) 15:02, 1. Mär. 2024 (CET)

Ich denke, eine Erwähnung von HTTP Public Key Pinning (HPKP) wäre eher nicht angebracht, da es mit HTTP Strict Transport Security (HSTS) nichts zu tun hat, außer dass beide vierbuchstabige Abkürzungen haben. Diese beiden Verfahren sollen unterschiedlichen Angriffsvektoren entgegenwirken, zwischen denen es keine Überschneidungen gibt. Ich befürchte daher, dass eine Erwähnung bei den meisten Lesern eher zu Verwirrung führen würde, als dass es einen enzyklopädischen Nutzen hätte. Außerdem hatte HPKP aufgrund schwerwiegender Nachteile nie eine nennenswerte Relevanz: Aus Chrome wurde es bereits 2018 wieder entfernt, Safari und Edge haben es nie unterstützt. Sein Nachfolger ist Certificate Transparency, das von allen gängigen Browsern unterstützt wird. Aber wie gesagt, das alles hat mit diesem Artikel über HSTS nichts zu tun. --Winof (Diskussion) 14:20, 11. Okt. 2024 (CEST)

Artikel nicht ganz konsistent

Da steht umseitig z.B.

> Wenn ein Browser einen HSTS-Header erhält, muss er ...

aber gleichzeitig ist es optional, da man als Browser HSTS nicht zwingend unterstützen muss.

> Um HSTS anzuwenden, müssen sich sowohl der Server als auch die Browser der Anwender entsprechend der Vorgabe verhalten.

Der Server muss gar nichts. Ein Client könnte HSTS implizit komplett selbst machen, ganz ohne den Server-Header. Dazu reicht es, wenn der Browser von sich aus nur auf Port 443 geht und nur gültige Zertifikate zulässt.

Der serverseitige Header ist erstmal nur eine Art Empfehlung an den Client, das er sich, wenn er möchte, eben so verhalten solle. Auch gilt: trotz HSTS-Header auf Port 443 kann der Server zeitgleich z.B. auch auf Port 80 alles nochmal unverschlüsselt ausspielen. Da ist es teils so, dass die Browser die Seite via Port 443 anzeigen, sogar wenn das Zertifikat abgelaufen ist (weil man sowieso via Port 80 rankommt).

Auch kann sich jeder die Muße machen, und sich den Code von Firefox oder Chrome auschecken, den HSTS Check entfernen, kompilieren und HSTS-Seiten auf Port 80 oder mit kaputtem Zertifikat ankucken.

Schlussendlich ist HSTS "nur" ein Mechanismus, den Client entsprechend so zu implementieren, um den 08/15-User eine Grundsicherheit bieten zu können, damit der 08/15-User sich nicht mit TLS-Gedöns auseinandersetzen muss.

Der Artikel fokussiert sich auch sehr auf Browser. HSTS ist aber ein HTTP-Mechanimus. Und HTTP machen viele Clients, nicht nur Browser. Beispiel: Mobile Apps oder cURL sind auch HTTP Clients, die prinzipiell HSTS können könnten, aber eben keine Browser sind. --2003:DE:F1C:400:7425:2479:2C3E:866A 23:50, 3. Jun. 2025 (CEST)

Das ist kein Widerspruch: Ein Browser muss nicht HSTS unterstützen, aber wenn er es tut, dann muss er sich an das Protokoll halten. Das Protokoll sagt: bei Vorliegen des HSTS-Headers muss die Kommunikation über HTTPS erfolgen. Wenn der Client das nicht macht, dann unterstützt er nicht HSTS. Dass ein Anwender seine Clientsoftware und somit die implementierten Protokolle modifizieren kann, ist davon unbenommen. --Matthäus Wander 19:49, 4. Jun. 2025 (CEST)

Eine clientseitige HSTS-Implementierung ohne Server-Header ist nicht möglich, weil das Protokoll voraussetzt, dass der Server einen HSTS-Header sendet. Richtig ist: der Client kann HTTPS auch ohne HSTS erzwingen. Das hat mit HSTS aber nichts zu tun. --Matthäus Wander 19:54, 4. Jun. 2025 (CEST)