11. Server Implementation and Deployment Advice (Server-Implementierungs- und Bereitstellungsratschläge)

Dieser Abschnitt ist nicht normativ.

11.1. Non-Conformant User Agent Considerations (Überlegungen zu nicht konformen Benutzeragenten)

Nicht konforme UAs ignorieren das Strict-Transport-Security-Header-Feld; daher lösen nicht konforme Benutzeragenten die in Abschnitt 2.3.1 ("Threats Addressed") beschriebenen Bedrohungen nicht. Siehe Abschnitt 14.2 ("Non-Conformant User Agent Implications") für weitere Diskussionen.

11.2. HSTS Policy Expiration Time Considerations (Überlegungen zur HSTS-Richtlinien-Ablaufzeit)

Server-Implementierungen und Website-Bereitstellungen müssen überlegen, ob sie die Ablaufzeit auf einen konstanten Wert in der Zukunft oder auf einen festen Zeitpunkt setzen.

Der Ansatz "konstanter Wert in der Zukunft" kann durch kontinuierliches Senden desselben max-age-Werts an UAs erreicht werden.

Zum Beispiel entspricht ein max-age-Wert von 7776000 Sekunden 90 Tagen:

Strict-Transport-Security: max-age=7776000

Beachten Sie, dass der UA seine Vorstellung davon, wann er seine Kenntnis dieses bekannten HSTS-Hosts löschen muss, jedes Mal aktualisieren muss, wenn er dieses Header-Feld empfängt.

Der Ansatz "fester Zeitpunkt" kann erreicht werden, indem ein max-age-Wert gesendet wird, der die verbleibende Zeit bis zur gewünschten Ablaufzeit darstellt. Dies erfordert, dass der HSTS-Host in jeder HTTP-Antwort einen neu berechneten max-age-Wert sendet.

Eine Überlegung hier ist, ob Bereitsteller die signalisierte HSTS-Richtlinien-Ablaufzeit mit der Ablaufzeit des Website-Domainnamen-Zertifikats abgleichen möchten.

Darüber hinaus sollten Server-Implementierer erwägen, in ihren Bereitstellungskonfigurationssystemen einen Standard-max-age-Wert von Null zu verwenden. Dies würde Bereitsteller dazu zwingen, max-age absichtlich festzulegen, damit UAs die HSTS-Richtlinie für ihre Hosts durchsetzen, und würde sie davor schützen, HSTS versehentlich mit einer beliebigen Nicht-Null-Dauer zu aktivieren.

11.3. Using HSTS in Conjunction with Self-Signed Public-Key Certificates (Verwendung von HSTS in Verbindung mit selbstsignierten öffentlichen Schlüsselzertifikaten)

Wenn alle vier folgenden Bedingungen wahr sind...

• Eine Website/Organisation/Unternehmen generiert ihre eigenen sicheren Transport-öffentlichen Schlüsselzertifikate für die Website, und

• Das Root-CA-Zertifikat dieser Organisation ist normalerweise nicht standardmäßig in Browser- und/oder Betriebssystem-CA-Zertifikatsspeichern eingebettet, und

• Die HSTS-Richtlinie ist auf Hosts aktiviert, die sich mit von der Organisations-CA signierten Zertifikaten (d. h. "selbstsignierten Zertifikaten") identifizieren, und

• Dieses Zertifikat stimmt nicht mit verfügbaren TLS-Zertifikatsassoziationen überein (wie in Abschnitt 4 der TLSA-Protokollspezifikation [RFC6698] definiert),

...dann werden sichere Verbindungen zu dieser Site durch das HSTS-Design fehlschlagen. Dies dient dazu, verschiedene aktive Angriffe zu verhindern, wie oben diskutiert.

Wenn die Organisation jedoch ihre eigene CA und selbstsignierte Zertifikate in Verbindung mit HSTS verwenden möchte, kann sie dies tun, indem sie ihr Root-CA-Zertifikat in den CA-Root-Zertifikatsspeichern ihrer Benutzer-Browser oder -Betriebssysteme bereitstellt. Sie kann auch zusätzlich oder alternativ hostspezifische Endentitätszertifikate an die Browser ihrer Benutzer verteilen. Es gibt mehrere Möglichkeiten, dies zu erreichen (Details liegen außerhalb des Umfangs dieser Spezifikation). Sobald ihr Root-CA-Zertifikat in Browsern installiert ist, kann sie die HSTS-Richtlinie auf ihren Sites verwenden.

Alternativ kann die Organisation das TLSA-Protokoll bereitstellen; alle Browser, die auch TLSA verwenden, können den über TLSA dargestellten verfügbaren TLS-Zertifikatsassoziationen identifizierten Zertifikaten vertrauen.

HINWEIS: Das interaktive Verteilen von Root-CA-Zertifikaten an Benutzer, z. B. per E-Mail, und das Installieren durch Benutzer könnte als Training der Benutzer angesehen werden, anfällig für eine mögliche Form von Phishing-Angriffen zu sein. Siehe Abschnitt 14.8 ("Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack"). Daher sollte Vorsicht geboten werden bei der Art und Weise, wie solche Zertifikate auf den Systemen und Browsern der Benutzer verteilt und installiert werden.

11.4. Implications of includeSubDomains (Auswirkungen von includeSubDomains)

Die includeSubDomains-Direktive hat praktische Auswirkungen, die sorgfältige Überlegung verdienen; zwei Beispielszenarien sind:

• Ein HSTS-Host bietet unsichere HTTP-basierte Dienste auf alternativen Ports oder verschiedenen Subdomains seines HSTS-Host-Domainnamens an.

• Verschiedene Webanwendungen werden auf verschiedenen Subdomains des HSTS-Hosts angeboten, sodass UAs in der Regel direkt mit diesen Subdomain-Webanwendungen interagieren, ohne notwendigerweise mit der auf dem HSTS-Host-Domainnamen angebotenen Webanwendung (falls vorhanden) zu interagieren.

Die folgenden Unterabschnitte diskutieren jedes dieser Szenarien der Reihe nach.

Für vollständige Details siehe RFC 6797.