目录
[六、终级方案：非对称加密 + 对称加密 + 证书认证](#六、终级方案：非对称加密 + 对称加密 + 证书认证)
一、为什么需要https
HTTP协议内容都是明文传输的，传输过程可能会经过很多中间设备（如一个局域网中的路由器，电脑连接手机热点，公共产所的wifi等），这些中间设备可以抓取我们的请求或响应，会导致信息泄露，消息篡改等信息安全问题，因此有了HTTPS。
HTTPS协议也是一个应用层协议，是在HTTP协议的基础上引入了一个加密解密层：
二、常见加密方法
1、对称加密
加密和解密时使用相同的密钥。
特点：加密速度快，加密效率高 。
常见对称加密算法：DES、3DES、AES等
2、非对称加密
特点：解决密钥安全配送问题，但运行效率低。
通信双方各有一组密钥：公钥和私钥
公钥可公开，私钥必须保密，用公钥加密的密文必须用与该公钥配对的私钥解密。
接收方将自己的公钥公开给发送方。发送方使用接收方的公钥对数据进行加密，然后传输给接收方。即使在加密数据的过程中，接收方的私钥始终保密，因此无需对外公开。只有接收方拥有私钥可以解密数据。
常见非对称加密算法：RSA是使用最广泛的非对称密码算法。
3、数据指纹
对于一份明文数据，通过一种Hash算法（MD5），可以让其生成一个固定长度的，非常低概率发生冲突的固定长度的字符串（也叫数据摘要），具有唯一性，如果原文发生细微更改，生成的字符串都会有很大的不同，这就叫这份明文的数据指纹。
使用案例：平时我们使用百度网盘的时候，可能会有看到秒传这样的现象，如何做到的呢？
假设有一个用户传了一部电影到百度网盘服务端，服务端会根据用诸如MD5这样的hash算法计算出它的摘要或者叫数据指纹，然后入库，当下一次另一个用户上传同样的一部电影时，经过计算发现其数据指纹对应的数据在服务端已经存在，就不需要再上层了，从而实现秒传。
三、选择什么加密方案？
方案一：对称加密（×）
客户端和服务端双方约定好同一个密钥，但这并不靠谱。
密钥分发困难：对称加密需要双方共享相同的密钥，如果密钥在传输过程中被攻击者截获，会导致加密效果失效。在服务端和客户端之间安全地传输密钥是一项挑战。
密钥管理成本高：当客户端数量庞大时，需要为每个客户端分配一个唯一的密钥，密钥管理成本将大大增加。
方案二：双方使用非对称加密（效率低）
由于非对称密钥算法效率比对称密钥算法的效率低，所以我们还行再改进一下。
依旧有安全问题
方案三：非对称加密+对称加密
服务端具有公钥S和私钥S'
客户端发起请求获取服务端公钥S；
客户端形成一个对称密钥C，将C通过服务器端的公钥进行加密发送给服务器。服务器通过私钥S'进行解密获得对称密钥C。
之后双方就采用对称加密，这样只有传送对称密钥C时采用的是非对称密钥，其他时候都采用的是对称密钥，因此可以大大提高效率。
接近最佳方案，但依旧有安全问题
中间人攻击
上面的方案都有一个安全问题：如果在一开始就受到中间人攻击了呢？
服务器具有非对称加密算法的公钥S，私钥S'
中间人具有非对称加密算法的公钥M，私钥M" 3. 客户端向服务器发起请求，服务器明文传送公钥S给客户端。
中间人劫持数据报文，提取公钥S并保存好，然后将被劫持报文中的公钥S替换成为自己的公钥M，并将伪造报文发给客户端。
客户端收到报文，提取公钥M(自己当然不知道公钥被更换过了),自己形成对称秘钥X，用公钥M加密X，形成报文发送给服务器。
中间人劫持后，直接用自己的私钥M'进行解密，得到通信秘钥X，再用曾经保存的服务端公钥S加密后，将报文推送给服务器。
7.服务器拿到报文，用自己的私钥S'解密，得到通信秘钥X 8. 双方开始采用X进行对称加密，进行通信。但是一切都在中间人的掌握中，劫持数据，进行窃听甚至修改，都是可以的
根本原因：客户端无法确定收到的含有公钥的数据报文，就是目标服务器发送过来的。
四、引入证书
服务端在使用HTTPS前，需要向CA机构领取一份数字证书，数字证书里含有申请者信息，公钥信息等。服务器将证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。
怎么保证证书是真的，且没有被篡改过？看下面：
五、数字签名
签名： 用签名者的私钥对数据摘要进行加密，就形成了一个签名，将加密后的数据摘要 附加到原始数据上就形成了带有数据签名的数据，并将他们一同发送给接收方。
验证： 接收方收到两部分内容：数据摘要和原文；要对签名进行验证，首先要签名者的公钥解密得到数据摘要，再根据原文用相同的算法计算出数据摘要，比较俩个值，如果相同，则数字签名有效。
CA机构就是通过数字签名技术来帮助辨别CA证书的真伪。
六、终级方案：非对称加密 + 对称加密 + 证书认证
前面提到几种方案都有安全隐患即：客户端无法确定收到的含有公钥的数据报文，就是目标服务器发送过来的。
那么这个方案就可以解决这个问题：
客户端发起第一次请求时，服务端要将自己的CA证书（包括CA机构的认证签名，服务端的
公钥、域名等信息）响应给客户端。客户端收到证书后，用其内置的很多权威CA机构的公钥来验证签名（用公钥对数据摘要解密，再与计算根据明文计算出来的数据摘要进行比对），比对成功，则证明证书是可信的，也就是说证书上的服务端的公钥是可信的，由此就可以防范中间人攻击。之后客户端就可以用服务端的公钥来加密自己的对称密钥R，发送给服务端后，双方就可以通过对称密钥来进行通信。
中间人有没有可能篡改该证书？1）篡改明文？篡改明文后客户端验证签名时会比对失败
2）掉包整个证书？中间人没有私钥，所以无法制作假证书，只能用真证书来掉包，但证书里面是有域名等信息的，客户端可以识别出来域名发生了变化。
为什么签名不直接加密，而是要先hash形成摘要？1）缩小签名密文长度，加快数字签名的签名和验证效率。
七、HTTPS一定是安全的吗？
不一定。
上面提到的中间人攻击本质是对客户端进行攻击，那如果客户端本身就是攻击者呢？