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

Question

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

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

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

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

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

Answer 1

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

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

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

信任证书有一个前提是：操作系统会默认信任一些可信的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签发证书，和作为一个服务端，处理客户端的请求，另一方面，按照正常的流程发送和解密从服务端发送的数据。是两个部份，分别对应一份证书。

Answer 2

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

证书的颁发过程是：

• 应用方提交csr

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

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

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

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

• 访问HTTPS时

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

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

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

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

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

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

Answer 3

接收方是谁？

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

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

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