Loading

Charles抓包工具使用

Charles抓包工具使用

Charles客户端下载

官网地址：https://www.charlesproxy.com/download/

选择适合自己的系统版本下载（这里我选择Windows）：

fig:

下载完成后激活

激活网站地址：https://www.zzzmode.com/mytools/charles/

fig:

fig:

打开Charles：

fig:

fig:

打开安装好的Charles，菜单栏 Help->Register Charles 弹出注册的窗口填入Registered Name和生成的license key，点击 Register。

Right On！注册成功

fig:

Charles 配置

打开Charles，先安装证书并且信任

fig:

证书下载好之后，找到证书文件，双击进行安装证书(I)，将其安装到【受信任】目录中，出现信任选项，点击始终信任即可。

可以看到当前证书不被信任

fig:

fig:

fig:

fig:

fig:

fig:

点击完成后提示导入成功。此时需要重新进入Help -> SSL Proxying -> Install Charles Root Certificate，查看证书结果，成功时如下提示：

fig:

证书状态显示：该证书没有问题就表示导入成功了。

设置SSL，保证可以抓取https协议的请求：

fig:

fig:

点击OK，添加信息。

查看某一个端口是否被占用

netstat -ano | findstr "8080"

fig:

fig:

fig:

工具栏展示：

fig:

什么是证书？为何需要证书？

首先明确一点，安装证书的目的是为了是的抓包工具可以抓取https协议的请求。

抓包的定义？

  1. 抓包就是将网络传输发送与接收的数据包进行截获、重发、编辑、转存等操作
  2. 用来检查网络安全。也经常被用来进行数据截取等。

对HTTP请求进行抓包

对于HTTP协议，因为本身就是明文传输，所以可以直接看到数据报文，除非对这些明文在传输时进行二次加密，但那是另一种情况，这里暂不分析。

对HTTPS请求进行抓包

对于双向加密的HTTPS，正常情况下，即使能以中间人的方式拿到通信报文，但是因为没有密钥，同样也不能看到具体的传输内容。基于HTTPS加密通信的建立过程，和密钥交换方式，如果在加密通信建立之前，截取服务端发送的包含证书的报文，伪装成服务端，把自己的证书发给客户端，然后拿到客户端返回的包含对称加密通信密钥的报文，以服务端自己的公钥加密后发给服务端，这样一来，双向加密通信建立完成，而中间人实际拿到了通信的密钥，所以可以查看、修改HTTPS的通信报文，这就是典型的Man-in-the-middle attack即MITM中间人攻击。

这样似乎看起来，HTTPS也不是那么安全，当然不能这么说了，实现MITM最关键的一点，是中间人要把服务端证书替换成自己的证书发给客户端，让客户端相信自己就是服务端，那么问题是，客户端为什么会信任而进行替换呢？HTTPS之所以安全，是因为它用来建立加密通信的证书是由权威的CA机构签发的，受信的CA机构的根证书都会被内嵌在Windows, Linux, macOS, Android, iOS这些操作系统里，用来验证服务端发来的证书是否是由CA签发的。CA机构当然不可能随便给一个中间人签发不属于它的域名证书，那么只有一个很明显的办法了，把中间人的根证书，导入到客户端的操作系统里，以此来完成建立加密通信时对中间人证书的验证。

看到这里你应该明白，我们前面为什么要把证书安装并存储到 受信任的根证书颁发路径 了吧。

所以，在一定的情况下，HTTPS通信是可以被监听的，抓包的实现基础，是Android测试机导入Fiddler或者Charles的根证书。

  • 无论是fidder和charles都是充当了一个中间人代理的角色来对HTTPS进行抓包:
  • 截获客户端向发起的HTTPS请求，佯装客户端，向真实的服务器发起请求。
  • 截获真实服务器的返回，佯装真实服务器，向客户端发送数据。
  • 获取了用来加密服务器公钥的非对称秘钥和用来加密数据的对称秘钥。

fig:

http协议是不安全的

在https诞生之前，所有网站都使用http协议，而http协议在数据传输的过程中都是明文，所以可能存在数据泄露和篡改。

fig:

使用对称秘钥进行数据加密

为了防止数据泄露和篡改，我们对数据进行加密，如：生成一个对称密码【DKUFHNAF897123F】，将对称秘钥分别交给浏览器和服务器端，他们之间传输的数据都使用对称秘钥进行加密和解密。

fig:

请求和响应流程如下：

  1. 客户端使用对称秘钥对请求进行加密，并发送给服务端。
  2. 服务端接收到密文之后，使用对称秘钥对密文进行解密，然后处理请求。 最后再使用对称秘钥把要返回的内容再次加密，返回给客户端。
  3. 客户端接收到密文之后，使用对称秘钥进行解密，并获取最终的响应内容。

如此一来，数据传输都是密文，解决了明文传输数据的问题。但是，这么干有bug。

  • 浏览器如何获取对称秘钥？
  • 如果每个客户端的对称秘钥相同，浏览器能拿到对称秘钥，那么黑客也可以拿到，所以，数据加密也就没有意义了。

非对称秘钥加密

公钥私钥对儿：公钥负责加密，私钥负责解密

fig:

如此一来，解决了 动态对称秘钥 和 数据加密的问题，因为每个用户的对称秘钥都是随机生成且传输的过程中都使用公钥加密（公钥加密的数据只有私钥能解密），所有黑客无法截获对称秘钥。而数据传输是通过对称秘钥加密过的，所以黑客即使能获取数据也无法去解密看到真实的内容。 看似无懈可击，但是，这么干还是又bug：如果黑客在上图 【步骤2】劫持，黑客把自己的公钥返回给客客户端，那么客户端会使用黑客的公钥来加密对称秘钥，黑客在【步骤6】截获请求，使用自己的私钥获取对称秘钥，后面过程全都会完蛋…

CA出现

fig:

使用 ca 证书可以解决黑客劫持的问题

如此一来，就解决了黑客劫持的问题，因为即使黑客劫持后的给浏览器即使返回了证书也无法通过校验，同时浏览器也会提示错误信息。

https可以保证数据安全，但由过程需要反复加密解密所有访问速度会有所下降（鱼和熊掌不能兼得）

posted @ 2024-09-27 14:57  qinhaoyi  阅读(356)  评论(0)    收藏  举报