公钥SSL固定的安全性及Android端动态公钥固定技术咨询

一、公钥固定的有效性 #

公钥固定（Pinning）是抵御中间人攻击（MITM）的有效手段，核心逻辑是跳过系统默认的CA信任链校验，直接验证服务器公钥是否匹配预定义的可信公钥/公钥哈希：

• 能有效拦截伪造CA证书、劫持合法CA证书的攻击场景——这类攻击能绕过系统CA信任，但无法生成匹配固定公钥的有效签名证书。
• 局限性：若服务器私钥泄露，攻击者可利用对应公钥发起攻击，但这属于服务器端的安全事故，并非公钥固定方案本身的缺陷。

二、公钥可公开获取，为何仍安全？ #

公钥本身就是公开的，公钥固定的安全核心不在于“隐藏公钥”，而在于限制APP仅信任特定的公钥集合：

• 攻击者即便获取目标域名的公钥，也无法拿到对应的私钥来生成可通过校验的服务器响应——私钥是服务器的核心机密，只要私钥未泄露，中间人就无法伪造出匹配固定公钥的有效证书链。
• 实际落地时，建议固定公钥的哈希值（如SHA-256哈希），而非明文公钥：一方面减少配置体积，另一方面避免明文公钥传输或存储时的篡改风险。

三、动态SSL固定方案（替代静态network_security_config） #

静态network_security_config的痛点是证书续期后必须强制更新APP，动态方案则通过从可信渠道动态更新可信公钥列表，实现无缝适配证书续期，常见实现思路如下：

1. 内置备用锚点+后台可控更新 #

• 初始化时，在APP内置1-2个长期有效的公钥哈希（比如服务器的备用长期公钥，或签发证书的根CA公钥）作为“信任锚”。
• APP启动后，从后端接口获取当前有效的公钥哈希列表（接口响应需用内置信任锚的公钥签名，防止篡改）。
• 服务器公钥校验逻辑：只要匹配内置锚点或后台返回的任意哈希，就允许连接。
• 证书续期时，后端先将新公钥哈希加入列表，待旧证书过期后再移除，用户无需更新APP即可自动适配。

2. 基于证书透明度（CT）日志的动态校验 #

• 从公开的CT日志中拉取目标域名的所有有效证书，提取公钥哈希并筛选出当前可信的条目，更新本地允许列表。
• 优势：无需自建后端维护公钥列表，依赖行业通用的CT日志体系；需注意验证CT日志的签名，确保日志内容未被篡改。
• 适配场景：适合依赖公共CA签发证书、且希望减少后端维护成本的应用。

3. 本地安全存储+增量更新 #

• 首次启动时，用内置初始公钥哈希校验服务器，校验通过后从服务器获取完整的可信公钥哈希列表，存储到Android Keystore等安全存储区域（防止被恶意篡改）。
• 后续定期向服务器请求增量更新（仅返回新增/移除的哈希条目），更新本地列表；更新请求的响应必须用已信任的公钥签名，保障更新过程安全。

四、动态方案的关键注意事项 #

• 必须保留至少一个长期有效的内置公钥锚点：防止所有动态更新的公钥失效时，APP彻底无法连接服务器。
• 公钥列表的存储要安全：优先使用Android Keystore，避免存储在普通SharedPreferences或文件中被篡改。
• 设置过渡周期：新旧公钥同时生效一段时间（如30天），避免服务器切换公钥后，未及时获取更新的旧版本APP无法连接。

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