数字签名与证书|HTTP协议篇
# 数字签名与证书
30 秒速记
- 仅有加密只能保障机密性，不能证明密文未被篡改，也不能证明通信对象真实可信。
- 攻击者即使不知道会话密钥，仍可能截获、修改或重放密文，并利用服务端响应继续分析。
- 如果公钥本身被攻击者替换，客户端会把敏感数据加密给错误对象，混合加密随即失去保护作用。
- 完整的安全通信至少需要同时解决机密性、完整性和身份认证；数字签名与证书主要补足后两项能力。
- 证书要解决的是公钥与真实身份之间的可信绑定，而不是提升加密算法本身的强度。
数字签名用来验证内容和发送者，证书则负责把公钥与真实身份可信地绑定起来。 只做加密只能防止别人读懂数据，攻击者仍可能篡改密文，甚至替换公钥，让客户端把敏感信息加密给错误对象。比如浏览器访问 HTTPS 站点时，会检查证书链、有效期、域名和用途，再决定是否信任站点公钥。证书不保证网站业务诚实，签名也不隐藏内容，私钥保护和终端信任库同样重要。
黑客虽然拿不到会话密钥，无法破解密文，但可以通过窃听收集到足够多的密文，再尝试着修改、重组后发给网站。因为没有完整性保证，服务器只能“照单全收”，然后他就可以通过服务器的响应获取进一步的线索，最终就会破解出明文。
另外，黑客也可以伪造身份发布公钥。如果你拿到了假的公钥，混合加密就完全失效了。你以为自己是在和“某宝”通信，实际上网线的另一端却是黑客，银行卡号、密码等敏感信息就在“安全”的通信过程中被窃取了。
所以，在机密性的基础上还必须加上完整性、身份认证等特性，才能实现真正的安全。
原理拆解： 机密性回答“旁观者能否读懂”，完整性回答“内容是否被改动”，身份认证回答“对端究竟是谁”。仅把数据加密并不会自动覆盖后两项：若使用缺少认证能力的加密方式，攻击者可能修改密文，使解密结果发生可预测或不可预测的变化；若客户端拿到的是攻击者替换后的公钥，则加密过程虽然数学上正确，密文却只能由攻击者解开。重放还说明完整性并不等于新鲜性，协议通常需要序号、随机数或时效信息共同约束。
具体实现： 数字签名通常先对消息计算摘要，再由私钥产生签名；验证方用公钥检查签名，可发现内容变化并确认签名者掌握对应私钥。证书则由受信任的 CA 对主体信息、公钥、有效期和用途等内容签名，把公钥绑定到域名或其他身份。浏览器访问 HTTPS 站点时，会验证证书链、有效期、域名匹配和用途，然后才把证书公钥视为该站点可信密钥。
边界与反例： 签名不负责隐藏消息，公开的签名数据仍可被读取；证书也不保证网站业务诚实，只证明某个公钥与经验证的身份标识存在可信绑定。攻击者若控制受信任私钥、终端信任库或合法站点本身，证书校验仍可能通过，因此私钥保护、吊销机制和终端安全同样重要。现代安全协议一般使用带认证的加密模式，同时提供机密性与消息完整性，但它仍不能替代证书承担的身份绑定。
工程验证： 可在浏览器开发者工具的安全面板查看证书主题、签发者、有效期和证书链，并对比地址栏域名。测试环境中分别访问过期证书、域名不匹配证书和自签名证书，预期浏览器均给出不同的信任错误。若证书显示正常却仍怀疑被代理，应继续检查证书指纹、系统信任库是否新增根证书，以及代理设备是否重新签发了站点证书。
面试官追问
追问 1支付接口已把请求体加密，攻击者虽然看不懂内容，却能修改密文并观察服务器响应；研发据此声称机密性已经足够，你会认可吗？
不会，机密性只解决旁观者能否读懂，并不保证密文未被修改或对端身份可信。缺少认证能力的加密可能使解密结果发生变化，还可能形成响应侧信道；协议仍需完整性保护和身份认证，并根据威胁模型补充防重放措施。
追问 2前端从登录接口返回值中读取一个公钥后立即加密密码，代码没有验证证书或公钥来源；上线评审时你最担心什么？
最危险的是攻击者替换接口返回的公钥，让加密过程在数学上完全正确，却只能由攻击者解密。客户端应通过可信证书链把公钥绑定到目标域名，并检查有效期、域名匹配和用途；仅看到一个格式合法的公钥不足以确认对端身份。
追问 3文件签名平台要求“签名后任何人都不能看到原文”，并准备删除原有加密模块；这个需求与方案是否匹配？
不匹配，数字签名用于发现内容变化并证明签名方掌握对应私钥，不负责隐藏消息。公开的原文和签名仍可被读取；若业务同时要求保密，应保留适当的加密保护，并分别处理密钥机密性和签名私钥安全。
追问 4测试环境证书显示“有效”，但浏览器访问 api.example.com 仍提示身份不可信；你会按什么顺序排查？
不能只看有效期，应继续核对证书主题或扩展名是否匹配 api.example.com、证书链是否能到达受信任根，以及证书用途是否适合该连接。若仍怀疑被代理，再比对证书指纹、系统信任库新增根证书和代理是否重新签发站点证书。
追问 5安全团队建议把“证书校验通过”直接解释为“该商城业务绝对可信”，产品准备据此移除风控提示；你会同意吗？
不会，证书只证明某个公钥与经验证的域名或其他身份标识存在可信绑定，不保证网站经营行为诚实。合法站点被入侵、私钥失窃或终端信任库被控制时，校验仍可能通过；业务风控和终端安全不能由证书替代。
追问 6订单接口对每个请求都做了签名，但同一份合法密文可被重复提交并造成重复扣款；为什么完整性校验没有拦住它？
签名能证明内容未变并验证私钥持有者，却不自动证明请求是本次新产生的。协议或业务层还需使用序号、随机数、时效信息或幂等标识约束重放；具体组合取决于系统威胁模型，不能把签名成功等同于请求新鲜。
# 摘要算法
30 秒速记
- 摘要算法把任意长度输入映射为固定长度结果，主要用于识别数据是否发生变化，不负责恢复原文。
- 它不使用解密密钥，计算方向具有单向性；输入发生细微变化时，输出通常会显著改变。
- 由于输出空间有限，不同输入理论上可能产生相同摘要，因此安全性关键在于抗碰撞能力，而不是绝对不存在碰撞。
- 摘要长度由算法决定：题干给出的
MD5、SHA-1、SHA-256分别输出16、20、32字节。 - 按题干所述的
TLS语境，MD5与SHA-1安全强度不足，应使用SHA-2系列；具体可用算法仍需以实际TLS版本和实现配置为准。
摘要算法会把任意长度的数据映射成固定长度的摘要，用于判断内容是否发生变化，不能用来还原原文。 它没有解密密钥，并具有单向性和雪崩效应，输入只改一点，输出通常也会明显不同。由于这是从大空间映射到小空间，碰撞在理论上无法避免，所以工程上看重的是抗碰撞能力。MD5、SHA-1 的安全强度不足，实际使用哪种 SHA-2 算法还要结合具体 TLS 版本和配置。
实现完整性的手段主要是摘要算法（Digest Algorithm），也就是常说的散列函数、哈希函数（Hash Function）。
你可以把摘要算法近似地理解成一种特殊的压缩算法，它能够把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”。
换一个角度，也可以把摘要算法理解成特殊的“单向”加密算法，它只有算法，没有密钥，加密后的数据无法解密，不能从摘要逆推出原文
摘要算法实际上是把数据从一个“大空间”映射到了“小空间”，所以就存在“冲突”（collision，也叫碰撞）的可能性，就如同现实中的指纹一样，可能会有两份不同的原文对应相同的摘要。好的摘要算法必须能够“抵抗冲突”，让这种可能性尽量地小。
因为摘要算法对输入具有“单向性”和“雪崩效应”，输入的微小不同会导致输出的剧烈变化，所以也被 TLS 用来生成伪随机数（PRF，pseudo random function）。
你一定在日常工作中听过、或者用过 MD5（Message-Digest 5）、SHA-1（Secure Hash Algorithm 1），它们就是最常用的两个摘要算法，能够生成 16 字节和 20 字节长度的数字摘要。但这两个算法的安全强度比较低，不够安全，在 TLS 里已经被禁止使用了。
目前 TLS 推荐使用的是 SHA-1 的后继者：SHA-2。
SHA-2 实际上是一系列摘要算法的统称，总共有 6 种，常用的有 SHA224、SHA256、SHA384，分别能够生成 28 字节、32 字节、48 字节的摘要。
你可以用实验环境的 URI“/25-1”来测试一下 TLS 里的各种摘要算法，包括 MD5、SHA-1 和 SHA-2
https://www.chrono.com/25-1?algo=md5
https://www.chrono.com/25-1?algo=sha1
https://www.chrono.com/25-1?algo=sha256
面试官追问
追问 1素材平台保存了上百万文件，后端把 MD5 相同直接当成内容绝对相同并合并存储；你会批准这条去重规则吗？
不能把摘要相同视为数学意义上的内容必然相同，因为任意长度数据映射到固定长度空间必然存在碰撞。若误合并会造成安全或高价值数据损失，应改用更强摘要，并在关键路径增加长度、元数据或原始内容校验，代价是额外计算与存储。
追问 2发布流水线要校验配置包是否被改动，开发只保存一份 SHA-256 并在下载后重新计算；这能定位具体改了哪一行吗？
它适合判断输入是否发生变化，但不能指出具体修改位置。摘要的雪崩效应会让一个字符变化引起输出显著不同；若需要定位差异，还应保留版本、清单或逐文件摘要，而不能从最终摘要反推出变更内容。
追问 3客服系统计划只存用户留言的 SHA-256，半年后再从摘要恢复原文用于审计；这套数据设计能实现吗？
不能，摘要是无密钥的单向映射，会把大输入空间压缩到固定长度空间，无法可靠逆推出原文。需要恢复内容时应保存受控的原文或采用可解密方案；摘要可用于变更校验，但不能同时承担可恢复存储。
追问 4TLS 配置扫描发现仍使用 MD5 或 SHA-1 相关摘要，负责人以“输出长度固定且已有多年代码”为由拒绝调整；你会怎样评审？
不能以接口稳定替代安全强度评估，来源明确指出 MD5 和 SHA-1 安全强度较低，在 TLS 中已被禁止使用。应检查实际协商和签名配置，迁移到 SHA-2 系列；迁移前还要确认上下游兼容性，不能只替换字符串名称。
追问 5线上上传校验偶发不一致，业务文件肉眼看起来相同，但两端计算出的 SHA-256 完全不同；你会先查哪些输入差异？
先确认两端计算的是完全相同的字节序列，包括编码、换行、序列化结果和传输过程中是否发生转换。摘要具有雪崩效应，极小的字节差异也会产生显著不同的结果；若输入字节一致仍不匹配，再核对算法和输出编码实现。
追问 6接口防篡改方案把请求体的 SHA-256 摘要与请求一起明文发送，团队认为攻击者无法逆推原文，所以完整性已经成立；这个取舍可靠吗？
不可靠，单向性只限制由摘要恢复原文，并不阻止攻击者修改请求后重新计算一个新摘要。需要把完整性校验与攻击者无法伪造的认证机制结合，例如由可信密钥参与签名或认证；具体协议选择超出摘要本身能力，不能靠公开摘要独立完成。
# 完整性
30 秒速记
- 发送方计算消息摘要，接收方对收到的消息重新计算并比对，可以检测传输内容是否发生变化。
- 单独附加公开摘要不能抵抗主动攻击：攻击者修改明文后，也能重新计算并替换摘要。
- 完整性校验要具备抗伪造能力，必须引入攻击者不知道的秘密，而不只是选择一种哈希算法。
- 题干中的方案是在受保护通信中结合会话密钥处理消息与摘要，并将相关机制称为
HMAC。 - 完整性只回答内容是否被改动，不等同于机密性，也不天然完成通信主体的身份认证。
完整性校验用于发现消息是否被改动，但只在原文后附一个公开摘要并不能抵抗主动攻击。 接收方可以重新计算摘要并比对，可攻击者若能同时修改明文和摘要，校验结果依然会一致。本质上还要引入攻击者不知道的秘密，例如结合会话密钥构造 HMAC，让对方无法伪造合法校验值。完整性不等于机密性，也不能单独证明通信对象的真实身份。
