目前 TLS 推荐使用的是 SHA-1 的后继者：SHA-2 。
SHA-2 实际上是一系列摘要算法的统称 ， 总共有 6 种 ， 常用的有 SHA224、SHA256、SHA384 ， 分别能够生成 28 字节、32 字节、48 字节的摘要 。
完整性摘要算法保证了“数字摘要”和原文是完全等价的 。 所以 ， 我们只要在原文后附上它的摘要 ， 就能够保证数据的完整性 。
比如 ， 你发了条消息：“转账 1000 元” ， 然后再加上一个 SHA-2 的摘要 。 网站收到后也计算一下消息的摘要 ， 把这两份“指纹”做个对比 ， 如果一致 ， 就说明消息是完整可信的 ， 没有被修改 。
如果黑客在中间哪怕改动了一个标点符号 ， 摘要也会完全不同 ， 网站计算比对就会发现消息被窜改 ， 是不可信的 。
不过摘要算法不具有机密性 ， 如果明文传输 ， 那么黑客可以修改消息后把摘要也一起改了 ， 网站还是鉴别不出完整性 。
所以 ， 真正的完整性必须要建立在机密性之上 ， 在混合加密系统里用会话密钥加密消息和摘要 ， 这样黑客无法得知明文 ， 也就没有办法动手脚了 。
这有个术语 ， 叫哈希消息认证码（HMAC） 。
文章插图
数字签名加密算法结合摘要算法 ， 我们的通信过程可以说是比较安全了 。 但这里还有漏洞 ， 就是通信的两个端点（endpoint） 。
就像一开始所说的 ， 黑客可以伪装成网站来窃取信息 。 而反过来 ， 他也可以伪装成你 ， 向网站发送支付、转账等消息 ， 网站没有办法确认你的身份 ， 钱可能就这么被偷走了 。
现实生活中 ， 解决身份认证的手段是签名和印章 ， 只要在纸上写下签名或者盖个章 ， 就能够证明这份文件确实是由本人而不是其他人发出的 。
在这里 ， 使用非对称加密里的“私钥”再加上摘要算法 ， 就能够实现“数字签名” ， 同时实现“身份认证”和“不可否认” 。
数字签名的原理其实很简单 ， 就是把公钥私钥的用法反过来 ， 之前是公钥加密、私钥解密 ， 现在是私钥加密、公钥解密 。
但又因为非对称加密效率太低 ， 所以私钥只加密原文的摘要 ， 这样运算量就小的多 ， 而且得到的数字签名也很小 ， 方便保管和传输 。
签名和公钥一样完全公开 ， 任何人都可以获取 。 但这个签名只有用私钥对应的公钥才能解开 ， 拿到摘要后 ， 再比对原文验证完整性 ， 就可以像签署文件一样证明消息确实是你发的 。
文章插图
刚才的这两个行为也有专用术语 ， 叫做“签名”和“验签” 。
只要你和网站互相交换公钥 ， 就可以用“签名”和“验签”来确认消息的真实性 ， 因为私钥保密 ， 黑客不能伪造签名 ， 就能够保证通信双方的身份 。
比如 ， 你用自己的私钥签名一个消息“我是小明” 。 网站收到后用你的公钥验签 ， 确认身份没问题 ， 于是也用它的私钥签名消息“我是某宝” 。 你收到后再用它的公钥验一下 ， 也没问题 ， 这样你和网站就都知道对方不是假冒的 ， 后面就可以用混合加密进行安全通信了 。
数字证书和 CA到现在 ， 综合使用对称加密、非对称加密和摘要算法 ， 是不是已经完美了呢？
不是的 ， 这里还有一个“公钥的信任”问题 。 因为谁都可以发布公钥 ， 我们还缺少防止黑客伪造公钥的手段 ， 也就是说 ， 怎么来判断这个公钥就是你或者某宝的公钥呢？
真是“按下葫芦又起了瓢” ， 安全还真是个麻烦事啊 ， “一环套一环”的 。
我们可以用类似密钥交换的方法来解决公钥认证问题 ， 用别的私钥来给公钥签名 ， 显然 ， 这又会陷入“无穷递归” 。 但这次实在是“没招”了 ， 要终结这个“死循环” ， 就必须引入“外力” ， 找一个公认的可信第三方 ， 让它作为“信任的起点 ， 递归的终点” ， 构建起公钥的信任链 。
这个“第三方”就是我们常说的 CA（Certificate Authority ， 证书认证机构） 。 它就像网络世界里的公安局、教育部、公证中心 ， 具有极高的可信度 ， 由它来给各个公钥签名 ， 用自身的信誉来保证公钥无法伪造 ， 是可信的 。 CA 对公钥的签名认证也是有格式的 ， 不是简单地把公钥绑定在持有者身份上就完事了 ， 还要包含序列号、用途、颁发者、有效时间等等 ， 把这些打成一个包再签名 ， 完整地证明公钥关联的各种信息 ， 形成“数字证书”（Certificate） 。
知名的 CA 全世界就那么几家 ， 比如 DigiCert、VeriSign、Entrust、Let’s Encrypt 等 ， 它们签发的证书分 DV、OV、EV 三种 ， 区别在于可信程度 。

稿源：(未知)

【傻大方】网址：http://www.shadafang.com/c/111J2Hc2020.html

标题：深入浅出 HTTPS (详解版)( 三 )