SSL Pinning与Certificate Transparency选型及弃用状态咨询

关于「SSL Pinning已被弃用」的说法澄清 #

首先明确结论：整个SSL Pinning技术体系从未被弃用，网上的说法属于典型的概念混淆，被主流浏览器（Chrome、Firefox、Safari）陆续下线的只有**基于HTTP响应头实现的HTTP Public Key Pinning（HPKP）**这一个特定的公网Web端标准，和其他场景下的pinning实现没有关系。
两类pinning的实际现状：

• Certificate Pinning（证书绑定）：直接在客户端内置服务端完整叶证书做校验，从来没有被任何标准弃用。只是因为叶证书续期就必须同步更新所有客户端配置，运维成本极高，现在很少在开放公网场景使用，但在封闭内网、高安全专属设备场景一直是常规防护手段。
• PK Pinning（公钥/SPKI绑定）：在客户端内置服务端证书对应的公钥哈希做校验，只要证书续期不更换密钥对就不需要修改客户端配置，运维成本比证书绑定低很多。除了前面提到的浏览器端HPKP实现被弃用之外，在移动端App、IoT设备、自定义客户端场景下的PK Pinning实现，至今是全行业通用的HTTPS防中间人加固手段，不存在任何弃用的说法。

HPKP被浏览器淘汰的核心原因不是技术不安全：一是配置容错率极低，运维一旦配错pin值或者忘记提前备份备用pin，会导致站点长达几个月无法被用户访问；二是随着Certificate Transparency生态成熟，HPKP原本要解决的「CA违规签假证书」问题已经有了更低成本的解决方案，HPKP的投入产出比太低才被下线。

两类方案的适用性对比 #

这两个技术解决的问题域并不完全重叠，没有绝对的“谁更强”，适用场景有明确区分：

• Certificate Transparency（证书透明度，CT）
  • 核心作用：解决公开PKI体系下CA被入侵、违规签发伪造站点证书的问题，要求所有公开信任的SSL证书必须被记录在公开可审计的CT日志中，浏览器会校验证书携带的CT签名证明，没有合法证明的证书会直接拦截连接。
  • 适用场景：面向公众的开放公网Web站点、H5页面是强制标配，目前主流浏览器已经要求所有公网可信证书必须接入CT，不需要站点开发者做额外的客户端改造，CA签发证书时会自动附带CT证明，运维成本几乎为0。
  • 局限性：无法防御用户设备本地安装恶意根证书（比如抓包工具安装的私有根证书）导致的中间人攻击，也不支持私有CA、内网自定义PKI的场景。
• SSL Pinning
  • 核心作用：跳过系统/客户端默认的根证书信任链校验逻辑，只认可客户端提前内置的服务端证书/公钥，哪怕用户设备装了恶意根证书、链路被网络侧劫持，只要中间人拿不出对应私钥就无法建立连接，防中间人攻击的强度远高于CT。
  • 适用场景：高安全要求的自有移动端App、IoT设备、内网业务系统、封闭生态客户端，目前银行、支付类App几乎全部内置了SSL Pinning逻辑，用来防恶意抓包、流量篡改。
  • 局限性：运维成本更高，服务端轮换密钥/证书时必须同步推送客户端更新，完全不适合开放公网Web场景——你不可能提前让所有访问你网站的用户在浏览器里存你绑定的公钥信息。

选型建议 #

• 如果你要防护的是面向普通公众访问的公开Web站点：直接选CT即可，不要尝试在公网Web场景配置Pinning，尤其是已经被弃用的HPKP响应头，配置失误很容易导致全站无法访问。
• 如果你要防护的是自有可控的客户端（自研App、IoT设备、内网专属客户端）：建议两者搭配使用，公网证书开启CT校验的同时，在客户端内置PK Pinning（优先选公钥绑定而非完整证书绑定，降低证书续期的运维成本），最大化防护能力。
• 如果是纯内网场景用私有CA签发证书：直接选SSL Pinning即可，CT本身不覆盖私有PKI场景，没有部署价值。

内容的提问来源于stack exchange，提问作者Eman Darwish