1. Introduction
HTTP [RFC2616] peut fonctionner sur divers transports, typiquement le Transmission Control Protocol (TCP). Cependant, TCP ne fournit pas de protection de l'intégrité du canal, de confidentialité ou d'identification sécurisée de l'hôte. Ainsi, le protocole Secure Sockets Layer (SSL) [RFC6101] et son successeur, Transport Layer Security (TLS) [RFC5246], ont été développés pour fournir une sécurité orientée canal, typiquement en couches entre les protocoles d'application et TCP.
Les UAs utilisent diverses politiques de sécurité locales lors de l'interaction avec des ressources web, dont les caractéristiques dépendent en partie du fait qu'ils communiquent avec l'hôte d'une ressource web donnée en utilisant HTTP ou HTTP-sur-Transport-Sécurisé.
Les UAs annoncent généralement à leurs utilisateurs tout problème lors de l'établissement sécurisé d'une connexion, comme l'incapacité à valider une chaîne de confiance de certificat de serveur TLS. Souvent, les UAs permettent à leurs utilisateurs de choisir de continuer à interagir avec l'hôte d'une ressource web face à de tels problèmes. Ce comportement a été informellement appelé "click-through insecurity".
Cette spécification incarne et affine l'approche proposée dans [ForceHTTPS]. Elle définit un champ d'en-tête de réponse HTTP pour les politiques et permet à un hôte de ressource web de déclarer que sa politique s'applique à l'ensemble du sous-arbre de nom de domaine.
1.1 Organization of This Specification (Organisation de cette Spécification)
Cette spécification commence par un aperçu des cas d'utilisation, des effets de politique, du modèle de menace et des exigences pour HSTS (dans la Section 2). La Section 3 définit ensuite les critères de conformité. Le mécanisme HSTS lui-même est formellement spécifié dans les Sections 5 à 15.
1.2 Document Conventions (Conventions du Document)
NOTE: Ceci est une note aux lecteurs. Ce sont des points qui doivent être gardés à l'esprit et/ou pris en considération.