https--HTTP权威指南读书笔记

why https

用https就是为了安全。那用http怎么就不安全了，请看下面例子。

小灰客户端，小红服务端有一天小灰给小红发请求；

但是，由于传输信息是明文，这个信息有可能被某个中间人恶意截获甚至篡改。这种行为叫做中间人攻击。

如何进行加密呢？
（对称加密）
小灰和小红可以事先约定一种对称加密方式，并且约定一个随机生成的密钥。后续的通信中，信息发送方都使用密钥对信息加密，而信息接收方通过同样的密钥对信息解密。




这样做是不是就绝对安全了呢？并不是。
虽然我们在后续的通信中对明文进行了加密，但是第一次约定加密方式和密钥的通信仍然是明文，如果第一次通信就已经被拦截了，那么密钥就会泄露给中间人，中间人仍然可以解密后续所有的通信内容。

这可怎么办呢？别担心，我们可以使用非对称加密，为密钥的传输做一层额外的保护。非对称加密的一组秘钥对中，包含一个公钥和一个私钥。明文既可以用公钥加密，用私钥解密；也可以用私钥加密，用公钥解密。
在小灰和小红建立通信的时候，小红首先把自己的公钥Key1发给小灰：

收到小红的公钥以后，小灰自己生成一个用于对称加密的密钥Key2，并且用刚才接收的公钥Key1对Key2进行加密，发送给小红：

小红利用自己非对称加密的私钥，解开了公钥Key1的加密，获得了Key2的内容。从此以后，两人就可以利用Key2进行对称加密的通信了。

在通信过程中，即使中间人在一开始就截获了公钥Key1，由于不知道私钥是什么，也无从解密。
那这样做是不是就绝对安全了呢？同样不是。
中间人虽然不知道小红的私钥是什么，但是在截获了小红的公钥Key1之后，却可以偷天换日，自己另外生成一对公钥私钥，把自己的公钥Key3发送给小灰。

小灰不知道公钥被偷偷换过，以为Key3就是小红的公钥。于是按照先前的流程，用Key3加密了自己生成的对称加密密钥Key2，发送给小红。
这一次通信再次被中间人截获，中间人先用自己的私钥解开了Key3的加密，获得Key2，然后再用当初小红发来的Key1重新加密，再发给小红。

那怎么办呢？难道再把公钥进行一次加密吗？这样只会陷入鸡生蛋蛋生鸡，永无止境的困局。
这时候，我们有必要引入第三方，一个权威的证书颁发机构（CA）来解决。

HTTPS流程
1.服务端首先把自己的公钥（Key1）发给证书颁发机构，向证书颁发机构申请证书。

2.证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密Key1，并且通过服务端网址等信息生成一个证书签名，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给了服务端。

3.当客户端向服务端请求通信的时候，服务端不再直接返回自己的公钥（Key1），而是把自己申请的证书返回给客户端。

4.客户端收到证书以后，要做的第一件事情是验证证书的真伪。需要说明的是，各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。所以客户端只需要知道是哪个机构颁布的证书，就可以从本地找到对应的机构公钥，解密出证书签名。
客户端对证书验证成功后，就可以放心地再次利用机构公钥，解密出服务端的公钥Key1。
客户端本地如何验证证书呢？

证书本身就已经告诉客户端怎么验证证书的真伪，也就是证书上写着如何根据证书上的方法自己生成一个证书编号，如果生成的证书编号与证书上的证书编号相同，那么证明这个证书是真实的。同时，为避免证书编号本身又被调包，所以使用第三方机构的私钥进行加密。
证书就是HTTPS中的数字证书，证书编号就是数字签名，而第三方机构就是指数字证书签发机构（CA）

5.客户端生成自己的对称加密密钥Key2，并且用服务端公钥Key1加密Key2，发送给服务端。

6.服务端用自己的私钥解开加密，得到对称加密密钥Key2。于是客户端与服务端开始用Key2进行对称加密的通信。

参考：
why https
https原理及流程