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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Symantec(VeriSign/GeoTrust)
  • Comodo
  • GoDaddy

猜你喜欢

转载自blog.csdn.net/firefile/article/details/80535426