Netcraft在2016年3月的SSL调研中发现，只有不到0.1%的证书用于HPKP响应头。而在实际部署中，三分之一的运维者采用了错误的HPKP配置策略。HPKP部署门槛之高，显而易见。
即使已入门，也需要对维护给予高度重视：无论是常规维护还是实施紧急措施都有可能给合法的访问者带来巨大风险，而且是长期的。但是，只要部署正确、维护妥当，HPKP绝对是一项强大的安全技术。
HPKP防什么？
一个网站可以通过部署HTTPS, HSTS和HSTS preloading预加载抵御大部分中间人攻击。将所有这些技术叠加在一起，可以保证网站通信从发出请求到获得响应都是被加密和授权的。
尽管有这些技术可以有效抵御如pharming和sslstrip之类的攻击，还是有许多攻击正跃跃欲试。一个偏执的攻击者甚至可以通过说服CA为他签发一张伪造的证书，来攻击一个防设“完美”的HTTPS网站。
HPKP可以防止顾客进入持有效假冒证书的钓鱼网站。尽管两个站点都持有可信CA签发的证书，只有真实网站的证书链包含了客户端所期望的证书。浏览器会对每个包涵哈希函数的固定证书进行网站预访问。
虽说让攻击者特地去为一个不由他控制的域名获取一张证书挺难，但也不是不可能。事实上这样的例子发生过很多次。多家证书授权机构被攻破，宽松的策略被发现，技术上的缺陷被攻击者利用。
HPKP响应头的引入就是基于生态系统的证书误发历史。为了使用HPKP，网站运营者必须挑选出一系列的公钥并投入使用。一旦用户访问站点，它的HPKP策略就会被存储在客户端，用来拦截未来所有非白名单的服务器连接。
当HPKP遇上用户计算机的本地流氓根证书，靠一条策略就想要抵御所有仿冒攻击是远远不够的。近日，Dell和Lenovo公司都被曝光在用户计算机内植入根证书，甚至还包含了私钥。攻击者只要有心，就可以利用这点为任何站点生成任何证书，然后仿冒这个网站。而受害者的浏览器会无视站点的HPKP策略，直接把证书当做合法的。
HPKP怎么用？
使用HPKP可以固定三种密钥：
- 网站当前的证书公钥
- 包含CA和中级证书的公钥
- 备份密钥
为了能够使浏览器接受并存储网站的HPKP策略，至少需要两个特定的钉针用于固定。其中一个用于在校验网站证书时固定浏览器信任链，另一个作为后备。
以下这个例子固定了三个不同的公钥（标粗内容）。这条规则有效期为一年，涵盖了所有现域名的子域名：
Public-Key-Pins:
pin-sha256="Q0ig6URMeMsmXgWNXolEtNhPlmK9Jtslf4k0pEPHAWE=";
pin-sha256="F5OSegYUVJeJrc4vjzT38LZtDzrjo7hNIewV27pPrcc=";
pin-sha256="p1Uk2ryJ7QmI5/zIzFmdzme0X+2nvXG5bHwR88A5ZjA=";
max-age=31536000; includeSubDomains
网站运维者必须在固定CA密钥时格外小心。因为CA可能会不经提醒就更改他们的签发机制，新证书可能用的不是之前那条信任链。如果新的证书链不再包含固定密钥，整个网站将在HPKP规则过期之前都无法访问。
为了避免使用CA密钥可能导致的麻烦，可以选择固定自己的密钥。但考虑到备份密钥可能不能用（密钥丢失或者不符合证书的要求（比如，该备份密钥被视作 Debian weak key，CA是不会接受并在新证书中采纳的）），风险也很大。
那谁还敢固定？
如果固定和证书都安排合理，HPKP实现起来可以称得上是完全安全的。但一想到可能出现的问题，HPKP就没那么“安全”了：任何一个细小的问题都会让客户几个月都无法访问到网站，从而毁掉一家网络公司。在诸多最火的站点中，以下敢使用HPKP的都是勇士：
GitHub
GitHub是部署HPKP最频繁的网站。 众所周知，GitHub最注重安全，它配置了太多当今最优秀的安全响应头。
当你访问 https://www.github.com ，其中的一个响应头就是用HPKP布置的：
Public-Key-Pins: max-age=300;
pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18=";
pin-sha256="JbQbUG5JMJUoI6brnx0x3vZF6jilxsapbXGVfjhN8Fg=";
includeSubDomains
这个HPKP策略带有两个固定，该指令适用于所有子域。
第一个固定的密钥（使用了WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18= SHA-256 hash）包含了DigiCert High Assurance EV Root CA。这是github.com现在使用的根信任链。
第二个哈希函数（JbQbUG5JMJUoI6brnx0x3vZF6jilxsapbXGVfjhN8Fg=)是Github的后备固定。它包含了VeriSign Class 3 Public Primary Certification Authority - G5 root。鉴于这个密钥并没有出现在Github的现有证书链上，它被视作后备固定。
当Github希望替换它的TLS证书时，新证书必须是由DigiCert或者Symantec签发的——否则，任何新证书链的密钥都无法与设置好的HPKP规则进行匹配，从而用户会被拉入访问黑名单。
相对于固定Github自己的备份密钥，固定一组根证书密钥风险要更小些，却是一笔更大的“交易”。根据Github现有的HPKP规则，攻击者依旧可以通过获取一张由DigiCert或Symantac签发的伪造证书来仿冒它。相反的，如果Github是依赖于它的备份密钥，那攻击者就只能靠攻破Github的私钥了。
即便如此，Github仍保持警惕——它把HPKP响应头的max-age设到了300。这意味着，浏览器只会在300秒内记住这条规则，由此一旦发生错误，用户也至多只会在五分钟内被拒绝访问。但这种做法也使得安全策略本身显得鸡肋。
在一场攻击中，任何在五分钟之内没访问到真实Github网站www.github.com的访客都会是潜在的受害者。就算他在五分钟之内访问了Github，被拒绝访问也可能只是个小差错。而一个精明的攻击者可以等个五分钟再进入Github，以确保不被发现。
Mozilla
Mozilla正在更有效地采用HPKP并支持到自己的网站上。它设置了更高的max-age响应：
Public-Key-Pins: max-age=1296000;
pin-sha256="r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E="
pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18=";
这个数字相当于15天，也就是说它每两周可以为任何访客提供有效的保护措施。
相较于使用包含不止一个CA的公钥哈希，Mozilla选择了固定单个CA:所有密钥都由DigiCert掌管。从某种角度说，只让一家CA签发新证书固然是安全的，但这导致Mozilla只能用DigiCert。万一DigiCert被迫终止签发，而Mozilla的证书又刚好需要替换，访客将会在15天内被限制访问Mozilla的站点。
Pixabay
pixabay.com的Pixabay图库采用了更大胆的HPKP配置。它的Public-Key-Pins响应头设置的max-age为一年。
Public-Key-Pins:
pin-sha256="Kx1dtEVeqnPn0gfhzqIJfChEYFr5zMe+FjvcJ0AhVgE=";
pin-sha256="zN9pxsvWtHm05/fKZ6zA1NJOq4j2NJJA3oIecCNc1eU=";
max-age=31536000;
相较于固定CA掌管的密钥，Pixabay固定了它自己的证书密钥以及备份密钥。这个做法完全防止了CA泄密带来的问题，但也将风险转嫁到另一方面：万一备份密钥不可用怎么办。
如果Pixabay丢失了所有证书的私钥，那将是灾难性的——访客将在一整年里被拒绝访问。但Pixabay认为这项风险部署是值得的。
为什么只有少量网站敢用HPKP?
在2016年的Netcraft SSL调研中显示，只有0.09%的证书在使用HPKP——这个数字比只有4100张证书由公钥固定响应头传递还要小。
或许有人认为这个数字还低得不够惊人。但事实上，其中超过四分之一的站点都在错误使用HPKP响应头，甚至可以称得上是禁用了HPKP。也就是说，真正在使用HPKP的证书数量低于3000。
依旧处于萌芽期
HPKP没有被广泛部署的一大原因是因为它还只是一项新标准，而且并没有被所有主流浏览器支持。然而，这只是部分解释了它在服务端上不得志的原因。尽管HTTP公钥固定扩展在2015年4月的RFC 7469之前没有正式上线，但由于Chrome 38支持HPKP，从2014年10月开始就有相当比例的网民从这项技术中受益。
2015年1月的时候Firefox 35也支持了HPKP技术，大约四分之一的网民受益于使用HPKP的站点。但在今天，HPKP仍没有被IE, Edge, Safari以及Opera Mini支持。另一方面，成千上万的用户正在使用支持HPKP的浏览器，而之所以他们没能得益于这项技术，是因为只有少部分网站在部署它。
缺乏重视
或许缺乏HPKP部署的最大的原因在于，许多网站运维者缺乏安全意识，又或者并没有意识到它能带来的好处。然而许多网站最主要的问题是缺乏一些最基础的网站设施，比如such as HSTS和“安全”的cookies。如果一个网站连HSTS都不支持，采用HPKP也是多余的，因为中间人攻击者还是可以劫持未加密的HTTP流量、阻止受害者的浏览器转到HTTPS网站。
缺乏理解
Nercraft的SSL调研结果说明了，许多繁琐的错误都是因为网站运营者在部署HPKP响应头的时候缺乏理解能力。这导致了在许多网站上HPKP都不能用。
HPKP是保护网站免于欺诈性证书攻击的最佳途径。但在上文中我们已经讨论到，HPKP的部署结果容易适得其反。一个小小的错误配置所能达到的破坏程度不可置否。
总结
HPKP提供了针对中间人攻击的强大防御，糅合了HTTPS、HSTS以及HSTS预加载技术——虽然优点显而易见，但没什么人去使用。目前只有0.09%的安全网站在使用HPKP响应头。
在部署HPKP时很难发现哪里出错，而任何一个环节出错都足以最终毁掉一个公司（长达数月的网站拒绝访问）。目前只有几千家安全站点接受这项风险。当然你也可以说只有那些备受瞩目的大型网站才会有用HPKP的必要。对那些小型网站而言，HPKP出错引发的灾难要比普通的网站攻击要严重得多：毕竟他们受欺诈性证书攻击的可能性还是非常小的，这种事主要针对大的网站。
还有一个更新的技术叫做Expect CT可能提供更加安全和容易的方式来应对欺诈性证书。采纳这项技术的网站能够让浏览器到Certificate Transparency的日志里查看他们的安全证书。而这些日志是完全透明的，所有域名拥有者、CA和域名用户都可以去验证错误签发的证书；欺诈性证书不会出现在日志列表中，自然在Expect CT这边也就不可信。这些日志的录入主要由CA来完成，同时也减轻了不少网站运营者的负担。
对于那些正确配置HPKP的网站而言，要去攻击他们极难，但也不是不可能。如果浏览器从来没有访问过任何站点，那它仍有可能受到中间人攻击。因为不像HSTS，HPKP没有常规的预加载列表。（或许可以向Google Chrome请求特殊待遇）
SSL信息
