关于Whistle抓包HTTPS的疑问

发表于 更新于 本文字数： 2.1k 阅读时长 ≈ 4 分钟
本文介绍关于Whistle抓包HTTPS的疑问，包括使用场景、实现细节等，以提高关于Whistle抓包HTTPS的疑问的效率。

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

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

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

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

HTTPS请求头部

  1. 这几个字段叫伪首部字段Pseudo-Header Fields，
  2. HTTP/1.x使用消息起始行( [[RFC7230]](http://httpwg.org/specs/rfc7540.html#RFC7230)，[3.1节](http://httpwg.org/specs/rfc7230.html#start.line) )表达目标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。

参考资料