Update: 缺陷已经在最新版本中被修复。目前已经得到开发组的允许，将缺陷细节解密：

HTTP伪装存在潜在特征识别风险

v2ray的HTTP伪装存在特征识别风险。这是代码实现出现的一个小问题，可以被改进和修复。我们的建议是暂时不要使用HTTP伪装功能穿透GFW。

考虑到HTTP伪装的使用相对不广泛，而且缺陷本身并不严重，目前也没有证据表明这个缺陷遭到GFW利用，我们将这个问题分类为潜在安全风险。

注意，在开发组回应、并为此issue分类和定性之前，请无相关知识和开发经验的用户不要随意猜测，篡改文意并四处传播。

按照v2ray-core最新的安全策略，我们使用开发组提供的公钥对缺陷细节和描述进行加密，内容仅开发组可见。在得到开发组允许之前不会向公众解密或透露细节。

下面是相关细节：

缺陷描述

这个问题并不算严重。问题主要出在HTTP伪装的服务器，可以使用主动探测的方法与正常服务器进行区分，而伪装的HTTP流量可能遭到潜在的被动检测。

v2ray的HTTP伪装如果开启，服务端对入站请求的处理过于笼统，且失败时回应为硬编码：

对于任何不符合规定的头部，均使用一个硬编码的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服务器。

修复方案

1. 使用非硬编码的服务器响应。并且对不同的请求解析错误，做出不同的响应，以模仿真实HTTP服务器行为。

2. 建议修改HTTP伪装实现方式，只在TCP流头部添加HTTP头的方式能起到一定伪装效果，但也容易被识破。比较好的方式是在每包前添加HTTP头部，但是这可能会改动v2ray的传输层和代理层实现，代价比较高。