https://scotthelme.co.uk/hpkp-http-public-key-pinning/
https://scotthelme.co.uk/hpkp-toolset/
https://tools.ietf.org/html/rfc7469#page-7
eli5 :
Si le browser reçoit un header "Public-Key-Pins" avec une liste de hash, il va les stocker en local avec le domaine associé (pour un temps donnée par le max-age, la rfc conseille 2 mois)
Firefox les stocke au même endroit que les HSTS : http://security.stackexchange.com/questions/92954/how-can-i-see-which-sites-have-set-the-hsts-flag-in-my-browser
Quand un browser se connecte en https à un site, et qu'il a en local une entrée HPKP, il va y avoir une condition pour que la connexion s'établisse :
Les hashs dans le header qui ne correspondent à rien sont considérés comme des backup.
Si aucun hash de l'entrée HPKP locale ne correspond à aucun hash de clé publique de la chaine : impossible de se connecter.
à partir de là, on peut implémenter comme on veut HPKP, en étant plus ou moins strict.
Par exemple, pour https://infomee.fr, grâce à https://report-uri.io/home/pkp_hash on peut voir les hash des clés publiques de ma chaine de certification :
Leaf : Here is your PKP hash for infomee.fr: pin-sha256="oM+/1421Ew13AzUUxBTNbJjxofRe40CxO2Lt89BUeHk="
Intermediate : Here is your PKP hash for Let's Encrypt Authority X3: pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="
Root : Here is your PKP hash for DST Root CA X3: pin-sha256="Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys="
Si je décide de renvoyer dans le header Public-Key-Pins seulement le hash du root :
Ce qui est déjà bien, mais si cette autorité est corrompue, un certificat frauduleux pourra toujours être utilisé.. C'est là qu'on peut aller plus loin et utiliser l'intermediate seulement ou encore plus loin le leaf seulement
Test :
Pour être top secure mais touchy à config/gérer : pin seulement le leaf (et bien sur un backup)