从https协议谈对称加密和非对称加密

  首先,我们为什么要用https协议,在此我们举例说明:你在网上商城,发送一个购物的请求,要购买一件商品,但你的数据包被黑客截获了,黑客在网上商城服务器回复你之前回复你,让你提供银行卡账号和密码,如果你未能识别出这是黑客行文,那么后果就可以自己想象了。
  为了解决这个问题,一般的思路就是加密。加密后的数据包黑客就算截获了了也无法解密,也就无法知道你要干嘛,就无从构造回复报文。加密分为两种方式:对称加密和非对称加密。
  在对称加密算法中,加密和解密使用的密钥是相同的,因此在使用对称加密算法的时候一定要保证密钥不被泄露。
  在非对称加密算法中,加密使用的密钥和解密使用的密钥是不同的,一把是作为公开的公钥,另一把是作为谁都不能给的密钥。公钥加密的信息,只有私钥才能解密。私钥加密的信息,只有公钥才能解密。
  在效率方面,对称加密算法的效率比非对称加密算法的效率要高的多。
  接下来我们详细说下对称加密。
  假如使用对称加密,在购物时你和网上商城约定了一个密钥,你发送请求的时候用这个密钥加密,网上商城使用同样的密钥解密,这样看起来没有一起都很OK,但有个问题,你和商城怎样约定密钥而不被截获了,既在加密建立前如何安全的传送密钥?如果直接传送密钥的信息,那么这信息可能被黑客截获,之后所有的通信黑客都可以解密查看了,也就没有秘密了。我们总不能和商城的人约定一个时间地点然后线下传送密钥吧,就算是线下接头那是不是也要有个约定的暗号什么的,不然你们又不认识,但在传输暗号的时候还是可能被黑客截获,那么线下和你接头的人也说不好是谁呢…
  So,只要是使用对称加密,如何安全的传送密钥就是一个绕不开的问题,如果只使用对称加密,就会陷入一个密钥传送的死循环,幸好此时我们的非对称加密挺身而出。
  网站使用非对称加密的时候,他的密钥放在自己的口袋里谁也不给,但他会把公钥放在一个指定的地方谁都可以获取,只要你拿到了公钥,在你网站交流的时候,你用公钥加密你的信息,这时就算被人截获但因为缺少私钥,所以黑客也解不开你的信息。目前为止,一切开起来很顺利,但网站在给你回复信息的时候有个问题:网站的回复信息是拿他自己的私钥加密的,这个信息谁都可以用公钥来解密的。看来要解决这个问题,只使用网站的公私钥还不行,客户端也得有自己的公私钥,客户端把自己的公钥给网站,把私钥放在自己口袋,在和网站通信的时候客户端使用网站的公钥加密,网站使用客户端的私钥加密回复信息,至此解决了非对称加密的保密性问题。
  但对于非对称加密也有和对称加密一样的问题,如何将公钥给到对方,前面其实我们也说过一个方法,就是把各自的公钥放在公网上,这样谁都可以去取;还有另一种方法,就是在建立连接的时候把公钥传给对方。但这两种方式都有一个问题,你怎么确保给到你的公钥就是你信任的人呢,有没有可能有人假冒对方呢,答案是完全有可能。
  解决信任问题,最好的方法就是证明,证明什么呢,证明“你是你”!在现实生活中要证明你是你,你需要拿着公安局给你的身份证或者户口本来证明,别人不一定信任你,但身份证的颁发机构是公安局,是权威机构,别人看到身份证也就相信了你是你。其实在网络中也一样,你也需要一个权威机构给你一个证明,证明你是你,证明他是他,证明我是我…在网络世界里,权威部门颁发给你的身份证被称为“证书”。
  在证书中包含:公钥、证书的所有者、证书的发布机构、和证书的有效期。这样来看证书其实和身份证很像~,证书是怎么来的呢,有没有可能有假的证书呢,就像假的身份证一样?
  要生成证书需要发起一个证书请求,然后将这个请求发给权威机构去认证,这个权威机构不是公安局而是CA(Certificate Authority),把生成证书的请求发给权威机构后,权威机构会给这个证书卡个公章,我们称之为签名算法,接着,继续我们的怀疑精神,有没有可能会仿造签名呢,该怎么解决呢?签名算法解决了伪造签名的问题,签名算法用自己的私钥来进行签名,这样能用他的公钥解开的签名就能证明这个签名是真的。
  签名算法一般先对信息做一个hash运算,得到一个hash值,我们都知道这个过程是不可逆的,也就是无法根据hash值推导出原来的信息。在把信息发送出去的时候呢,把这个hash值加密后作为签名一起发出去。
  CA用自己的私钥给网站的公钥的签名,就相当于CA成了网站的担保人,担保这个公钥是这个网站的公钥而不是别人伪造的。
  那么你在和网站通信的时候就不会得到一个公钥了,而是一个证书,一个由CA担保的证书,但我们都知道,信任会传递,不信任也会传递,我们凭什么相信一个我们并不了解的CA机构呢,他又不是国家的公安局,而且我们得到的证书要解密的话还需要CA的公钥,我们怎么获取CA的公钥呢,怎么去相信获得的是CA的公钥呢,这是不是又是一个信任的死循环呢?当然不是,首先CA的公钥也要有人给他做担保人,谁呢?更牛的CA,你不相信小的CA机构,但如果是大的CA机构呢,就这样CA一层层的做担保,直到大到那种全球认可的CA机构他们不再需要担保人,因为他们自身就是root CA。
  在使用Https的时候还有一种常见的证书,就是自签名证书(self-signed certificate),有点像是我给自己带盐,你爱信不信的意思。
  到现在为止我们知道了,在使用https的时候我们无法只使用对称加密算法,但可以只使用非对称加密,之前我们提到过,非对称加密算法在效率上要远低于对称加密算法,因此在传输大数据量的时候我们希望能使用对称加密来提高效率,因此https将两种加密算法搭配使用,具体的过程如下:
  1.客户端发送Client Hello信息到服务器,信息以明文传输TLS版本信息、加密套件候选列表、压缩算法候选列表等。另外还会给对方一个随机数,这个随机数客户端和服务器都会留着。
  2.服务器会回复Server Hello消息,告诉客户端用那个协议、加密套件、压缩算法等,并且服务器也会给客户端一个自己的随机数,现在每个人手里都有两个随机数了。
  3.然后服务器会给客户端自己的证书
  4.服务器会告诉客户端Server Hello done,我就给你这些信息。
  5.客户端会去验证这个证书,在验证的过程中会不断的上溯CA、CA的CA,一直到一个你信任的CA出来做担保。
  6.证书验证通过后,客户端会生成随机数Pre-master,发送Client Key Exchange,用证书中的公钥加密发给服务器。
  7.服务器有了第三(客户端给了两个,自己生成一个)个随机数,客户端也有了三个随机数,然后双方都通过“自己的随机数”+“对端的随机数”+“Pre-master”一起算出对称密钥。
  8.然后双方都发送给对方一个Encrypted Handshake Message,将已经协商好的参数等,采用密钥加密发给对方,作为握手验证,双方验证通过后就可以采用对称加密通信了。
  总结
  加密分为对称加密和非对称加密,对称加密效率高,但是解决不了秘钥的传输问题;非对称加密可以解决这个问题,但效率不高。
  非对称加密需要通过证书来验证公钥的合法性。
  https是综合了对称加密和非对称加密算法的http协议。