HTTPS的应用层协议
HTTPS的应用层协议
方案 5 - 非对称加密 + 对称加密 + 证书认证
在客户端和服务器刚一建⽴连接的时候, 服务器给客户端返回一个 证书，证书包含了之前服务端的公钥, 也包含了网站的身份信息.
客户端进行认证
当客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的).
• 判定证书的有效期是否过期
• 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
• 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的
中间人有没有可能篡改该证书？
• 中间人篡改了证书的明文
• 由于他没有 CA 机构的私钥，所以无法 hash 之后用私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名
• 如果强行篡改，客户端收到该证书后会发现明文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人
中间人整个掉包证书？
• 因为中间人没有 CA 私钥，所以无法制作假的证书(为什么？)
• 所以中间人只能向 CA 申请真证书，然后用自己申请的证书进行掉包
• 这个确实能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能够识别出来。
• 永远记住：中间人没有 CA 私钥，所以对任何证书都无法进行合法修改，包括自己的
常见问题
为什么摘要内容在网络传输的时候一定要加密形成签名?
常见的摘要算法有: MD5 和 SHA 系列
以 MD5 为例, 我们不需要研究具体的计算签名的过程, 只需要了解 MD5 的特点:
• 定⻓: 无论多⻓的字符串, 计算出来的 MD5 值都是固定⻓度 (16 字节版本或者32 字节版本)
• 分散: 源字符串只要改变一点点, 最终得到的 MD5 值都会差别很大.
• 不可逆: 通过源字符串生成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的.
正因为 MD5 有这样的特性, 我们可以认为如果两个字符串的 MD5 值相同,则认为这两个字符串相同.
理解判定证书篡改的过程: (这个过程就好比判定这个身份证是不是伪造的身份证)
假设我们的证书只是一个简单的字符串 hello, 对这个字符串计算 hash 值(比如 md5), 结果为 BC4B2A76B9719D91
如果 hello 中有任意的字符被篡改了, 比如变成了 hella, 那么计算的 md5 值就会变化很大. BDBD6F9CF51F2FD8
然后我们可以把这个字符串 hello 和 哈希值 BC4B2A76B9719D91 从服务器返回给客户端, 此时客户端如何验证 hello 是否是被篡改过?
那么就只要计算 hello 的哈希值, 看看是不是 BC4B2A76B9719D91 即可.
所以被传输的哈希值不能传输明文, 需要传输密文.
所以，对证书明文(这里就是“hello”)hash 形成散列摘要，然后 CA 使用自己的私钥加密形成签名，将 hello 和加密的签名合起来形成 CA 证书，颁发给服务端，当客户端请求的时候，就发送给客户端，中间人截获了，因为没有 CA 私钥，就无法更改或者整体掉包，就能安全的证明，证书的合法性。最后，客户端通过操作系统里已经存的了的证书发布机构的公钥进行解密, 还原出原始的哈希值, 再进行校验.
为什么签名不直接加密，而是要先 hash 形成摘要?
• 缩⼩签名密文的⻓度,加快数字签名的验证签名的运算速度
总结
HTTPS 工作过程中涉及到的密钥有三组.
第一组(非对称加密): 用于校验证书是否被篡改. 服务器持有私钥(私钥在形成 CSR 文件与申请证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器在客户端请求时，返回携带签名的证书. 客户端通过这个公钥进行证书验证, 保证证书的合法性，进一步保证证书中携带的服务端公钥权威性。
第⼆组(非对称加密): 用于协商生成对称加密的密钥. 客户端用收到的 CA 证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.
第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密. 其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的. 第⼆组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器. 第一组非对称加密的密钥是为了让客户端拿到第⼆组非对称加密的公钥