Saraph1nes Blog

Appearance

Charles抓包原理与HTTPS加密 ​

✨文章摘要（AI生成）

本文深入探讨了 Charles 抓包工具的工作原理和 HTTPS 加密机制。文章首先介绍了对称加密和非对称加密的基本概念，然后详细解释了 HTTPS 的连接建立过程（TLS握手）和通信过程。接着讨论了数据完整性验证的重要性，包括数字签名和数字证书的作用。最后通过分析 Charles 的抓包策略，说明了它如何通过伪造证书来实现 HTTPS 请求的拦截和解密。文章对于理解网络安全和抓包工具的工作机制提供了全面的参考。

加密方式 ​

对称加密 ​

其原理是使用相同的密钥（也称为私钥或共享密钥）来加密和解密数据。这意味着加密和解密过程中都使用同一个密钥。

以下是对称加密的原理和特点：

原理：

  • 加密过程：明文通过一个算法和密钥进行加密，生成密文。
  • 解密过程：密文通过相同的算法和密钥进行解密，还原为原始的明文。

特点：

  • 高效性：对称加密算法的加密和解密速度很快，适合对大量数据进行加密。
  • 简单：相比非对称加密算法，对称加密算法更加简单，易于理解和实现。
  • 密钥管理：密钥的管理相对容易，因为只需要管理一个密钥，而不像非对称加密需要管理一对密钥。
  • 安全性：虽然对称加密算法通常比非对称加密算法更快速，但在密钥分发和管理方面存在一些挑战。密钥的安全性非常重要，因为如果密钥泄露，所有加密的数据都会受到威胁。
  • 适用范围：对称加密通常用于保护大量数据的传输，例如在网络通信、数据存储和加密文件等方面。

非对称加密 ​

与对称加密相比，它使用一对密钥：公钥和私钥。公钥用于加密数据，而私钥用于解密数据。

以下是非对称加密的原理和特点：

原理：

  • 加密过程：发送者使用接收者的公钥对数据进行加密。
  • 解密过程：接收者使用自己的私钥对加密后的数据进行解密。

特点：

  • 双重密钥：与对称加密不同，非对称加密使用一对密钥，即公钥和私钥。公钥用于加密，私钥用于解密。
  • 安全性：非对称加密提供了更高的安全性，因为私钥不需要共享或传输，只有持有私钥的接收者才能解密数据。
  • 密钥分发：不需要在通信之前共享密钥，只需要发送方知道接收方的公钥即可。这降低了密钥管理的复杂性和安全性风险。
  • 数字签名：非对称加密可以用于数字签名，验证数据的完整性和真实性。发送者可以使用自己的私钥对数据进行签名，而接收者可以使用发送者的公钥来验证签名的有效性。
  • 计算复杂性：相对于对称加密，非对称加密算法通常更加复杂，加密和解密的计算成本更高，因此可能不太适合大量数据的加密。

尽管非对称加密提供了更高的安全性和便利性，但它的计算复杂性和性能开销可能会成为一些特定应用场景的限制因素。因此，在实际应用中，通常会将非对称加密与对称加密结合使用，以兼顾安全性和效率。

HTTPS ​

连接建立过程（TLS握手） ​

  1. 客户端向服务器请求（发送TLS版本号、支持的加密算法、随机数Client Random）；
  2. 服务器返回非对称加密的公钥（证书）、商定的加密算法、随机数Server Random给客户端；
  3. 客户端验证服务器返回的证书；
  4. 证书验证通过，客户端就会生成一个新的随机数pre-master，用服务器的公钥加密该随机数并发送给服务器；服务器收到后，用私钥解密，得到客户端发来的随机数pre-master。 至此，客户端和服务端双方都共享了三个随机数，分别是Client Random/Server Random/pre-master。客户端就根据服务器返回的证书及3个随机数生成一个会话密钥（对称加密）；
  5. 客户端用服务器返回的公钥（证书）对会话密钥进行非对称加密后传输给服务器；
  6. 服务器通过私钥解密得到会话密钥；
  7. 客户端和服务器互相传输加密的握手消息来验证安全通道是否已完成；

img

通信过程 ​

  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，如果不一致则数据已被篡改

数字证书 ​

数字证书&CA ​

以上加密过程，最核心的就是非对称加密的公钥和私钥。如果这个密钥都是攻击者提供的，那传输的数据在攻击者那里也是相当于裸露的，如何确保密钥是不被冒充的呢？

HTTPS使用了数字证书(签名)，数字证书就是身份认证机构CA（Certificate Authority）加在数字身份证上的一个签名，证书的合法性可以向CA验证。

证书的制作方法是公开的，任何人都可以自己制作证书，但只有权威的证书颁发机构的证书能通过CA认证。

当客户端与服务器建立HTTPS连接时，客户端会验证服务器提供的数字证书。

数字证书主要包含以下信息：

  • 证书颁发机构
  • 证书颁发机构签名
  • 证书版本、有效期
  • 证书绑定的服务器域名
  • 签名使用的加密算法（非对称算法，如RSA）
  • 公钥

