12. User Agent Implementation Advice (Benutzeragenten-Implementierungsratschläge)
Dieser Abschnitt ist nicht normativ.
Um Benutzern und Websites effektiveren Schutz zu bieten und zur Kontrolle der Verwaltung ihres UA-HSTS-Richtlinien-Caches sollten UA-Implementierer erwägen, Funktionen wie die folgenden einzuschließen:
12.1. No User Recourse (Kein Benutzer-Rückgriff)
Das Scheitern der Einrichtung einer sicheren Verbindung bei jeder Warnung oder jedem Fehler (gemäß Abschnitt 8.4 ("Errors in Secure Transport Establishment")) sollte mit "keinem Benutzer-Rückgriff (no user recourse)" abgeschlossen werden. Dies bedeutet, dass dem Benutzer kein Dialog präsentiert werden sollte, der es ihm ermöglicht, fortzufahren. Stattdessen sollte es der Behandlung von Serverfehlern ähneln, bei der der Benutzer in Bezug auf die Interaktion mit der Ziel-Webanwendung nichts weiter tun kann, außer zu warten und es erneut zu versuchen.
Im Wesentlichen bedeutet "jede Warnung oder jeder Fehler" alles, was eine UA-Implementierung dazu veranlassen würde, dem Benutzer anzukündigen, dass etwas mit der Verbindungsherstellung nicht ganz richtig ist.
Dies nicht zu tun, d. h. Benutzer-Rückgriff zu erlauben, z. B. "durch den Warn-/Fehlerdialog zu klicken", ist ein Rezept für Man-in-the-Middle-Angriffe. Wenn eine Webanwendung eine HSTS-Richtlinie ausgibt, wählt sie implizit den Ansatz "kein Benutzer-Rückgriff", d. h. alle Zertifikatsfehler oder -warnungen führen zum Abbruch der Verbindung, ohne die Möglichkeit, den Benutzer zu "täuschen", eine falsche Entscheidung zu treffen und sich selbst zu gefährden.
12.2. User-Declared HSTS Policy (Vom Benutzer deklarierte HSTS-Richtlinie)
Eine vom Benutzer deklarierte HSTS-Richtlinie ist die Fähigkeit für einen Benutzer, explizit zu deklarieren, dass ein bestimmter Domainname einen HSTS-Host darstellt, wodurch er als bekannter HSTS-Host angeimpft wird, bevor tatsächlich mit ihm interagiert wird. Dies würde helfen, die Bootstrap-MITM-Schwachstelle zu verhindern, wie in Abschnitt 14.6 ("Bootstrap MITM Vulnerability") diskutiert.
HINWEIS: Eine solche Funktion ist auf Basis pro Site schwierig richtig zu machen. Siehe die Diskussion über "Umschreiberegeln" in Abschnitt 5.5 von [ForceHTTPS]. Zum Beispiel kann eine beliebige Website nicht alle ihre URIs mit dem "https"-Schema konkretisieren, sodass, wenn der UA versucht, ausschließlich mit solchen URIs auf die Site zuzugreifen, diese "kaputt" gehen könnte. Beachten Sie auch, dass diese Funktion die "HSTS-Vorlade-Liste"-Funktion ergänzen, aber unabhängig von ihr sein würde (siehe Abschnitt 12.3).
12.3. HSTS Pre-Loaded List (HSTS-Vorlade-Liste)
Eine HSTS-Vorlade-Liste ist eine Einrichtung, durch die Website-Administratoren UA-Anbieter dazu bringen können, die HSTS-Richtlinie ihrer Site vorzukonfigurieren, ähnlich wie Root-CA-Zertifikate "ab Werk" in Browser eingebettet werden -- die sogenannte "Vorlade-Liste". Dies würde helfen, die Bootstrap-MITM-Schwachstelle zu verhindern (Abschnitt 14.6).
HINWEIS: Eine solche Einrichtung würde die "vom Benutzer deklarierte HSTS-Richtlinie"-Funktion ergänzen (Abschnitt 12.2).
12.4. Disallow Mixed Security Context Loads (Gemischte Sicherheitskontextladungen nicht zulassen)
Eine "gemischte Sicherheitskontext (mixed security context)"-Ladung tritt auf, wenn eine von einem UA über sicheren Transport erhaltene Webanwendungsressource anschließend dazu führt, dass eine oder mehrere andere Ressourcen ohne Verwendung von sicherem Transport erhalten werden. Dies wird auch allgemein als "gemischte Inhalte (mixed content)"-Ladung bezeichnet (siehe Abschnitt 5.3 ("Mixed Content") von [W3C.REC-wsc-ui-20100812]).
HINWEIS: Um Verhaltenskonsistenz zwischen UA-Implementierungen bereitzustellen, würde das Konzept des gemischten Sicherheitskontexts weitere Standardisierungsarbeit erfordern, z. B. klarere Definition der Begriffe und Definition spezifischer damit verbundener Verhaltensweisen.
12.5. HSTS Policy Deletion (HSTS-Richtlinienlöschung)
Die HSTS-Richtlinienlöschung ist die Fähigkeit, die zwischengespeicherte HSTS-Richtlinie des UA auf Basis pro HSTS-Host zu löschen.
HINWEIS: Das Hinzufügen einer solchen Funktion sollte sowohl in Benutzeroberflächen- als auch in Sicherheitsaspekten sehr sorgfältig durchgeführt werden. Das Löschen eines Cache-Eintrags eines bekannten HSTS-Hosts sollte eine sehr überlegte und durchdachte Aktion sein -- es sollte nicht etwas sein, das Benutzer routinemäßig zu tun gewöhnt sind: zum Beispiel einfach "durchklicken", um die Arbeit zu erledigen. Darüber hinaus müssen Implementierungen sich davor schützen, dass ein Angreifer Code (z. B. ECMAscript) in den UA injiziert, der Einträge aus dem Cache bekannter HSTS-Hosts des UA still und programmgesteuert löschen würde.