HTTPS = HTTP + SSL/TLS
为什么需要 SSL/TLS，是因为 HTTP 太不安全了， HTTP 是明文传输，主要风险如下：
- 数据被窃取，即中间人可以窃取到通信内容
- 数据被篡改，即中间人可以劫取到报文后，对其进行修改
- 冒充服务器，与浏览器进行通信
HTTPS 加密方法
<1> 对称加密
对称加密即通信双方共用同一把密钥，一方用密钥对数据进行加密，另一方收到后再用密钥进行解密，从而得到数据内容。
优点：
- 加密解密的速度快，性能高
缺陷：
- 由于密钥是双方共用的，那生成密钥方需要把密钥传输给另一方，而在该传输过程中，是明文传输，那密钥当然也会很轻易地被中间人劫取甚至替换掉，那后续传输过程中数据加密的效果就失效了。
<2> 非对称加密
非对称加密即通信双方使用不同的密钥，一把为公钥，一把为私钥。公钥是可以公开的，私钥不可以公开。而公钥加密的内容由私钥解开，私钥加密的内容由公钥解开。
流程为：服务器会生成一个公钥 key 和私钥 key1 。服务器会把公钥 key 给浏览器私钥 key1 留在服务器本地。
优点：
- 浏览器到服务器的数据传输很安全，因为浏览器用公钥 key 给数据加密，而想要解密必须要 私钥 key1 ，而 私钥 key1 是在服务器本地，不易被中间人劫取。
缺陷：
- 缺陷也显而易见，即服务器到浏览器的数据会轻易地被中间人破解，因为 公钥 key 在传输过程中是明文传输！
<3> 对称加密 + 非对称加密
如下图所示： 
这样，两方都拿到了密钥 X ，且 X 并没有通过明文传输，所以不会被劫取！
看似问题已经得到解决了，但是还是有 bug ，中间人还是可以进行一波操作！如下图所示：
那如何解决浏览器收到的公钥一定是服务器的公钥呢？------------ CA 证书
网站在使用 HTTPS 协议前，需要向 CA机构 申领一份数字证书 ，数字证书中含有 证书持有者的信息 ：
证书序列号、证书过期时间、站点的组织名、站点的DNS主机名、站点的公开密钥以及 颁布者的信息 ：颁布者的名称、颁布者的签名......
(1) 如何防止证书被篡改？------------ 数字签名
数字签名的实现：
即先使用摘要算法（如 MD5）将证书主要内容生成摘要，然后使用第三方权威机构的私钥对生成的摘要进行加密，签名就生成了！
客户端的验证：
客户端收到证书后，根据摘要算法，生成该证书的摘要。并用第三方机构的公钥对数字签名进行解密，获取摘要，并将两个摘要进行对比，如果一致，说明验证通过！如果不一致，说明证书被篡改！
注意：
CA 公钥如何安全地传输到 client ？如果还是从 server 传输到 client，依然无法解决公钥被调包的风险，实际上此公钥是存在于 CA 证书上，而此证书（也称 Root CA 证书）被操作系统信任，内置在操作系统上的，无需传输
(2) 如何防止证书被调包 ？------------ 域名验证
任何站点都可以向第三方权威机构申请 CA 证书，中间人也可以。那中间人岂不是就可以拦截 server 发送给 client 的证书，并调包换成自己的证书，从而进行后续数据的劫取？
其实是行不通的，因为客户端在收到证书后，除了要验证书是否合法外，还会 验证证书上的域名与自己请求的域名是否一致？ 如果不一致，client 则会认定为不通过！
那抓包软件如 Charles 是如何实现抓包的呢？
主要流程如下图：
所以 Charles 中间人能够抓包的前提是 client 得信任它的证书！
补充之关于根证书/一级证书/二级证书
我们可以向 CA 申请证书，但全世界的顶级 CA（Root CA） 就那么几个，每天都有很多人要向它申请证书，它也忙不过来啊，怎么办呢？
既然顶级 CA 忙不过来，那它就向下一级，下下级 CA 授权即可，这样我们就只要找一级/二级/三级 CA 申请证书即可。怎么证明这些证书被 Root CA 授权过了呢，小一点的 CA 可以让大一点的 CA 来签名认证，比如一级 CA 让 Root CA 来签名认证，二级 CA 让一级 CA 来签名认证,Root CA 没有人给他签名认证，只能自己证明自己了，这个证书就叫「自签名证书」或者「根证书」，我们必须信任它，不然证书信任链是走不下去的！
如果 站点申请的是 二级 CA 颁发的证书，client 收到之后会如何验证这个证书呢，实际上 service 传了传给二级 CA 的证书外，还会把证书信任链也一起传给客户端，这样客户端会按如下步骤进行验证：
-
浏览器就使用信任的根证书（根公钥）解析证书链的根证书得到一级证书的公钥+摘要验签
-
拿一级证书的公钥解密一级证书，拿到二级证书的公钥和摘要验签
-
再然后拿二级证书的公钥解密 server 传过来的二级证书，得到服务器的公钥和摘要验签，验证过程就结束了
参考：