11. Server Implementation and Deployment Advice (Conseils d'Implémentation et de Déploiement de Serveur)

Cette section est non normative.

11.1. Non-Conformant User Agent Considerations (Considérations pour les Agents Utilisateurs Non Conformes)

Les UA non conformes ignorent le champ d'en-tête Strict-Transport-Security; par conséquent, les agents utilisateurs non conformes ne résolvent pas les menaces décrites dans la section 2.3.1 ("Threats Addressed"). Voir la section 14.2 ("Non-Conformant User Agent Implications") pour une discussion plus approfondie.

11.2. HSTS Policy Expiration Time Considerations (Considérations sur le Temps d'Expiration de la Politique HSTS)

Les implémentations de serveur et les déploiements de sites Web doivent considérer s'ils définissent le temps d'expiration à une valeur constante dans le futur, ou à un point fixe dans le temps.

L'approche "valeur constante dans le futur" peut être réalisée en envoyant continuellement la même valeur max-age aux UA.

Par exemple, une valeur max-age de 7776000 secondes correspond à 90 jours :

Strict-Transport-Security: max-age=7776000

Notez que le UA devra mettre à jour sa notion du moment où il doit supprimer sa connaissance de cet hôte HSTS connu chaque fois qu'il reçoit ce champ d'en-tête.

L'approche "point fixe dans le temps" peut être réalisée en envoyant une valeur max-age représentant le temps restant jusqu'au temps d'expiration souhaité. Cela nécessitera que l'hôte HSTS envoie une valeur max-age nouvellement calculée dans chaque réponse HTTP.

Une considération ici est de savoir si les déployeurs souhaitent faire correspondre le temps d'expiration de la politique HSTS signalée avec le temps d'expiration du certificat de domaine du site Web.

De plus, les implémenteurs de serveur devraient envisager d'utiliser une valeur max-age par défaut de zéro dans leurs systèmes de configuration de déploiement. Cela obligerait les déployeurs à définir intentionnellement max-age pour que les UA appliquent la politique HSTS pour leurs hôtes, et les protégerait contre l'activation involontaire de HSTS avec une durée arbitraire non nulle.

11.3. Using HSTS in Conjunction with Self-Signed Public-Key Certificates (Utilisation de HSTS avec des Certificats à Clé Publique Auto-Signés)

Si les quatre conditions suivantes sont toutes vraies...

• Un site Web/organisation/entreprise génère ses propres certificats à clé publique de transport sécurisé pour le site Web, et

• Le certificat d'autorité de certification (CA) racine de cette organisation n'est généralement pas intégré par défaut dans les magasins de certificats CA des navigateurs et/ou du système d'exploitation, et

• La politique HSTS est activée sur des hôtes qui s'identifient avec des certificats signés par la CA de l'organisation (c'est-à-dire, "certificats auto-signés"), et

• Ce certificat ne correspond pas aux associations de certificats TLS disponibles (telles que définies dans la section 4 de la spécification du protocole TLSA [RFC6698]),

...alors, par conception HSTS, les connexions sécurisées à ce site échoueront. Ceci est pour empêcher diverses attaques actives, comme discuté ci-dessus.

Cependant, si l'organisation souhaite utiliser sa propre CA et ses certificats auto-signés en conjonction avec HSTS, elle peut le faire en déployant son certificat CA racine dans les magasins de certificats CA racine de ses navigateurs ou systèmes d'exploitation d'utilisateurs. Elle peut également distribuer en plus ou à la place des certificats d'entité terminale spécifiques à un hôte aux navigateurs de ses utilisateurs. Il existe plusieurs façons d'accomplir cela (les détails dépassent le cadre de cette spécification). Une fois que son certificat CA racine est installé dans les navigateurs, elle peut utiliser la politique HSTS sur ses sites.

Alternativement, l'organisation peut déployer le protocole TLSA; tous les navigateurs utilisant également TLSA pourront faire confiance aux certificats identifiés par les associations de certificats TLS disponibles représentées via TLSA.

NOTE : Distribuer interactivement des certificats CA racine aux utilisateurs, par exemple par e-mail, et faire en sorte que les utilisateurs les installent, peut être considéré comme entraînant les utilisateurs à être vulnérables à une forme possible d'attaque de phishing. Voir la section 14.8 ("Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack"). Par conséquent, il faut faire attention dans la manière dont de tels certificats sont distribués et installés sur les systèmes et navigateurs des utilisateurs.

11.4. Implications of includeSubDomains (Implications d'includeSubDomains)

La directive includeSubDomains a des implications pratiques qui méritent une considération attentive; deux exemples de scénarios sont :

• Un hôte HSTS offre des services basés sur HTTP non sécurisés sur des ports alternatifs ou divers sous-domaines de son nom de domaine d'hôte HSTS.

• Différentes applications Web sont offertes sur différents sous-domaines de l'hôte HSTS, de sorte que les UA interagissent généralement directement avec ces applications Web de sous-domaine, sans nécessairement interagir avec l'application Web offerte sur le nom de domaine de l'hôte HSTS (s'il y en a une).

Les sous-sections ci-dessous discutent de chacun de ces scénarios à tour de rôle.

11.4.1. Considerations for Offering Unsecured HTTP Services (Considérations pour l'Offre de Services HTTP Non Sécurisés)

Par exemple, les autorités de certification offrent généralement leurs services de distribution CRL et OCSP [RFC2560] via HTTP brut, parfois sur des sous-domaines d'applications Web accessibles au public qui peuvent être protégées par TLS/SSL.

Si ca.example.com devait émettre une politique HSTS avec la directive includeSubDomains, alors les agents utilisateurs basés sur HTTP implémentant HSTS qui ont interagi avec l'application Web ca.example.com ne pourront pas récupérer les CRL et ne pourront pas vérifier OCSP pour les certificats, car ces services sont offerts via HTTP brut.

Dans une telle situation, l'exemple de CA pourrait :

• Ne pas utiliser la directive includeSubDomains, ou

• S'assurer que les services basés sur HTTP offerts sur les sous-domaines de ca.example.com sont également offerts uniformément via TLS/SSL, ou

• Offrir les services basés sur HTTP brut sur un nom de domaine différent, par exemple, crl-and-ocsp.ca.example.NET, ou

• Utiliser des méthodes alternatives de distribution de l'état des certificats qui évitent le besoin d'offrir des services de distribution CRL et OCSP via HTTP brut (par exemple, l'extension TLS "Certificate Status Request" [RFC6066], communément appelée "OCSP Stapling").

11.4.2. Considerations for Offering Web Applications at Subdomains (Considérations pour l'Offre d'Applications Web sur des Sous-Domaines)

Dans ce cas, un hôte HSTS déclare une politique HSTS avec la directive includeSubDomains, et il existe également différentes applications Web à différents sous-domaines de l'hôte HSTS, de sorte que les UA interagissent généralement directement avec ces applications Web de sous-domaine, sans nécessairement interagir avec l'hôte HSTS. Dans ce cas, les UA ne recevront ni n'appliqueront la politique HSTS.

Pour résoudre ce problème, les hôtes HSTS devraient être configurés de sorte que le champ d'en-tête STS soit émis directement sur chaque nom de domaine ou de sous-domaine d'hôte HSTS qui constitue des "points d'entrée" bien connus de leur application Web, qu'ils adoptent ou non la directive includeSubDomains.