Https原理_httpcanary原理

HTTP缺点

HTTP也有几个较为显著的缺点：

1. 通信使用明文，内容容易被抓包泄露
2. 无法证明报文的完整性，所以有可能遭到篡改
3. 不验证通信方的身份，因此有可能遭遇伪装

HTTPS的安全性

正是由于这几个显著的缺点存在，所以HTTPS应运而生。https俗称超文本传输安全协议。是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。HTTPS是在HTTP的基础上加上一层安全层(SSL或TLS协议)，用于数据加密、解密、身份认证，即
HTTP + 加密 + 认证 = HTTPS

HTTPS的安全性主要体现在下面3个方面：

1. 数据的保密性（防窃听）
2. 数据的完整性（防篡改）
3. 通信双方身份的真实性（防冒充）

数据保密性

要实现数据的保密，就需要使用加密算法对数据进行加密；加密算法大致分为三类：对称加密、非对称加密、散列算法

1. 对称加密算法：加密和解密数据使用同一个密钥。这种加密方式的特点是速度很快。目前主流算法有DES算法，3DES算法，AES算法
2. 非对称加密算法：数据用公钥加密后必须用私钥解密，数据用私钥加密后必须用公钥解密。这种加密方式的特点是速度慢，CPU 开销大。目前主流算法有RSA算法
3. 散列算法：没有秘钥，目前无法反向解密。(暴力破解除外)目前主要以MD5和SHA-1算法为主

CA证书：CA证书CA证书内含服务端公钥与私钥，使用hash散列函数计算明文信息的信息摘要，然后采用CA证书内含的私钥对信息摘要进行加密最终生成签名。即：证书 = 公钥 + 签名 +申请者和颁发者的信息。客户端中因为在操作系统中就预置了CA的公钥，所以支持解密签名。

一、连接建立过程

1. 客户端向服务器请求（发送TLS版本号、支持的加密算法、随机数C）；
2. 服务器返回非对称加密的公钥（证书）、商定的加密算法、随机数S给客户端；
3. 客户端验证证书通过，客户端就根据返回的证书及随机数S和随机数C生成一个会话密钥（对称加密）；
4. 客户端用服务器返回的公钥（证书）对会话密钥进行非对称加密后传输给服务器；
5. 服务器通过私钥解密得到会话密钥；
6. 客户端和服务器互相传输加密的握手消息来验证安全通道是否已完成；

二、通信过程

1. 客户端使用会话密钥对传输的数据进行对称加密传输给服务器；
2. 服务器使用会话密钥对传输的数据进行解密；
3. 服务器使用会话密钥对响应的数据进行对称加密传输给客户端；
4. 客户端使用会话密钥对传输的数据进行解密；

总结：连接建立过程使用非对称加密，后续通信过程使用对称加密；

数据完整性

数据的加密，有效保证了数据不被窃听（很难得到原始的数据），但传输的数据在传输过程中有可能被篡改或替换；比如：
传输的原始数据是123456，经过加密后数据是abcdef；客户端将abcdef这个数据传输给服务器，传输过程中中间人能拿到abcdef这个数据，但因为没有密钥很难解密出原始数据123456；但是，中间人还是能对得到的abcdef这个加密数据进行处理，比如将这个数据改为xxxxx；这样服务器得到的数据就是被篡改后的xxxxx；同样，服务器返回数据给客户端时也会被篡改；这样其实也是不安全的；
解决方案是进行数字签名：使用Hash算法将任意长度的字符串转化为固定长度的字符串，该过程不可逆，可用来作数据完整性校验；

数字签名的简要过程（服务器–>客户端为例，客户端–>服务器类似）：

1. 服务器使用Hash算法对数据提取定长摘要
2. 服务器使用私钥对摘要进行加密，作为数字签名
3. 服务器将数字签名连同加密的数据一同传输给客户端
4. 客户端使用公钥对数字签名进行解密，得到摘要A
5. 客户端对解密后的传输数据也使用Hash算法得到定长摘要B
6. 对比摘要A和摘要B，如果不一致则数据已被篡改

通信双方身份的真实性

以上加密过程，最核心的就是非对称加密的公钥和私钥；如果这个密钥都是攻击者提供的，那传输的数据在攻击者那里也是相当于裸露的；如何确保密钥是不被冒充的呢？HTTPS使用了数字证书(签名)，数字证书就是身份认证机构CA（Certificate Authority）加在数字身份证上的一个签名，证书的合法性可以向CA验证；证书的制作方法是公开的，任何人都可以自己制作证书，但只有权威的证书颁发机构的证书能通过CA认证；
数字证书主要包含以下信息：

• 证书颁发机构
• 证书颁发机构签名
• 证书绑定的服务器域名
• 证书版本、有效期
• 签名使用的加密算法（非对称算法，如RSA）
• 公钥
  客户端和服务器连接过程中，收到服务器返回的证书后，会先向CA验证证书的合法性（根据证书的签名、绑定的域名等信息），如果校验不通过中止连接，并提示证书不安全。

抓包原理

几乎所有网络数据的抓包都是采用中间人的方式（MITM），包括大家常用的Fiddler、Charles等知名抓包工具，HttpCanary同样是使用中间人的方式进行抓包。

从上面这个原理图，可以看出抓包的核心问题主要是两个：

MITM Server如何伪装成真正的Server；
MITM Client如何伪装成真正的Client。

第一个问题，MITM Server要成为真正的Server，必须能够给指定域名签发公钥证书，且公钥证书能够通过系统的安全校验。比如Client发送了一条https://www.baidu.com/的网络请求，MITM Server要伪装成百度的Server，必须持有www.baidu.com域名的公钥证书并发给Client，同时还要有与公钥相匹配的私钥。

MITM Server的处理方式是从第一个SSL/TLS握手包Client Hello中提取出域名www.baidu.com，利用应用内置的CA证书创建www.baidu.com域名的公钥证书和私钥。创建的公钥证书在SSL/TLS握手的过程中发给Client，Client收到公钥证书后会由系统会对此证书进行校验，判断是否是百度公司持有的证书，但很明显这个证书是抓包工具伪造的。为了能够让系统校验公钥证书时认为证书是真实有效的，我们需要将抓包应用内置的CA证书手动安装到系统中，作为真正的证书发行商（CA），即洗白。这就是为什么，HTTPS抓包一定要先安装CA证书。

第二个问题，MITM Client伪装成Client。由于服务器并不会校验Client（绝大部分情况），所以这个问题一般不会存在。比如Server一般不会关心Client到底是Chrome浏览器还是IE浏览器，是Android App还是iOS App。当然，Server也是可以校验Client的，这个后面分析。