Mitmproxy抓包时IoT设备行为与请求流异步的问题排查

现有观测到的“设备先执行操作、抓包请求延迟数秒到数十分钟才出现、指令和抓包无明确对应”的现象，并非厂商专门针对MITM代理工具的定向干扰设计，90%以上概率是现有抓包链路的配置错配、流量路径错位导致的，仅小概率是厂商的通用低延迟架构设计附带的反抓包效果。

• 流量路径的错位：你当前的环境里，IoT设备是靠mac主机的USB共享网络联网，iPhone单独配置了指向主机mitmproxy的代理，但两类设备的网络桥接是相互独立的。绝大多数IoT控制APP都支持局域网直连逻辑——如果手机和IoT设备处于同一个可互通的局域网段，APP会优先走低延迟的直连通道把控制指令发给设备，根本不会走“控制请求经云端再转发回设备”的路径。这时候设备先执行操作，而你在mitmproxy里抓到的“延迟出现的请求”，本质是APP在设备操作完成后，异步、批量上传的操作日志、设备状态同步请求，因为这类上报请求没有实时性要求，APP会攒一批再发，自然就出现了延迟从几秒到30分钟不等、和操作完全对不上的情况。
• 抓包链路的队列堆积：你使用的是macOS 10.14老版本系统，同时要承担USB给IoT供网、Wi-Fi给iPhone供网、运行mitmproxy代理的三重负载，很容易出现带宽不足、连接队列堵塞的问题。mitmproxy默认的连接处理逻辑是等整个请求、响应全交互完成后，才把对应的流条目展示在控制台里，如果APP走了HTTP/2多路复用的长连接，多个请求会被堵在同一个TCP通道里，等连接超时或者攒够一批才会被mitmproxy识别、展示，就会出现请求看似随机冒出来的现象。
• 代理规则的绕过缺口：iOS的系统级代理存在天然的规则边界，本地局域网的请求、部分APP内置硬编码的直连逻辑，都不会经过系统配置的代理通道。很多IoT APP为了降低控制延迟，会主动检测系统代理状态，把对实时性要求高的控制信令切到直连通道，只有非实时的日志上报类请求才走系统代理，这也会导致你抓不到核心控制指令，只能抓到零散的延迟上报包。
• 厂商的低延迟架构附带的抓包干扰：部分厂商为了降低IoT设备的控制延迟，会刻意把控制信令通道和云API通道完全解耦——控制信令走设备和APP之间的直连长连接传递，只有操作完成后的日志、状态同步才会走公网API上报。这种设计的核心目的是把控制延迟从云端转发的数百毫秒压缩到几十毫秒，并不是专门为了对抗MITM抓包，但客观上确实会让靠代理抓API的攻击者无法快速定位控制指令对应的数据包。

• 先掐断局域网直连通道：在mac的网络设置里做网段隔离，把IoT设备所在的USB共享网络段，和iPhone所在的Wi-Fi网络段做访问隔离，禁止iPhone直接通过局域网地址访问IoT设备，强制APP必须把所有控制指令发往云端、再由云端下发给设备。完成隔离后如果控制指令的POST请求能和设备操作实时对应，就说明之前的观测偏差全是直连逻辑导致的。
• 调整mitmproxy的运行参数消除队列延迟：运行时添加参数--set connection_strategy=lazy --set http2=true --set show_host_in_list=true，关闭非必要的本地缓冲逻辑，替换默认的控制台UI为mitmweb的网页视图——它的流列表会在请求发起的第一时间就展示条目，不会等请求完成交互才显示，能从根源上解决请求延迟出现的问题。
• 先做链路完整性基准测试：在iPhone上用浏览器访问任意网页，观察这个请求是不是能在1秒内出现在mitmproxy的流列表里。如果连基础的浏览器请求都存在明显延迟，说明当前的网络转发、防火墙配置存在拦截，导致请求在本地缓存堆积，和APP的逻辑无关——需要先排查mac防火墙对mitmproxy进程的入站、出站权限，确保所有指向代理端口的流量能直接被mitmproxy接收。
• 异步上报流量的过滤排除：完成上述调整后，每次操作设备时记录mitmproxy里实时出现的第一个发往设备云域名的POST请求，逐一对比参数和操作的对应关系，剩下的延迟出现的零散请求基本都是设备状态上报类的杂包，直接过滤即可。

内容的提问来源于stack exchange，提问作者John