1. Introduction (Einführung)

HTTP [RFC2616] kann über verschiedene Transportprotokolle betrieben werden, typischerweise das Transmission Control Protocol (TCP). TCP bietet jedoch keinen Schutz der Kanalintegrität, Vertraulichkeit oder sichere Hostidentifikation. Daher wurden das Secure Sockets Layer (SSL)-Protokoll [RFC6101] und sein Nachfolger Transport Layer Security (TLS) [RFC5246] entwickelt, um kanalorientierte Sicherheit zu bieten, die typischerweise zwischen Anwendungsprotokollen und TCP geschichtet ist.

UAs verwenden verschiedene lokale Sicherheitsrichtlinien bei der Interaktion mit Webressourcen, deren Eigenschaften teilweise davon abhängen, ob sie mit dem Host einer bestimmten Webressource über HTTP oder HTTP-über-Sicheren-Transport kommunizieren.

UAs kündigen ihren Benutzern normalerweise Probleme beim sicheren Aufbau einer Verbindung an, wie z.B. die Unfähigkeit, eine TLS-Server-Zertifikat-Vertrauenskette zu validieren. Oft ermöglichen UAs ihren Benutzern, trotz solcher Probleme weiterhin mit dem Host einer Webressource zu interagieren. Dieses Verhalten wird informell als "click-through insecurity" bezeichnet.

Diese Spezifikation verkörpert und verfeinert den in [ForceHTTPS] vorgeschlagenen Ansatz. Sie definiert ein HTTP-Antwort-Headerfeld für Richtlinien und ermöglicht es einem Webressourcen-Host zu erklären, dass seine Richtlinie für den gesamten Domänennamen-Teilbaum gilt.

1.1 Organization of This Specification (Organisation dieser Spezifikation)

Diese Spezifikation beginnt mit einem Überblick über Anwendungsfälle, Richtlinieneffekte, Bedrohungsmodell und Anforderungen für HSTS (in Abschnitt 2). Abschnitt 3 definiert dann Konformitätskriterien. Der HSTS-Mechanismus selbst wird in den Abschnitten 5 bis 15 formal spezifiziert.

1.2 Document Conventions (Dokumentkonventionen)

HINWEIS: Dies ist ein Hinweis an die Leser. Dies sind Punkte, die beachtet und/oder berücksichtigt werden sollten.

---