SSL信息HTTP公钥固定（HPKP，见RFC7469）——一个给大家用来固定公钥的标准——也许已经死了。作为一个完全加密的、可靠的互联网支持者，我非常期待HPKP取得成功，但我担心它用起来太困难，也太危险，而且如果没有我们的维护，它什么也做不了。
什么是公钥固定？
在我继续讲之前，先简单讨论一下我们为什么首先需要的是公钥固定。这个问题是伴随我们的信任机制的管理方式而来的：我们有数百个证书管理机构，每个都能为世界上任何一个网站颁发证书。从技术上来说，这并不需要网站所有者的许可。我认为这一体系实际上运行地相当不错，是因为异常事件的发生率很低。但虚假证书仍能通过这样那样的方式被制造出来，这对那些知名度很高的网站来说就不太妙了。同时，对于专业人员来说，依赖一个并不十分稳固的系统是一件很令人头痛的事情。
说到公钥固定，网站所有者们是有发言权的，依靠这项技术，他们能够确保证书是有效的。例如，在可供选择的证书中，你选中两个或更多的证书管理机构，然后把其他机构颁发的证书全部忽略。有什么理由不去喜欢这种方式呢？
公钥固定技术始于谷歌，他们首先把这一技术用来将Chrome浏览器和他们自己的网站固定。这是一种静态固定方式；由于pin嵌入浏览器中，所以不容易修改。Chrome浏览器的固定为我们服务了很多年，也揭露了很多本来可能瞒天过海的虚假证书。谷歌以前（现在仍然）允许其他机构将他们的pin嵌入Chrome浏览器。现在，火狐浏览器也支持静态固定，而这来自通过谷歌维护的相同的pin。
尽管静态固定技术运行很好，但由于pin需要手动维护且很费时间，所以这项技术还存在一些问题。为此，谷歌发起成立了IETF，从而产生了RFC7469，它被正式称作“HTTP公钥固定扩展”，但大家喜欢叫HPKP。HPKP是一个动态固定的范例；网站所有者们可以随意设置pin。
那么HPKP的问题到底是什么？
HPKP的主要问题，或者说固定技术的主要问题，是它会堵住网站。罪魁祸首是记忆效应：pin一旦设置好，会在一段时间内持续有效。每个pin都与网站赖以继续运行的唯一的加密身份标识相关联。如果你失去了对这个身份标识的控制，那你也就失去了你的网站。
很明显，固定技术引入了一个范式转移。相对而言，不支持该技术的TLS是十分宽容的——假如你丢掉密钥，还能创建一个新的，并为其配备一个全新的证书。而在引入固定技术后，你的密钥就变得弥足珍贵了。
稍微令人感到安慰的是，一个有效HPKP设置必须包含至少一个备份密钥。这其中的理念是，如果你遇到了严重的问题，你还可以取出此前安全保存下来的备份密钥来继续进行正常操作。
即使你没丢掉固定的密钥，对于何时、怎样更换它，你也必须小心谨慎。在任何时候，你的设置都必须提供至少一个与你提供给此前所有用户的设置相匹配的pin码。如果你变换密钥过于频繁的话，那么你可能会失去一些老的访客。
总之，HPKP不是为胆小鬼准备的；你必须知道自己在干什么并且要小心谨慎。
谈到这个，HPKP其实是非常灵活的，你可以用它做很多事。你可以用它把任何一个公钥固定在证书链中，从你自己的密钥（叶证书）、中级证书或根证书中选择。每个决定都有其优势和劣势，而你需要很好地理解PKI，才能正确鉴别它们。这种灵活性很容易产生混乱，实际上这经常导致系统瘫痪（也就是不知道该“干什么”）。一些网站会不可避免地做出错误选择因而遇到麻烦。
因此，一个成功的固定策略要求如下：
- 建立一个威胁模型，确定固定时是否会造成实际的威胁，应付这个威胁的成本是否可以接受；
- 理解PKI和HPKP，选择正确的位置进行固定；
- 不要丢失固定的密钥；
- 在服务器遇到威胁时隔离保存备份密钥；
- 更换密钥要有充分稳固的计划。
以上步骤执行起来并不太困难，但好处却很大。固定时出现严重错误会导致业务中断。部署的数量反映了这个情况；2016年8月，Scott Helme发现只有375个网站部署了HPKP，76个网站的HPKP仅仅在报告模式运行。与其形成鲜明对比的是，在相同样本中有30000个网站部署HSTS。
HPKP被滥用
HPKP的一个潜在的更大问题是，它会被恶意的活动者滥用。比如说，有人侵入你的服务器（这太平常了）并获得了你的网站控制权。那样他们就能偷偷地激活HPKP，然后对你的大量用户数据库执行固定命令。你很难监测到他们。等到很久以后，他们把固定的密钥从服务器中移除然后仅仅为了找乐子把你的网站堵住。或者，如果你幸运的话，他们会给你机会从他们那里得到备份的固定密钥来保持你的业务正常运转，然后以此来敲诈你。
HPKP工作组早就知道这个问题，但在标准中并未加入缓解机制。早期HPKP方案指定了一个持续上升期：固定行为必须在一段时间内被观察到并变得充分起作用。这一特性最终被删除，这很可能是因为很难清楚有效地判断这一现象的持续性。最后，RFC规定，一个活动pin和一个非活动（备份）pin在任何一段时间内都足以激活固定行为。RFC中“敌对固定行为”一节对此问题几乎是一带而过，文档中指出网站应当能够在最大策略持续期结束以后恢复。RFC让浏览器来决定他们的生存期的最大值，并给出一个非常温和的建议，60天。
所谓由于HPKP才刚刚产生。尽管我们还没看到这类攻击，但却已经发生。就在这个月，在DEFCON大会上就有一次关于RansomPKP的讨论。
那为什么我说HPKP死了？
我认为，HPKP在部署和维护过程中需要太多的工作，以至于只有少数网站会部署它。而与此同时，它却可以——以目前的形式——被当作攻击每个人的有力武器。
讽刺的是，对于HPKP来说，不会有很多网站使用它（因为这太费劲），但它却可以被用来攻击那些数以百万计的小型网站。这些网站甚至还没意识到HPKP的存在。对少数正在使用固定技术的网站来说，静态固定技术却很可能工作地很好，异常情况很少，并且对互联网的其他部分没有危险。
HPKP能被修复吗？
为了修复HPKP我们需要1）让它的部署更简单且更安全；2）有办法对付潜在的恶意使用。
对于后者来说，一种可能性是让HPKP变得不那么敏感，这样它仍然有用，但有威胁的一面也被处理成没威胁的部分了。有很多种方法可以做到这一点。例如，我们可以重新引入上升期机制。另一个解决方法可以是对那些具有一定安全知识和熟悉业务的人运营的网站的固定行为进行限制，例如那些已经预先加载HSTS的网站。也许浏览器也可以建立一种撤销机制用来对付坏掉的pin码。
让HPKP更易用很可能意味着允许网站部署更安全的固定，例如固定到证书管理机构而不是他们的根证书。实际上，这正是目前大量静态固定所采取的办法。它是这样运行的：你选出2-3个证书管理机构并指定只有他们可以为你的网站颁发有效证书。这种方法并不像固定到页证书（你自己的密钥）那么安全，但它大大减少了攻击面，并降低了工作量。（在HPKP的开发过程曾讨论过这一理念。但因为这并不是一个纯技术解决方案，而且需要多个机构协作，所以这一理念被否决了。）
从技术上看，假如你对PKI有很深的理解，那么固定到证书管理机构是可行的。关键问题在于理解不同的根存储怎样包含不同的根密钥，根密钥怎样更改，等等。我希望我们可以依靠更多的公共信息，在一些感兴趣的证书管理机构的帮助下，在不对HPKP做出任何改变的情况下，让这种更安全的固定方式变为可能。
那么现在你能做些什么？
抛开未来的诸多可能性，让我们试着想想今天能做些什么。下面是可以让你更安全的一些想法：
- 首先，你可以在适当位置建立一个监视系统，来检查你的配置并监测有害固定行为。对大企业来说，不管怎样这很可能是个好主意，因为固定（以及其他安全技术）可能仅由一个开发人员部署，并未在整个企业范围内得到充分协调。（例如，HPKP和HSTS都有记忆效应，也都支持includeSubDomains指令 ，这会对整个域名进行配置，甚至包括其他团队管理的服务器。）
- 你可以为你的网站配置一个反向代理服务器，却不把HPKP响应头发送到你的用户。这种防御措施并不能处理所有可能的攻击（如有人将网站重定向到其他服务器并使用一个错误颁发的证书），但会减少服务器被接管的可能。
- 如果你不介意自己受到约束，固定行为本身也可以是一个对付恶意固定的有效防御手段。如果你已经使用了固定技术，包括DNS劫持和虚假证书在内的所有攻击都会被监测到。不幸的是，一个通过入侵你的服务器控制了你的pin的人，可以把pin变换为他们已控制的。（而在那个例子中，前一个控制，也就是反向代理服务器会有帮助。）
感谢Ryan Sleevi和Scott Helme 阅读这个帖子的初稿。本文由Ivan Ristic2016年9月6日发表于SSL Labs。
相关阅读：安全网站回避HTTP公钥固定？！