HTTPS 深入浅出 - 摘要、MAC 、数字签名到 CA 证书

本文目录：

这是一个从弱到强的过程，对数据安全的功力，从一个普通扫地僧到武林至尊的过程。

我们来逐步推进这个过程：

1. 摘要

首先，我们想要确认一段文本的完整性。于是用上 MD5 或者 SHA 算法，从一段文本中摘要出一段信息附在文本后面。使用文本的期间，可以用同样的摘要算法，摘要出相关信息和之前摘要的信息比较一下。因为摘要算法摘要出来的信息冲突概率小到几乎可以忽略不计，所以可以认为，文本是完整的。

2. MAC

但是，如果文本在网络上传输，被人拦截了，而对方也知道摘要算法，重新摘要后再附在文本后面再发给我们，客户端不就发现不了这个文本是被篡改的？

这时候 MAC 就派上用场，MAC 使用对称密钥技术，比如 DES 算法，对上面的摘要进行加密。服务端和客户端都协商好的对称密钥进行加解密，因为只有对方持有密钥，所以我们可以认为这个文本来源是可靠的。

3. 数字签名

但是这个还有个疑问，怎么确保这个密钥真的只有服务端和客户端持有？这个对称密钥如何通知服务端和客户端？如果直接明文传输密钥，中途还是有被中间人拦截的可能。

于是，我们使用数字签名。和 MAC 比较，数字签名对摘要采用的是非对称密钥加密技术。加密方式为私钥加密，公钥解密，公钥公开，被拦截了也没关系。然后因为只有服务端才有私钥，所以如果解密并且验证摘要成功，那么就可以确定文本来源可靠。

数字签名就像一个人的指纹，也可以称为文件指纹，具有唯一性。

客户端拿到信息和服务端的签名。也用相同的摘要算法获取摘要，然后用公钥解开数字签名作比较，摘要信息一样就可以确认服务端的身份，也可以确认数据中途没有被篡改过。

4. CA 证书

但是大魔王中间人又来了，如果中间人拦截服务端传递过来的公钥，换成自己的公钥，那么文本还是有可能被篡改。我们怎么保证公钥是服务端传过来的？

这个时候，CA 证书就派上了用场。服务端公钥证书通过证书中心 “Certificate authority”，也叫做 CA 的地方进行认证，证书中心用自己的私钥，对服务端的公钥和一些信息再进行一次数字签名，发送给客户端。然后只要客户端信任这些 CA 证书机构，拿出来验证一下服务端的公钥证书。认证成功后，服务端的公钥也就可信任了。数字签名也就可信任了。

5. 根 CA 证书

那么问题来了，服务端带的 CA 是假证书怎么办？也就是怎么知道我们的客户端是信任这些证书的？而不是某些中间人伪造的？

那么根 CA 证书派上了用场。验证服务端证书的 CA 证书，也要有 CA 证书认证，这些统称为中级证书。一直到根 CA 证书。全世界被认可和支持的，大部分浏览器和操作系统信任的根 CA 证书没几家。服务端要用 HTTPS，要让地球上几乎所有设备能够用上安全的 HTTP，就需要买这几家的证书：

• Symantec（VeriSign/GeoTrust）
• Comodo
• GoDaddy