简单说，证书就是用来告诉客户端，服务端是否合法。

为了让服务端的公钥被信任，服务端的证书都由CA签名，CA就是网络世界里的公安局，具有极高的可信度，所以由它来给各个公钥签名，信任的一方签发的证书，那必然证书也是被信任的。

数字证书签发和验证流程 ​

  • CA签发证书的过程

    • 首先CA会把持有者的公钥、颁发者、用途、有效时间等信息打包；然后对这些信息进行Hash计算。
    • 然后CA会使用自己的私钥将该Hash值加密，生成Certificate Signature，即CA对证书做了签名。
    • 最后将Certificate Signature添加在文件证书上，形成了数字证书；

  • 客户端校验服务端的数字证书的过程：

    • 客户端会使用同样的Hash算法获取该证书的Hash值A；
    • 通常浏览器和操作系统中集成了CA的公钥信息，浏览器收到证书后可以使用CA的公钥解密Certificate Signature内容，得到一个Hash值B;
    • 最后比较A和B，如果值相同，则为可信赖的证书，否则认为证书不可信。

客户端和服务器连接过程中，收到服务器返回的证书后，会先向CA验证证书的合法性（根据证书的签名、绑定的域名等信息），如果校验不通过中止连接，并提示证书不安全。

HTTPS抓包原理 ​

unknown的原因 ​

首先我们看下默认情况下，使用Charles抓包HTTPS的情况：

img

正常情况下，得到的结果都是<unknown>，这是因为我们前面讲的HTTPS的安全性的作用，点击<unknown>查看具体信息：

img

（ps: 截图中也可以看到 TLS版本号，协商的加密算法等信息；这个和上述流程对应上了）

可以看到，报错原因是SSL握手失败，也就是在TLS/SSL连接建立时就已经失败，还没有到数据通信这步来；

进一步查看TLS Alert Code得到更详细的信息：

wiki
handshake_failure (40) - Unable to negotiate an acceptable set of security parameters, this probably means there are no cipher suites in common

大概意思是，密钥参数没有协商一致

这是因为Charles为了能窃听、篡改HTTPS通信数据，在客户端与服务端连接建立过程中（参考上面HTTPS连接建立过程的第2步），当服务器返回非对称加密的公钥（证书）、商定的加密算法、随机数Server Random给客户端时，Charles拦截到服务器返回给客户端的公钥（证书）替换成自己的公钥（证书）再发送给客户端； 准备以此来冒充通信的双方。

但是前面我们也分析过了，HTTPS会通过数字证书验证通信双方身份的真实性；Charles的证书并不能通过CA验证，证书未验证通过那客户端后续流程就不会进行：包括生成一个新的随机数pre-master、生成非对称密钥等流程；最终导致连接失败；

由于是TLS握手都没成功，不止是Charles失败，原先的客户端和服务器也不能建立正常连接，客户端网络请求也都是失败；

Charles的策略 ​

Charles如何解决证书验证的问题呢？

根据官方教程，需要我们使用者在手机上安装Charles根证书并设置为信任：

img

配置好后，就能和HTTP一样抓包使用了；

为什么手机安装了Charles根证书后就能正常抓包呢？结合数字证书验证的原理，CA起到了决定性作用；一般常用的CA证书(公钥)是事先内嵌在手机系统里的，如果不是内嵌的CA私钥签名的都验证不通过；

Charles根证书就类似Charles CA，用户手动安装到系统并设置信任，相当于系统里多了一个CA；

后续Charles的伪造的经过Charles根证书(私钥)签名的公钥就能验证通过，握手成功，通信过程也能窃听、篡改；

Charles抓包的完整流程 ​

整个流程大致如下图：

img

  • 当客户端和服务器建立连接时，Charles会拦截到服务器返回的证书（服务器公钥）
  • 然后动态生成一张伪造证书（Charles公钥/假公钥）发送给客户端
  • 客户端收到Charles证书后，进行验证；因为之前我们手机设置了信任，所以验证通过；（只要手机不信任这种证书，HTTPS还是能确保安全的）
  • 客户端生成会话密钥，使用Charles证书对会话密钥进行加密再传输给服务器
  • Charles拦截到客户端传输的数据，使用自己的Charles私钥进行解密得到会话密钥
  • 连接成功后，客户端和服务器通信，客户端对传输的数据使用会话密钥加密并使用公钥对数据摘要进行数字签名，一同传输给服务器；
  • Charles拦截到通信的数据，使用之前获得的会话密钥解密就能得到原始数据；
  • Charles同样也能篡改通信的数据：将篡改后的数据重新加密并重新生成摘要并使用之前获得的公钥进行数字签名，替换原本的签名，再传输给服务器；
  • 服务器收取到数据，按正常流程解密验证；
  • 服务器返回响应数据时，Charles也是类似拦截过程

Last updated: