关于Whistle抓包HTTPS的疑问

Whistle在当前工作中挺常用,同时大部分站点已开启HTTPS,而为了能够正常的代理操作这些站点,Whistle需要进行一些设定。

但有时会出现状况,比如抓不到请求等,搞清楚背后的原理/设计有益于解决相关问题。因此这里Mark下。

Chrome开发者工具下:开头的头部字段

在Chrome下查看请求时发现HTTPS下的请求有几个特殊字段

HTTPS请求头部

  1. 这几个字段叫伪首部字段Pseudo-Header Fields
  2. HTTP/1.x使用消息起始行( [RFC7230]3.1节 )表达目标URI。对于同样的目的,HTTP/2使用以’:’字符(ASCII 0x3a)开始的特殊的伪首部字段来表示请求的方法和响应的状态码。

HTTP请求头部

x前缀字段

如果想在HTTP头里添加自定义的字段,为了和标准字段区分,之前是建议加上X-前缀的(X代表Extension)。这个建议是在1982年为Email标准提出(参考RFC-822),行之有效了几十年。

经常看到的自定义字段比如X-Powered-By

2012年6月,互联网工程任务小组(IETF)发布了新的征求意见稿(RFC-6648),要求自定义HTTP头字段应放弃使用X-前缀。

如果完全是私有自定义字段且不可能标准化,推荐名称包含组织名(如反域名com.example.foo)

header name大小写

Header字段大小写是不敏感的,因此在实际开发中可以按照个人习惯去写。

Each header field consists of a name followed by a colon (“:”) and the field value. Field names are case-insensitive.

Whistle抓包HTTPS下的三个设定

CA

当我们下载证书=>安装证书=>信任证书,证明最终work的标志即如下访问时,查看查看证书签发机构变成了whistle。

MitM

如果不对HTTPS请求进行解密,代理环节也只是可以看到域名,请求具体信息及响应信息是无法正确解析查看的,因为SSL加密的原因。而Whistle,或者其它代理软件Surge都是采用MitM来解决抓包问题。

为什么MitM可以解决是因为MitM是利用自签证书来与原服务端/客户端同时与双方进行通讯。

Capture TUNNEL CONNECTS

该选项如果不开启是无法获取HTTPS请求体/响应体内容的。

为什么这里叫TUNNEL CONNECT?

  1. 隧道(tunnel)是建立起来之后,就会在两条连接之间对原始数据进行盲转发的HTTP应用程序
  2. Tunnel是个抽象概念,针对HTTPS请求来说,浏览器被代理,则请求会先发送HTTP请求-Connect方法到代理服务器创建隧道

Enable HTTP/2

如果关闭该设定,在Whistle中显示的HTTP版本信息还会是1.1,出现错误

Whistle抓包不work

Network看不到相关请求

一般是这些请求并没有走到Whistle代理,比如最近我遇到的一个情况。

我的网络环境如下

系统代理工具为Surge,Chrome下请求会先走Surge,然后被分发到Whistle8899端口代理。但最近发现192.168内网IP服务都无法抓包,最后定位是Surge中有skip proxy配置,内网IP,Surge代理会直接跳过,那更不用说走到Whistle了。

因此遇到此类情况,需要关心的是请求到Whistle代理是不是配置正确

Rule不work

在network下查看对应请求下的信息,如果没有匹配rule显示,则证明rule配置无效。

当前whistle对于rule配置并没有进行有效性check。

延伸

nginx http2

Nginx无法在同一端口多服务情况下提供多种不同的协议。即比如443端口挂了多个服务配置,彼此只是根据域名来区分,但只要在其中一个服务下配置HTTP2,则对外即都是HTTP2协议。

写在最后

以上问题搞清,在排查whistle代理抓包/解析问题就会相对清晰些,也能更好的使用Whistle。

参考资料