拦截请求的那些软件，例如Fiddler，是怎么解码https内容的？

Question

先说明，我对ssl也不是完全理解，只知道它既用了对称加密，也用了非对称加密。。哈。。。

以我的理解，https是用ssl证书进行内容加密，然后服务端通过对应的证书进行解密（这里用的非对称加密？）。

因此，Fiddler要拦截https，需要给监控设备安装ssl证书。但是这个ssl证书，在接收方那边，是不承认的，既然如此。。。。它又是如何能对返回的数据进行解密的呢？

==========2023-8-27==========
补充，看了一下几位大佬的回答，我大概明白了证书的作用，就是验证身份而已，我补充一下我的疑惑：

1.https的发送内容被加密，是证书的作用吗？这个加密解密是谁操作的呢？我一直以为，服务端用ssl证书加密，如果客户端没用一样的ssl证书的话，则无法解密？

==========2023-8-25==========
补充，看了一下几位大佬的回答，我补充一下我的疑惑：

1.网站的服务器端，例如nginx，会配置一个ssl证书。这个证书和Fiddler的那个证书，有什么关联吗？既然人家服务器是以自己的这个证书为准的，那Fiddler这个证书，不是不承认吗？

Answer 1

给“监控”设备安装的是“可信证书颁发机构”的CA证书，不是普通的证书。

证书的颁发过程是：

• 应用方提交csr

• 证书机构对csr签名颁发证书（csr内的公钥copy到证书内）

  • 使用证书颁发机构的CA证书对应的私钥对其签名

证书的验证（可信）过程是：

• 客户端（浏览器、操作系统、移动设备终端）内（预）置全球所有可信CA机构的CA证书（内含公钥） （注意这一条）

• 访问HTTPS时

  • 发起握手
  • 对方服务器发送证书给浏览器（终端设备）
  • 浏览器解析证书是由哪家CA颁发的

  • 在自己的内置CA列表中找到这个CA证书，拿出来公钥

    • 找不到这个CA，就报错，当前HTTPS网站使用的证书 不可信

  • 用CA证书公钥验证这个网站的证书是否合法

    • 签名验证通过没
    • 过期没
    • 域名匹配不
  • 继续握手

而Fiddler就是在终端设备的内置的CA证书列表中，插入自己的CA证书。这样，由Fiddler自己颁发的证书，在终端设备看来就是合法的证书。

更新：

1。网站的服务器端，例如nginx，会配置一个ssl证书。这个证书和Fiddler的那个证书，有什么关联吗？既然人家服务器是以自己的这个证书为准的，那Fiddler这个证书，不是不承认吗？

没有任何关联，当使用Fiddler时，通信过程是这样的

Client <---> Fiddler <---> Server

1. Client  我要访问baidu.com --> Fiddler  我要访问baidu.com --> Server
2. Client  （连接挂起，浏览器转圈加载中）< Fiddler < 这是baidu.com的证书(nginx配置的) Server

3. Client < 这是baidu.com的证书（Fiddler自己生成的） Fiddler < Server
4. Client 使用Fiddler的CA进行证书验证 < Fiddler < Server

第三步想通过，必须先在客户端主动**信任**Fiddler的CA证书

重新强调：CA证书和域名证书是两个不一样的证书。CA证书是内置、预置在设备中的（手机、操作系统、浏览器）。主动信任CA证书，是手动的把CA证书导入到系统信任CA证书列表中。

更新2:

https的加密和TLS加密不是一回事。
TLS/SSL握手是协商加密密钥和算法，协商后，就是单向加密了。

流程如下：

• client和server握手

  • client 告诉server，我（浏览器）支持哪些算法，哪些格式的证书

  • server告诉client，在你告诉我的这堆算法中，我支持最好的是算法A（如rsa2048+sha1+aes128）

    • 同时，server应答的包括但不限于

      • 服务端证书
      • 我支持的算法列表
      • 我选择的算法是什么
      • 我用这个算法使用证书私钥加密了一个随机数 注意这一步

  • client 验证证书、算法

    • 拿出来服务端的随机数用公钥（包含在服务端返回的证书里）解密出来随机数
  • 客户端再把随机数+新生成的随机数用公钥加密再发回给服务器
  • 客户端和服务端握手成功
  • 协商出来一个单向加密密钥
  • https握手结束
