HTTPS:非对称加密原理？数字签名和数字证书是什么？TLS握手过程是怎样的？为什么抓取HTTPS包时要安装代理证书？

为什么需要HTTPS

HTTP是明文传输的。在一个广播域内（连在同一个交换机的所有设备），所有的设备都是可以收到传输的数据（只是链路层协议会检查mac地址是否为自己，不是就丢弃）。

其数据的安全可能受到窃听、篡改、发送者身份不可靠 的三个问题。所以TLS( 传输安全协议)提供了加密、 数字签名、和 数字证书 来解决这三个问题。

加密算法分为对称加密和非对称加密，TLS使用的是非对称加密与对称加密结合。

对称加密即加密和解密用同一个密钥，其优点是效率高，但没有办法直接在网络上传播（直接传播对称密钥会使密钥也被窃听）。

非对称加密是指用一对密钥之一加密，另一个解密（一个叫公钥，一个叫私钥）。可以用公钥加密，也可以用私钥加密。

其优点是可以在网络通信的场景中使用——所有网络的用户都公开自己的公钥。发送者用接收者的公钥对数据加密，这样只有接收者可以解开这份加密过的数据。但缺点是加解密的效率低。

用一个简单的数学问题来模拟非对称加密的核心RSA

有两个规定好的公式来计算公钥和密钥：每个人的私钥都只有自己知道，公钥则是公开的

3^私钥 % 17 = 公钥（可以看出从公钥是无法逆推私钥的）
对方的公钥^自己的私钥 %17 = 密钥（可以看出密钥的得出需要双方的信息）

现在规定:

A:（私钥）13
B:（私钥）15

可以计算出：

A:（私钥）13 （公钥）12
B:（私钥）15 （公钥）6

最后的密钥：

A的私钥13 +B的公钥6 -->（密钥）10
B的私钥15 +B的公钥12-->（密钥）10

这样实现了在开放的网络中A和B公开的协商后了一对只要它们俩才知道的密钥（密钥的得出必须要协商双方一方的公钥+另一方私钥）

A现在要告诉B一个数字k（原文），于是把他放在一个信封里，信封上面标注着12（12是A的公钥），并且传输k+10（10是协商的密钥）（加密）。B收到之后，看到信封上的12，知道是A发给自己的消息，会用A的公钥计算秘钥，得出为10，会减去10（解密）。

现在信息的加密传递只需要发送发和接受发的公钥就可以完整，每个人都把自己的公钥公开，接受方的公钥就可以得到，发送方把自己的公钥标注在信封在，接收方也可以拿到发送方的公钥。

而其他窃听者只能得到k+10（密文）,由于没有B的私钥，没有办法算出密钥，就无法知道真实的数据。

通过这样的方式，发送方用接收方的公钥加密，保证只有接收方能读懂发送方发的数据。

加密使得发送方不用担心数据被别人看到，但接收方并不能保证自己受到的数据是可信的。这份数据可能被篡改过（即信封中k+10可能会被人改成k+9）。

所以引入了数字签名来保证B收到数据时可以判断数据有没有被别人修改过。

数字签名类似于校验码，会附加在要传输的原文件的尾部，原文件+数字签名任何一者的修改过都会导致无法通过校验。

接收方接收到原文件和数字签名时，会做两件事。

注意：数字签名并没有防止窃听，只能保证发送的数据和收到的数据是一样的

上面的流程中，使用到了A的公钥去解密。所以还存在一个问题，即这个公钥可靠吗？即A这个用户真的存在吗，或者它真的是A本人吗？

所以有了数字证书颁发机构和数字证书，用来做发送方的身份确认。

数字证书颁发机构（CA）是通信中的权威机构，所有用户都信任它。

发送方A将会将自己的公钥交给CA，CA会用自己私钥对发送方A的公钥加密,生成A的证书，给A。

之后的通信过程中，A会首先把自己的公钥证书（用CA私钥加密的A的公钥）发送给B,B用CA的公钥解密收到的证书。解密成功，才认为这个公钥的可信的。

TLS的握手过程可以简单分为两个过程

在使用charles抓包时，作为客户端和服务器的中间，可以截获所有数据。

但在抓取HTTPS数据包时，由于数据解密需要用到的密钥需要用到服务端的公钥和私钥，公钥即服务端的证书，而私钥不可能获取，所有会看到所有的数据都是乱码。

所以需要

即安装的代理软件的证书就是 由代理软件自己签发的+用代理软件的公钥生成的 凭证。客户端必须安装这个证书，并且信任Charles这个签发机构。