关于Whistle抓包HTTPS的疑问

· 4 min read

Whistle在当前工作中挺常用，同时大部分站点已开启HTTPS，而为了能够正常的代理操作这些站点，Whistle需要进行一些设定。
但有时会出现状况，比如抓不到请求等，搞清楚背后的原理/设计有益于解决相关问题。因此这里Mark下。

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

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

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

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

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

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

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

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

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

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

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

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

为什么这里叫TUNNEL CONNECT？

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

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

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

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

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

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

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

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

Last updated on Nov 13, 2021