24. HSTS : persistance d’une exigence HTTPS

Comprendre le mécanisme

Strict-Transport-Security permet au navigateur de mémoriser une exigence de transport HTTPS pour un hôte dans les conditions du mécanisme. Ce choix n’installe pas un certificat valide et ne répare pas un service indisponible en TLS. Les options de sous-domaines étendent le périmètre et demandent un inventaire préalable. Le préchargement ajoute encore un processus et des conséquences distinctes d’un simple en-tête reçu.

Raisonner et vérifier

Déployez progressivement, après vérification des sous-domaines et du renouvellement des certificats. Une modification de configuration n’efface pas instantanément toutes les politiques déjà mémorisées par les clients. Testez les redirections, les liens générés et les contextes derrière proxy. Une courte durée de laboratoire facilite l’observation sans transformer une erreur de périmètre en engagement durable.

Politique mémorisée

HSTS mémorise une politique de transport côté client. Le contrôle ne provisionne pas les certificats. HSTS informe le client d’une exigence HTTPS pour le périmètre concerné. Il ne génère aucun certificat et ne répare pas une chaîne invalide ; ces responsabilités doivent être traitées séparément.

Sous-domaines

La portée includeSubDomains demande un inventaire. La politique peut étendre ses exigences aux sous-domaines. includeSubDomains étend le périmètre au-dessous du domaine concerné. Inventoriez services anciens, noms délégués et dépendances avant activation, car ils devront eux aussi satisfaire la politique de transport.

Durée

Un max-age élevé prolonge la politique mémorisée. Les clients peuvent conserver l’état reçu précédemment. Un grand max-age garde l’exigence longtemps dans les clients qui l’ont apprise. Une modification serveur ne peut pas effacer instantanément tout cet état déjà distribué dans les navigateurs.

Apprentissage sûr

HSTS s’apprend via le canal sécurisé prévu. La politique ne doit pas être établie par une source non authentifiée. Le client apprend HSTS via le canal sécurisé prévu. Un header reçu sur un trajet non conforme ne doit pas être présenté comme une garantie équivalente pour établir cette confiance.

Déploiement progressif

Une montée progressive limite les surprises. La portée et le renouvellement doivent être maîtrisés. Commencez avec un périmètre et une durée contrôlés, vérifiez les erreurs et augmentez selon le plan. Cette progression doit rester compatible avec vos exigences de transport et les clients concernés.

Certificat

Un certificat invalide doit être corrigé. Le mécanisme de transport ne corrige pas l’identité du pair. Le service doit présenter un certificat valide et renouvelé. HSTS peut rendre certaines erreurs plus bloquantes pour le visiteur ; sa présence augmente l’importance d’une exploitation TLS correcte.

Premier contact

Le premier contact dépend du contexte et des politiques préchargées. L’apprentissage et le préchargement ont des modèles distincts. La protection du premier accès dépend de l’état client et d’éventuelles politiques préchargées. Évitez de promettre une connaissance préalable universelle simplement parce qu’un header est désormais configuré.

Retrait

Le retrait doit tenir compte de l’état déjà mémorisé. L’absence de nouveau champ ne supprime pas nécessairement l’ancien état. Un rollback doit tenir compte des clients qui ont mémorisé la politique. Maintenez HTTPS pendant la transition prévue et vérifiez comment la nouvelle politique est reçue par les clients déjà concernés.

Métier distinct

Le transport sécurisé ne vérifie pas les droits métier. Les permissions restent dans l’application. Une connexion HTTPS exigée peut transporter une demande interdite. Vérifiez toujours l’utilisateur, la ressource précise et l’intention ; la persistance de transport n’établit aucun droit de modification.

Vérification de portée

Les tests doivent inclure les sous-domaines concernés. Les services inclus peuvent avoir des configurations différentes. Testez domaine principal et sous-domaines inclus avec certificats et routages réels. Le succès de la page principale ne démontre pas le maintien du transport sur un service secondaire oublié.

Atelier guidé : lire, expliquer et vérifier le code

Strict-Transport-Security: max-age=31536000; includeSubDomains

Le header engage une durée d’un an et inclut les sous-domaines. Expliquez ces deux dimensions avant de le recopier. Vérifiez l’inventaire et le renouvellement des services concernés, puis distinguez cette exigence de transport de la validité du certificat et des permissions applicatives.

includeSubDomains élargit précisément la portée. La portée et le maintien de TLS doivent correspondre aux services inclus. HSTS ne provisionne pas les certificats. Les clients peuvent conserver la politique.

Travail pratique : Inventoriez les hôtes et dépendances avant d’envisager une politique couvrant les sous-domaines. Simulez un renouvellement de certificat.

Critères de correction : Vérifiez chaque service HTTPS et le comportement d’un navigateur neuf puis déjà exposé à la politique. Documentez durée, périmètre et procédure d’incident. N’activez pas une extension de périmètre sur la seule base du domaine principal.