Update: 缺陷已经在最新版本中被修复。目前已经得到开发组的允许，将缺陷细节解密：
HTTP伪装存在潜在特征识别风险
v2ray的HTTP伪装存在特征识别风险。这是代码实现出现的一个小问题，可以被改进和修复。我们的建议是暂时不要使用HTTP伪装功能穿透GFW。
考虑到HTTP伪装的使用相对不广泛，而且缺陷本身并不严重，目前也没有证据表明这个缺陷遭到GFW利用，我们将这个问题分类为潜在安全风险。
注意，在开发组回应、并为此issue分类和定性之前，请无相关知识和开发经验的用户不要随意猜测，篡改文意并四处传播。
按照v2ray-core最新的安全策略，我们使用开发组提供的公钥对缺陷细节和描述进行加密，内容仅开发组可见。在得到开发组允许之前不会向公众解密或透露细节。
下面是相关细节：
缺陷描述
这个问题并不算严重。问题主要出在HTTP伪装的服务器，可以使用主动探测的方法与正常服务器进行区分，而伪装的HTTP流量可能遭到潜在的被动检测。
v2ray的HTTP伪装如果开启，服务端对入站请求的处理过于笼统，且失败时回应为硬编码：
|
func (a HttpAuthenticator) Server(conn net.Conn) net.Conn { |
|
if a.config.Request == nil && a.config.Response == nil { |
|
return conn |
|
} |
|
return NewHttpConn(conn, new(HeaderReader), a.GetServerWriter(), formResponseHeader(&ResponseConfig{ |
|
Version: &Version{ |
|
Value: "1.1", |
|
}, |
|
Status: &Status{ |
|
Code: "500", |
|
Reason: "Internal Server Error", |
|
}, |
|
Header: []*Header{ |
|
{ |
|
Name: "Connection", |
|
Value: []string{"close"}, |
|
}, |
|
{ |
|
Name: "Cache-Control", |
|
Value: []string{"private"}, |
|
}, |
|
{ |
|
Name: "Content-Length", |
|
Value: []string{"0"}, |
|
}, |
|
}, |
|
})) |
|
} |
对于任何不符合规定的头部，均使用一个硬编码的500回复进行回复。
我们可以猜想存在这样一种检测，用以区分正常HTTP服务器和伪装的v2ray服务器：
v2ray的HTTP伪装，是在TCP流量开始处，添加一个HTTP头部，此后便不再添加HTTP头部。服务端到客户端的通讯亦如此。这种奇怪的TCP连接，有可能遭到防火墙的怀疑。
对于这样的流量，防火墙可以构造标准的HTTP请求，以及一个随机载荷，对服务器进行主动探测。
如果标准HTTP请求和随机载荷得到的服务器响应，均形如
HTTP/1.1 500 Internal Server Error
Connection: close
Cache-Control: private
Content-Length: 0
Date: Tue, 02 Jun 2020 17:15:26 GMT
则该服务器为使用了HTTP伪装的v2ray服务器。
如果标准的HTTP请求，得到了404/403/200/500等回应，并且随机载荷得到了400的回应，则这是一个正常的HTTP服务器。
修复方案
-
使用非硬编码的服务器响应。并且对不同的请求解析错误，做出不同的响应，以模仿真实HTTP服务器行为。
-
建议修改HTTP伪装实现方式，只在TCP流头部添加HTTP头的方式能起到一定伪装效果，但也容易被识破。比较好的方式是在每包前添加HTTP头部，但是这可能会改动v2ray的传输层和代理层实现，代价比较高。
Update: 缺陷已经在最新版本中被修复。目前已经得到开发组的允许，将缺陷细节解密：
HTTP伪装存在潜在特征识别风险
v2ray的HTTP伪装存在特征识别风险。这是代码实现出现的一个小问题，可以被改进和修复。我们的建议是暂时不要使用HTTP伪装功能穿透GFW。
考虑到HTTP伪装的使用相对不广泛，而且缺陷本身并不严重，目前也没有证据表明这个缺陷遭到GFW利用，我们将这个问题分类为潜在安全风险。
注意，在开发组回应、并为此issue分类和定性之前，请无相关知识和开发经验的用户不要随意猜测，篡改文意并四处传播。
按照v2ray-core最新的安全策略，我们使用开发组提供的公钥对缺陷细节和描述进行加密，内容仅开发组可见。在得到开发组允许之前不会向公众解密或透露细节。
下面是相关细节：
缺陷描述
这个问题并不算严重。问题主要出在HTTP伪装的服务器，可以使用主动探测的方法与正常服务器进行区分，而伪装的HTTP流量可能遭到潜在的被动检测。
v2ray的HTTP伪装如果开启，服务端对入站请求的处理过于笼统，且失败时回应为硬编码：
v2ray-core/transport/internet/headers/http/http.go
Lines 236 to 263 in 85633ec
对于任何不符合规定的头部，均使用一个硬编码的500回复进行回复。
我们可以猜想存在这样一种检测，用以区分正常HTTP服务器和伪装的v2ray服务器：
v2ray的HTTP伪装，是在TCP流量开始处，添加一个HTTP头部，此后便不再添加HTTP头部。服务端到客户端的通讯亦如此。这种奇怪的TCP连接，有可能遭到防火墙的怀疑。
对于这样的流量，防火墙可以构造标准的HTTP请求，以及一个随机载荷，对服务器进行主动探测。
如果标准HTTP请求和随机载荷得到的服务器响应，均形如
则该服务器为使用了HTTP伪装的v2ray服务器。
如果标准的HTTP请求，得到了404/403/200/500等回应，并且随机载荷得到了400的回应，则这是一个正常的HTTP服务器。
修复方案
使用非硬编码的服务器响应。并且对不同的请求解析错误，做出不同的响应，以模仿真实HTTP服务器行为。
建议修改HTTP伪装实现方式，只在TCP流头部添加HTTP头的方式能起到一定伪装效果，但也容易被识破。比较好的方式是在每包前添加HTTP头部，但是这可能会改动v2ray的传输层和代理层实现，代价比较高。