一、代理原理

众所周知 https协议数据是加密传输的，那为什么charles/fiddler工具可以抓取到https接口数据呢?

前提:了解对称加密、非对称加密、私钥、公钥(密钥)

对称加密

双方使用相同的密钥进行通信；
编、解码使用相同密钥的算法，如（AES，RC4，ChaCha20）

【对称加密速度快，但安全性较低，传输的数据加密的秘钥容易被拦截到，所以结合非对称加密算法一起使用–混合加密】

非对称加密

一个密钥对(包含:一个公钥和一个私钥)，公钥是对外开放 的任何人可使用，私钥是自己私有的，绝对严格保密；
公钥加密的数据，只能私钥解密
私钥加密的数据，只能公钥解密
编、解码使用不同密钥的算法 ，如（DH，DSA，RSA，ECC）。

【非对称加密速度慢、效率低，相对对称加密来说，加密过程较复杂；但可以保证身份校验，避免篡改的第三方身份】

【所以服务器给浏览器发送的数据一般都使用公钥加密的，使用私钥加密的话不安全，因为公钥容易被窃取到；而浏览器给服务器发送用公钥加密的数据是安全的，因为拿不到私钥无法解密】

整体工作流程:

CA证书获取

服务器从签发机构获得的CA证书，如何获得的?

1.服务端先生成一对密匙，包含公钥和私钥，私钥自己保留，然后拿着自己的公匙以及其他基础信息（比如说申请者、域名等）去CA申请数字证书

【明文信息:发布机构、有效期、证书拥有着、签名算法、申请者的公钥、申请者的基础信息（域名）】

2.权威证书签发中心CA在拿到申请者信息后，判明申请者的身份，会选择一种单向Hash算法，也就是签名算法（比如说常见的MD5）对这些明文信息进行加密生成签名值sign

3.CA（也有一对公钥 私钥）还会用自己的私匙对签名值sign进行加密，加密后的数据我们称之为数字签名

4.CA将会服务器的公钥和数字签名整合在一起，由此而生成数字证书;

5.CA机构将数字证书传递给服务器

篡改证书

charles拦截CA证书，charles拿到服务器的公钥 ，自己制作一份证书发给客户端，其中包含了charles自己的基础信息等；

charles拿到服务器公钥的目的:使用charles的公钥替换掉服务器的公钥 ，【这样后期就可以使用charles自己的公钥加密 真正通信时对称加密的密钥，再使用自己的私钥解密拿到】，从而达到拦截篡改客户端、服务端之间的通信 信息的目的；

CA证书校验

【身份校验】客户端如何对收到的证书校验，看是否被篡改过呢?

【进行CA证书签发的机构总共就那几家，一般操作系统都有内置他们的根证书】
【前提:客户端即我们的app端需要去CA机构拿到CA根证书，这里其实我们的操作系统不论APP端还是pc端 一般已经内置了CA机构的根证书；】

1）操作系统内置的CA根证书，即可以拿到CA公钥，即通过公钥解密数字签名后可以拿到签名值sign值；

备注:这里上级证书相当于根证书是包含了CA的公钥的；
因为数字签名是经过CA的私钥加密过的，所以需要CA的公钥解密；

2）客户端根据读取到CA证书的明文信息，通过相同的hash算法（签名算法）得到一个签名sign值；【下发的证书中携带服务器使用的签名算法信息】

3)两者得到的签名sign值做匹配，匹配成功则可信任,说明数据完整没有被篡改；

补充:
【CA证书相当于一个证书链，操作系统存储的是根证书，
服务器证书相当于它的下级，证书链的验证是从根CA机构开始自下而上的信任传递的过程。】

例如:

证书链1:
www.baidu.com------>root_1(根证书)
证书链2:
cdn.qq.com------->root_2（根证书）
证书链2:
cdn.qq.com------->-------中间证书>root_2（根证书）
//这里当然也可以出现中间证书
即ca机构有可能存在中间机构，让中间机构给服务端生成下发真正的CA证书；