Headers dépréciés

Deux headers de sécurité TLS sont apparus puis repartis : Public-Key-Pins (HPKP) et Expect-CT. Tous deux tentaient de protéger les sites contre les certificats mal émis, HPKP en épinglant des clés publiques dans le navigateur et Expect-CT en exigeant la Certificate Transparency (CT) avant qu'elle ne soit obligatoire.

Les navigateurs ont retiré les deux. Si un scan trouve l'un ou l'autre header sur votre site, le correctif est de le supprimer.

Il n'y a aucun header de remplacement à envoyer. Ce qui les a supplantés, la Certificate Transparency et les enregistrements DNS CAA, fonctionne sans aucun header de réponse, si bien que la seule action que ces headers appellent est de les retirer de la configuration de votre serveur.

En bref

Public-Key-Pins (HPKP)

HTTP Public Key Pinning (RFC 7469, 2015) permettait à un site d'épingler les clés publiques que sa chaîne de certificats devait contenir. Le header portait une ou plusieurs valeurs pin-sha256, chacune un hash base64 d'une clé publique (sa SPKI), plus un max-age obligatoire, avec des directives séparées par des points-virgules. Le navigateur mettait les pins en cache et refusait toute connexion future à l'hôte dont la chaîne de certificats n'incluait pas l'une des clés épinglées. La spécification exigeait un pin de secours, un pin pour une clé absente de la chaîne actuelle, comme voie de récupération, et une variante Public-Key-Pins-Report-Only qui reportait au lieu de bloquer.

Voici à quoi ressemblait un déploiement. Ne l'envoyez jamais aujourd'hui ; aucun navigateur ne le lit.

Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=";
  pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
  max-age=5184000; includeSubDomains

Trois problèmes l'ont tué :

