The topic of the reading group next week will be V2Ray and VMess. The reading group happens after the weekly team IRC meeting, which will be at 16:00 UTC on Thursday, 2020-06-11. https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam#I...
V2Ray is a platform for deploying proxy protocols. It offers a number of composable proxy protocols, transports, and obfuscation options. https://www.v2ray.com/en/ https://github.com/v2ray/v2ray-core
VMess is one of the proxy protocols supported by V2Ray. From my cursory understanding, it is in a similar vein to protocols like obfs4 and Shadowsocks. https://github.com/v2ray/manual/blob/master/eng_en/protocols/vmess.md
I started a discussion thread, hoping to attract comments from people who are familiar with V2Ray and know the state of the art. https://github.com/net4people/bbs/issues/36
There is a beginner's guide to setting up V2Ray: https://guide.v2fly.org/en_US/
Just in the past week there has news with VMess. The latest releases of V2Ray fix a replay / active probing vulnerability.
https://github.com/v2ray/v2ray-core/releases/tag/v4.23.3 * Issued an emergency fix for VMess weakness described in #2523 This fix can significantly hindrance attack based on the weakness described. Only servers need to be updated to apply this emergency fix, it not expected for well-behaved clients to be influenced. A more permanent solution is underway.
https://github.com/v2ray/v2ray-core/releases/tag/v4.23.4 * Issued further fixs for VMess weakness described in #2523 #2539 * For VMess connections, clients cannot rely on servers to indicate issues in connectivity or password mismatch by closing connection. Well behaved clients are not influenced. * For VMess servers, it is not recommended to change UUID frequently as VMess will procedurally generate its connection drain and close pattern based on UUID it has when the first connection arrives. * Server will by default wait 60 seconds for the handshakes to complete before closing the connection instead of 4 seconds. This allows the server to blend into normal TCP servers better and its benefit is significantly higher than potential downsides. * From now on, the VMess protocol will drain any unrecognized or invalid connection based on procedurally generate connection drain and close patterns. It can neutralize all known "replay and observe close" attacks. The base drain size and drain size jitter will be generated based on UUID a VMess inbound have when the first connection arrives. For each server, these values will be different and remain constant for that server.
One of the two upstream issues are in Chinese, so you'll have to fend for yourself with machine translation.
https://github.com/v2ray/v2ray-core/issues/2523 vmess协议设计和实现缺陷可导致服务器遭到主动探测特征识别(附PoC) Design and implementation flaws in the vmess protocol can lead to the server being subjected to active detection signatures (with PoC)
https://github.com/v2ray/v2ray-core/issues/2539 Some extra ways of active probing
As I understand it, VMess's authentication is broken with regard to replays. The only authenticator is a 16-byte hash of the user's random ID and the current time; an authenticator remains valid for 30 seconds. The VMess server will read the authenticator and the following command, and expect them to have a certain checksum. But here's the problem: the encrypted command has variable length because of an internal padding field that can range in length from 0 to 15 bytes. ("Margin P" in https://github.com/v2ray/manual/blob/master/eng_en/protocols/vmess.md#comman....) The server must read and decrypt the command before being able to check its integrity. The attack is to replay a valid authenticator, tweak the value of the padding length field, then see how many bytes the server tries to read. You can do this multiple times in 30 seconds. If the number of bytes read varies by up to 16 bytes, then the server is decided to be VMess.
The flaw was reported by p4gefau1t, who is also the main contributor of https://github.com/p4gefau1t/trojan-go, a Go implementation of the Trojan circumvention system.
It looks like the fix was to have the server not disconnect immediately on authentication failure, but continue to read from the socket for a while, somewhat in line with the recommendations of https://censorbib.nymity.ch/#Frolov2020a. The exact connection draining thresholds are set per-server in a ScrambleSuit-like way, so two VMess servers will not have the exact same behavior.
On Thu, Jun 04, 2020 at 05:45:22PM -0600, David Fifield wrote:
The topic of the reading group next week will be V2Ray and VMess. The reading group happens after the weekly team IRC meeting, which will be at 16:00 UTC on Thursday, 2020-06-11. https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam#I...
V2Ray is a platform for deploying proxy protocols. It offers a number of composable proxy protocols, transports, and obfuscation options. https://www.v2ray.com/en/ https://github.com/v2ray/v2ray-core
VMess is one of the proxy protocols supported by V2Ray. From my cursory understanding, it is in a similar vein to protocols like obfs4 and Shadowsocks. https://github.com/v2ray/manual/blob/master/eng_en/protocols/vmess.md
I started a discussion thread, hoping to attract comments from people who are familiar with V2Ray and know the state of the art. https://github.com/net4people/bbs/issues/36
There is a beginner's guide to setting up V2Ray: https://guide.v2fly.org/en_US/
On Thu, Jun 04, 2020 at 05:45:22PM -0600, David Fifield wrote:
There is a beginner's guide to setting up V2Ray: https://guide.v2fly.org/en_US/
The guide doesn't really explain how to configure the client. Here is what worked for me.
On the server:
``` # wget https://install.direct/go.sh # bash go.sh ... PORT:36685 UUID:799e8b6b-d87e-41ce-b214-82ac581802cf ... # cat /etc/v2ray/config.json { "inbounds": [{ "port": 36685, "protocol": "vmess", "settings": { "clients": [ { "id": "799e8b6b-d87e-41ce-b214-82ac581802cf", "level": 1, "alterId": 64 } ] } }], "outbounds": [{ "protocol": "freedom", "settings": {} },{ "protocol": "blackhole", "settings": {}, "tag": "blocked" }], "routing": { "rules": [ { "type": "field", "ip": ["geoip:private"], "outboundTag": "blocked" } ] } } # systemctl start v2ray ```
Then on the client,
``` # wget https://install.direct/go.sh # bash go.sh # vi /etc/v2ray/config.json # cat /etc/v2ray/config.json { "inbounds": [{ "listen": "127.0.0.1", "port": 1080, "protocol": "socks" }], "outbounds": [{ "protocol": "vmess", "settings": { "vnext": [{ "address": "173.255.250.95", "port": 36685, "users": [{ "id": "799e8b6b-d87e-41ce-b214-82ac581802cf", "level": 1, "alterId": 64 }] }] } }] } # systemctl start v2ray ```
The server is configured with a single "inbound", which uses VMess. It has two "outbound"s. The "freedom" outbound means to make a direct outgoing TCP connection, with no further proxying. The "blackhole" outbound denies the outgoing connection. Outgoing traffic goes to the "freedom" outbound by default, unless it is tagged with the "blocked" tag that is added by the "geoip:private" routing rule.
The client has one "socks" inbound and one "vmess" outbound. I guess the connection between them is implicit.
On the server, you can configure multiple clients with different "id"s. On the client, you can also configure an array of multiple "id"s. I'm not sure why that is or how it decides which "id" to use.
anti-censorship-team@lists.torproject.org
-
David Fifield