从Https协议谈对称加密和非对称加密
从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将两种加密算法搭配使用，具体的过程如下：
- 客户端发送Client Hello信息到服务器，信息以明文传输TLS版本信息、加密套件候选列表、压缩算法候选列表等。另外还会给对方一个随机数，这个随机数客户端和服务器都会留着。
- 服务器会回复Server Hello消息，告诉客户端用那个协议、加密套件、压缩算法等，并且服务器也会给客户端一个自己的随机数，现在每个人手里都有两个随机数了。
- 然后服务器会给客户端自己的证书
- 服务器会告诉客户端Server Hello done，我就给你这些信息。
- 客户端会去验证这个证书，在验证的过程中会不断的上溯CA、CA的CA，一直到一个你信任的CA出来做担保。
- 证书验证通过后，客户端会生成随机数Pre-master，发送Client Key Exchange，用证书中的公钥加密发给服务器。
- 服务器有了第三（客户端给了两个，自己生成一个）个随机数，客户端也有了三个随机数，然后双方都通过“自己的随机数”+“对端的随机数”+“Pre-master”一起算出对称密钥。
- 然后双方都发送给对方一个Encrypted Handshake Message，将已经协商好的参数等，采用密钥加密发给对方，作为握手验证，双方验证通过后就可以采用对称加密通信了。
总结
加密分为对称加密和非对称加密，对称加密效率高，但是解决不了秘钥的传输问题；非对称加密可以解决这个问题，但效率不高。
非对称加密需要通过证书来验证公钥的合法性
https是综合了对称加密和非对称加密算法的http协议。