https为什么是安全的?通俗易懂讲解非对称加密,数字签名与数字证书
这几天在看django源码,发现一些关于加密的问题,因此结合已知的一点密码学知识跟几个小时的网上查找,总结出了此文章。
我们都知道https就是http上使用了加密,因此在chrome上,会标记http是不安全的,因为它是明文传输的,而https是安全的。那么,为什么https是安全的呢?它的传输究竟是怎么做的?下面我们需要先普及几个概念
明文传输
http,就是使用的明文传输,也就是没有任何加密,你的账号密码直接在报文上可以看到,又由于我们的数据包是经过各种转发到达的,因此也就是说,客户端到服务器走过的数据链路都知道了你们的发啥。简单来说,这其实就是小学时上课的传纸条啊!结果传纸条路径上的所有人都知道了你们再聊啥,要是聊到什么深度的问题,咳咳。
对称加密
为了不让其他人随便看你们的通信,加密是必须的,最容易想到的就是对称加密,即两人约定使用一种加密算法跟同样的秘钥。对称加密就是两个人使用同一种秘钥p。
由于计算机中加密算法就那么几种,因此需要使用秘钥,保证让黑客暴力难以**,举个简单的比如两个写信的小男孩规定每个字母往后移两个,如a变c。变音就是加密算法,这个2就可以当成秘钥,因为别人不知道你往后变几个音
假设甲是服务器,乙是客户端浏览器。
甲先把文件用对称加密。有两个重要参数,一个是算法,一个是秘钥p。
此时需要把这两个东西给乙。这份报文是可以加密给了,可是一开始秘钥不可能加密再给乙啊,不然一开始乙都不知道怎么加密的,怎么获得秘钥,直接明文给被获取又凉凉。因此https是这么做的,将对称加密的秘钥p用非对称加密来传输。传输之后,就一直用对称加密进行报文的通信就行了。
因此,这里解决了的是,后续报文的通信问题。但有第一次传输对称秘钥的问题
https使用数字签名与非对称加密(准确来说数字证书包括这两项)来发送秘钥(可能你会问为什么不使用非对称加密直接加密报文,原因是,非对称加密速度太慢,比对称加密慢100-1000倍。没必要,用非对称加密来传输对称加密使用的秘钥p,之后用对称加密进行通信就行了)。
非对称加密
非对称加密有公钥跟私钥,公钥加密的必须用私钥才能解密,私钥加密的用公钥才能解密。
跟对称加密的区别就是一把加密,只能用另一把解密,因此是非对称的。
甲有自己的公钥跟私钥r1跟b1,乙也有自己的公钥私钥r2跟b2。甲发消息时,就用公钥b1进行加密,再发出去。这样,就只有乙才能解密了,因为它有私钥r2。反之亦然,这样就保证了报文内容的安全性。
因此一开始由甲把自己的公钥r1明文发送给乙,乙自己随机生成一个对称秘钥r2,b2,并用b1将b2加密后发送给甲,甲用r1进行解密,得到b2。这样乙就有自己的秘钥r2,b2跟甲的公钥b1,甲也有自己的秘钥跟乙的公钥b2
(下图蓝色代表甲的,橙色代表乙的)
第一次发送的报文内容是安全不会被暴露了,那么问题来了,要怎么证明报文没有在中途被替换,确实是甲发过来的?这里就要用到数字签名了。
数字签名
因此甲把文件使用hash算法(一般使用不可逆的hash算法,如MD5),得出摘要,这个摘要没有语义,无法从摘要退出原理报文的信息,而且摘要一般比报文短很多,这样解密就会比较快,摘要在文件发生任何改变时,都会改变,也就是说篡改内容时生成的摘要也会变,因此摘要主要用来验证是否相等。
这时候甲再将摘要用私钥r1加密,这个加密后的摘要就是数字签名。注意数字签名是用私钥进行加密的,而不是用公钥加密的。
然后将报文+数字签名发给乙。乙将报文用自己的私钥r2进行解密,再用甲的公钥b1对数字签名进行解密。然后将解密后的文件用hash得出摘要,再与数字签名的结果进行对比,如果摘要相同,就证明是甲发的。
因为数字签名用的是甲的公钥b1解密的,因此加密的人一定是甲。这里证明的是,发过来的文件是公钥b1对应的私钥r1发过来的,中间没有被篡改。
(下图,蓝色是甲的秘钥,橙色是乙的秘钥)
数字证书
问题又来了,怎么确认这个公钥是甲的而不是别人的,即是说,r1的拥有者一定是甲呢?
这就有了"数字证书"(Digital Certificate)。甲需要发送自己的数字证书给乙证明自己就是甲,不是其他人。
两人无法互相相信时,此时就需要一个权威的第三者,这是一个签发数字证书的权威机构,叫”证书中心"(certificate authority,简称CA)。
要有这个机构的数字证书,才能进行身份认证,认证证书不仅包括了公钥,还包括了域名,签发机构,有效期,签名等,CA机构的认证很严格,跟我们的身份认证一样,因此可以相信。数字证书就像身份证,CA机构就是派出所。甲作为服务器一端,需要把自己的证书给乙看。然后乙到CA查看此证书是否是真实的。就相当于某人出示身份证,你就到派出所查看这个身份证是否是真的。
证书=公钥+申请者与颁发者信息+签名。
此外,CA机构还会提供双方公共的时间戳,过期时间以及随机数等。防止一方以时间不对而不承认签名。
CA的自己的证书或者公钥呢?
注意,你可能会发现一个问题,如何保证用户跟CA通信时,信息是CA发的?这个问题貌似又回到前面,如何证明是甲发的。由于CA机构给用户的数字传输时也使用了非对称加密,因此用户乙需要知道CA机构的公钥。
答案是:直接把最权威的几个CA机构证书放到用操作系统中。其实,之后只需要使用信任链,即机构1说机构2可以信任,那我们就可以信任2,机构2说机构3信任,那我们就可以信任机构C。这样我们就可以信任很多个CA机构分发的证书了。
https秘钥传输过程
参考文献:
https://www.zhihu.com/question/33645891
http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html