前瞻
HTTP与HTTPS的关系
HTTPS也是一个在应用层的协议，是在HTTP协议基础上的一个加密解密层
明文 密文 秘钥
明文->秘钥 加密
秘钥->明文 解密
例如:明文为7 秘钥为2 7^2=101=5； 5就是密文
例子:
因为http的内容是明文传输的，明文数据会经过路由器、wifi热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是 中间人攻击，所以我们才需要对信息进行加密。
常见的加密方式
对称加密：
单秘钥加密，加密和解密所用秘钥相同
DES 3DES AES
特点:加密效率高，加密快，计算小
非对称加密：
双密钥加密 ：公开秘钥 私有秘钥
DSA RSA
我们可以将明文使用公开秘钥加密，再用私有秘钥解密
也能加个明文使用私钥加密，公钥解密
特点:算法强度复杂 运算速度非常慢
数据摘要&&数据指纹
对数据采用类如哈希和MD5方法变成散列值
应用场景： 百度云盘秒传 当我们传入一部电影时，会先形成数据指纹，一旦百度云盘对比指纹成功，就会形成一个指向性文件，指向别人已经上传好的文件
我们来设计https
提出方案，发现方案问题
方案一：双方只用对称秘钥：
中间人也能拿到公钥，当客户端发送请求时，中间人能直接用公钥解密
方案二：双方只用非对称加密：
中间人无法拿公钥解密，只有服务器能用私钥解密，貌似是安全的，但是服务端向给客户端回应呢，服务端用私钥加密，但是中间人不也可以用公钥解密，用公钥加密，客户端又无法解密
方案三：双方都用非对称加密
服务器有一对非对称秘钥 公钥S 私钥S*
客户端有一对非对称秘钥 公钥C 私钥C*
双方交换公钥 此时中间人，客户端，服务端都有S C 客户端和服务端额外有自己的 S* C*
当客户端用S加密request 只有服务器能用S*解密，没问题，中间人无法解密
服务端进行响应,用客户端的公钥C加密，只有客户端能用自己的私钥C*解密，中间人也无法解密
看起来无懈可击，但是非对称加密运算速度非常慢,可能导致响应到零点几秒
并且依旧有安全问题
但数据只值10元钱。但是我们用100去破密，此时可以说我们是加密是安全的
方案四：用非对称加密与对称加密
服务器拥有S S* ，客户端拥有公钥P，服务端发给客户端S，此时我们得让服务端知道P，但不能让中间人知道P，此时就用S+P发给服务端，只有服务端能用S*解密得到公钥P，此后只用对称秘钥进行通信。
既解决速度问题，又解决了安全问题
即使市面上HTTPS60%都是这种方案，但是还是有问题
我们试着作为攻击这个方案
我们作为中间人一直都是被动处理信息，但是我们是可以主动发起攻击的，假设此时中间人也拥有了非对称私钥M M*
我们可以在客户端向服务端获取公钥S的时候就发起攻击，直接将S换成M，假装无事发生发送给客户端，客户端再用M加密对称秘钥C，此时客户端发送给服务端C+M，此时中间人截获，可以直接用M*截取C，之前，我们中间人客户端服务端都是不知道我们的存在的，我们肯定要一直待在暗处，此时就不能傻乎乎的把C+M发送给服务器，因为一旦发生C+M，服务器解密不出来C，就发现了我们的存在，此时我们就又要假装无事发生的将之前获取S，对C+S发送给服务器，让服务器以为只有自己知道了C。
同理在上面我们提到双方都用非对称加密 也是有安全问题的，我们直接将S截获换成M，把服务器骗了，当客户端发送req+M时，中间人就可以解密了
这个问题，在于我们客户端太单纯了，一有坑就跳。
此时我们就得引入证书了
解决：方案五
浏览器/client内置CA权威机构的公钥+证书(server的公钥)+非对称+对称= 方案5