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

[p4gefau1t]

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

	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服务器。

修复方案

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

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

[DuckSoft]

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

[blindwrite]

考虑到HTTP伪装的使用相对不广泛

While there may not be many people using it on v2ray, actually its application on v2ray-plugin is not rare, and I assume it's also affected?

[DuckSoft]

考虑到HTTP伪装的使用相对不广泛

While there may not be many people using it on v2ray, actually its application on v2ray-plugin is not rare, and I assume it's also affected?

看粗体字就好了。看到之前几个bug/0day的技术细节描述，一些阴谋论者、借机炒作者、一些不了解或者不甚了解实际问题的人消费恐慌。如果此处措辞激进，难免又让某些人有了可乘之机。在官方通知并决定应该揭露细节之前，不会再透露任何细节信息。

[blindwrite]

考虑到HTTP伪装的使用相对不广泛

While there may not be many people using it on v2ray, actually its application on v2ray-plugin is not rare, and I assume it's also affected?

看粗体字就好了。看到之前几个bug/0day的技术细节描述，一些阴谋论者、借机炒作者、一些不了解或者不甚了解实际问题的人消费恐慌。如果此处措辞激进，难免又让某些人有了可乘之机。在官方通知并决定应该揭露细节之前，不会再透露任何细节信息。

Don't really agree on this one.

In my opinion, the range affected should not be classified as "details". As that project uses v2ray, it's reasonable to ask for a confirmation whether downstreams will be affected.

Anyway, I respect the decision made by the development team.

[DuckSoft]

官方已披露，细节已公开。

[xiaokangwang]

This weakness have been fixed by v2fly/v2ray-core@087a62e . Users are advised to update V2Ray to v4.23.4 to migrate this weakness.

The original bug report is declassified and appended below.

gpg: encrypted with 4096-bit RSA key, ID FCA0D3DB38CCC72C, created 2020-06-02
      "V2Fly Developers <dev@v2fly.org>"
# HTTP伪装存在潜在特征识别风险

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

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

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

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

下面是相关细节：

## 缺陷描述

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

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

https://github.com/v2ray/v2ray-core/blob/85633ec25ea06aff31fb1754992ebf86a3a737bd/transport/internet/headers/http/http.go#L236-L263

对于任何不符合规定的头部，均使用一个硬编码的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的传输层和代理层实现，代价比较高。

[xiaokangwang]

考虑到HTTP伪装的使用相对不广泛

While there may not be many people using it on v2ray, actually its application on v2ray-plugin is not rare, and I assume it's also affected?

看粗体字就好了。看到之前几个bug/0day的技术细节描述，一些阴谋论者、借机炒作者、一些不了解或者不甚了解实际问题的人消费恐慌。如果此处措辞激进，难免又让某些人有了可乘之机。在官方通知并决定应该揭露细节之前，不会再透露任何细节信息。

Don't really agree on this one.

In my opinion, the range affected should not be classified as "details". As that project uses v2ray, it's reasonable to ask for a confirmation whether downstreams will be affected.

Anyway, I respect the decision made by the development team.

It could take time to design and release a patch, it is for the best interest of all users to keep weakness and vulnerabilities classified before a fix is ready.

Accredited downstream developers may request additional data about weakness in a private channel.

[PHCSJC]

Do this issue effect v2ray-plugin?

[Mygod]

As per shadowsocks/v2ray-plugin#215, I don't think this is a serious security issue. HTTP is designed to be plain text and there are probably hundreds of more ways to extract v2ray fingerprint (especially server side, considering how complicated the HTTP protocol is). The best way to fix this might just be to pull in an entire repo of popular HTTP server like Apache, but then this approach is not as lightweight.

I suggest that future research should look at traffic classification vulnerabilities for other protocols and leave HTTP as is, and only fix it when there is a use case for it, e.g. some popular firewall application can identify v2ray http traffic.

[github-actions]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days