Closed Insh3ll closed 4 years ago
按照协议规范,https://tools.ietf.org/html/draft-luotonen-web-proxy-tunneling-01#section-3.2 确实应该是 HTTP/1.0 200 Connection established
的,不知道 martian 为啥不是
https://github.com/zema1/martian/pull/2 改了一个可以用的版本,明天发版更新下
AWVS 的这个问题并不是 200 OK
导致的,而是后面的 Content-Length
导致的,length 为 0 是应该被忽略的,但不知道为啥 AWVS 直接认为失败了,应该是 AWVS 的 bug (: 去掉后一切正常了。
虽然 Connection established
会好一些,但写代码实现时一般不会去校验这个 text,而是直接使用 StatusCode。 主要原因如下:
// StatusText returns a text for the HTTP status code. It returns the empty
// string if the code is unknown.
func StatusText(code int) string {
return statusText[code]
}
另外非常感谢你的反馈,我一开始以为肯定不是 xray 的问题没在意(虽然的确和 xray 不是很相关),给你带来困扰了。 稍后发个红包给你~
zema1/martian#2 改了一个可以用的版本,明天发版更新下
AWVS 的这个问题并不是
200 OK
导致的,而是后面的Content-Length
导致的,length 为 0 是应该被忽略的,但不知道为啥 AWVS 直接认为失败了,应该是 AWVS 的 bug (: 去掉后一切正常了。虽然
Connection established
会好一些,但写代码实现时一般不会去校验这个 text,而是直接使用 StatusCode。 主要原因如下:
- 校验 text 远比 比对 statusCode 废时
- http/1.1 中 statusCode 和 text 是一一对应的,statusCode 就代表了 text,这点可以从 go 标准库中看出一些端倪:
// StatusText returns a text for the HTTP status code. It returns the empty // string if the code is unknown. func StatusText(code int) string { return statusText[code] }
另外非常感谢你的反馈,我一开始以为肯定不是 xray 的问题没在意(虽然的确和 xray 不是很相关),给你带来困扰了。 稍后发个红包给你~
当时看到状态字不一致,以为是响应状态字的问题,没分析清楚,尴尬。技术的事,红包就客气了!用着xray,算是贡献一点绵薄之力!
抓包看了一下数据包:
awvs+burpsuite
awvs+xray
从抓包结果来看,使用HTTP代理访问HTTPS站点时使用隧道模式,HTTP客户端首先发起的是CONNECT请求,而这里xray和burpsuite对CONNECT请求的响应不同。
《HTTP 权威指南》
根据《HTTP 权威指南》描述:CONNECT请求当隧道建立成功时应响应
200 Connection established
awvs在收到xray的响应
200 OK
时,认为隧道没有建立成功,所以会继续发起CONNECT请求尝试建立隧道(从抓包中可以看到),在尝试一定次数后认为隧道建立失败结束扫描。而浏览器容错性比较好,在收到200 OK时也认为隧道建立成功,继续进行下一步的SSL握手和数据传输。