• 接下来，client和server使用aes128这个算法，使用上一步协商的密钥进行加密通信

https的过程，是协商使用哪个单向加密算法和密钥的过程。

Answer 2

额，其实你不用去关心这些解密/加密的过程，因为 Fiddler 自始至终就没有参与 “破解” 你的会话（请求），而是 Fiddler “冒充” 了，你与服务端进行通信，同时在服务端的视角里，Fiddler “冒充”了你，这就是常说的 中间人攻击(MITM)。

当你使用 Fiddler 时，必须要设置一个由 Fiddler 创建的代理，安装一个证书（对于 HTTPS 而言）。

这个代理的作用毋庸置疑就是用 Fiddler 来转发你的流量。但是证书就不一样了，Fiddler 为自己签发了一张根证书，并且引导你安装到了你的电脑中，现在 Fiddler ，就可以冒充成任意一个服务端（域名、甚至是 IP）。

现在当你发起一个请求时，实际上是你在请求 Fiddler。因为你安装了 Fiddler 签发的证书，所以 Fiddler 可以获取并解密你的请求。

然后 Fiddler 再把自己伪装成你，把你发送的参数再发给真正的服务端，这时候你可以把 Fiddler 就看成一个简单的 cURL 或者 Postman 都可以，他们只是一个请求的工具，他自然可以拿到响应，然后再顺带把响应发给你就行。

而确保 HTTPS 安全最重要的一环就是本地信任的根证书，不要轻易导入不被信任的根证书，因为他可以冒充任何人。

当然，也有预防手段，比如 SSL Pinning，但是浏览器内的网页不能使用，一般用于 App 中。

---

扩展阅读：

• 【web安全3】【硬核】HTTPS原理全解析_哔哩哔哩_bilibili

---

最后补充一个来自 ChatGPT 的解释吧。

Answer 3

接收方是谁？

只考虑客户端和服务端。ssl 通常意义上是客户端验证服务端的。

正常情况下，客户端只有可信的证书（有层级），这样当你想中间人攻击的时候，你无法模拟出服务端的响应。

Fiddler 的话，需要你手动给客户端导入一份证书，这个证书是 fiddle 自己颁发的，所以当你发出请求的时候，服务端其实就是 fiddle，因为他可以模拟出服务端的响应了

Answer 4

具体怎么解密的其实我也不知道

但是我觉得这个问题里，可能怎么实现解密不是最重要的。

看上去问题关键的地方在于 “信任证书” 。

信任证书有一个前提是：操作系统会默认信任一些可信的CA机构，windows/linux/android基本上都会有，具体不同系统设置的位置可能不一样，但是都有。

然后就是，证书都是从哪里来，两个渠道，1是找CA机构签发证书，2是自签证书。

通常，我们这边从CA机构签发的证书，它的 CA证书 已经在系统默认信任的证书列表里面了，所以如果服务端使用的是从CA机构那里签发的证书，那么客户端在和服务端建立连接通讯的时候，就能拿到服务端发送的证书，检查证书的信息，然后和本地信任的CA证书列表做对比，就能知道服务端发送的这个证书是不是受信任的证书。

如果这个时候，服务端使用了自己签发的证书，自然就过不了这个检查，因为自己签发的证书的CA，不在系统默认的CA信任列表里面。

然后回到问题，为什么Fiddler抓取HTTPS，需要安装证书，说一下这里的安装证书其实就是让系统信任Fiddler创建的CA证书。这里如果信任了Fiddler创建的CA证书，并且Fiddler拦截了HTTPS请求，再转发请求给客户端设备(这里Fiddler将证书替换成了Fiddler签发的证书)，那么客户端在进行验证服务端发送过来证书是否有效的时候(因为已经信任了Fiddler的CA证书)，就能验证通过了。

服务端的证书，正常情况下，基本上都不会用自己签的，都是CA机构签的。

Fiddler在这个抓包的流程里面，是作为一个中间人的角色。一方面，Fiddler使用自己的CA签发证书，和作为一个服务端，处理客户端的请求，另一方面，按照正常的流程发送和解密从服务端发送的数据。是两个部份，分别对应一份证书。