• Le self-DoS. Perdez les clés épinglées et chaque navigateur qui revient refuse votre site jusqu'à l'expiration de max-age, et les valeurs de 60 jours étaient courantes, donc une seule erreur pouvait rendre le site inaccessible à chaque visiteur qui revient pendant des semaines.
• L'épinglage hostile, connu sous le nom de RansomPKP. Un attaquant qui contrôle brièvement le serveur peut épingler des clés qu'il est seul à détenir et les monnayer ; les navigateurs continuent de rejeter le certificat légitime après que le propriétaire du site a récupéré. Le justificatif de retrait de Chrome nomme exactement ces « risks of denial of service and hostile pinning » (risques de déni de service et d'épinglage hostile).
• Une adoption quasi nulle. L'usage a culminé autour de 3 500 sites dans le top 1 million et était tombé à environ 650 en septembre 2019, dont beaucoup mal configurés.

Chrome a retiré HPKP il y a des années, et Firefox, qui l'avait livré plus tôt, l'a retiré peu après, depuis quoi les headers sont silencieusement ignorés. Safari et Edge ne l'ont jamais livré.

Expect-CT

Expect-CT (RFC 9163) était un pont opt-in vers l'application de la Certificate Transparency, pour la période précédant l'obligation de la CT. Il prenait un max-age obligatoire, un drapeau enforce et un report-uri, séparés par des virgules plutôt que par les points-virgules de HPKP (une source classique de confusion entre les deux). Les deux headers reportaient via des POST JSON report-uri sur mesure qui précèdent la Reporting API ; tout endpoint encore configuré pour eux est aujourd'hui une boîte aux lettres morte.

Expect-CT: max-age=86400, enforce

Le header est devenu inutile par décision de politique. Chrome exige la CT pour tous les certificats publiquement approuvés émis après le 30 avril 2018, si bien qu'un site n'avait plus rien à activer ; les derniers certificats pré-CT ont expiré vers juin 2021. Le RFC n'a été publié qu'en 2022, en statut Expérimental, l'année même où Chrome a retiré le header.

Chrome a retiré Expect-CT il y a des années. Firefox et Safari ne l'ont jamais implémenté.

Ce qui les a remplacés

• La Certificate Transparency, activée par défaut. Chrome exige la CT pour les certificats émis après le 30 avril 2018, et les plateformes Apple pour les certificats émis après le 15 octobre 2018. Les autorités de certification intègrent les preuves SCT dans le certificat lui-même ; les sites n'envoient rien.
• Les enregistrements DNS CAA (RFC 8659) déclarent quelles autorités de certification peuvent émettre pour votre domaine.
• L'épinglage dans l'application pour les clients que vous contrôlez (applications mobiles, clients machine-to-machine), selon le cheat sheet OWASP sur l'épinglage.

Une mise en garde honnête : la CT et la CAA réunies ne couvrent pas tout à fait chaque fonctionnalité de HPKP, mais elles offrent une protection comparable contre la mauvaise émission sans les risques de HPKP.

Risques à les conserver

Il n'y a aucun risque d'application, parce que plus rien n'analyse ces headers ; un pin périmé ne peut aujourd'hui verrouiller personne via le header. Les coûts sont opérationnels : des octets morts sur chaque réponse, des scanners et rapports de pentest qui les signalent comme constats de dépréciation, et le signal qu'un header mort de l'ère 2017 envoie sur une configuration de sécurité non maintenue. Passez votre site dans le scanner de headers de sécurité pour vérifier si l'un ou l'autre header est encore dans vos réponses.

Recommandation

Retirez Public-Key-Pins, Public-Key-Pins-Report-Only et Expect-CT de la configuration de votre serveur. La Certificate Transparency est imposée par défaut pour chaque certificat qu'une CA publique peut émettre aujourd'hui, selon la politique CT de Chrome, il n'y a donc rien à configurer à leur place. Si vous avez réellement besoin d'épinglage pour un client que vous contrôlez, épinglez dans le client en suivant la cheat sheet OWASP sur l'épinglage, jamais via un header de navigateur.

Prise en charge par les navigateurs

Public-Key-Pins :

Expect-CT :

FAQ

Expect-CT est-il encore nécessaire ?

Non. Supprimez-le. Chrome a abandonné la prise en charge du header, et il était propre à Chromium au départ. La Certificate Transparency est désormais imposée par défaut pour chaque certificat qu'une CA publique peut émettre, il ne reste donc plus rien que le header puisse activer. Ce sont des octets morts que les scanners signalent comme constat de dépréciation.

Qu'est-ce qui a remplacé HPKP ?

Côté header, rien à envoyer. La Certificate Transparency tourne par défaut, donc les CA intègrent la preuve dans le certificat et votre site ne configure rien. Les enregistrements DNS CAA vous laissent déclarer quelles CA peuvent émettre pour votre domaine. Pour les clients que vous contrôlez, comme les applications mobiles, épinglez dans le client selon les recommandations OWASP, jamais via un header de navigateur.

Faut-il supprimer Public-Key-Pins ?

Oui, supprimez à la fois Public-Key-Pins et sa forme report-only. Aucun navigateur actuel ne les traite ; chaque moteur qui a livré HPKP l'a retiré. L'envoyer aujourd'hui n'impose rien, mais il ajoute des octets morts à chaque réponse et signale une configuration de sécurité non maintenue que les scanners et rapports de pentest signalent.

Voir aussi

• Headers hérités couvre les headers de politique qui ont des remplaçants modernes (X-Frame-Options, Feature-Policy, X-XSS-Protection), un ensemble distinct des deux headers TLS morts de cette page
• Vue d'ensemble des headers de sécurité
• Informations divulguées, les autres headers qu'un scan vous dit de retirer : Server, X-Powered-By et le reste des bannières de version
• Strict-Transport-Security, le header de sécurité TLS que vous devriez envoyer
• Scanner de headers de sécurité pour vérifier vos headers déployés

Sources

• RFC 7469, extension de Public Key Pinning pour HTTP
• RFC 9163, extension Expect-CT pour HTTP
• RFC 8659, autorisation d'autorité de certification par DNS (CAA)
• Chrome Platform Status, retrait du HTTP-Based Public Key Pinning
• Chrome Platform Status, entrée de dépréciation d'Expect-CT
• Politique Certificate Transparency de Chrome
• Notes de version Firefox sur le retrait de HPKP
• OWASP, cheat sheet sur l'épinglage