v2ray-core在v4.23.2版本之前存在重大安全漏洞，可导致服务器遭到主动探测特征识别，请大家尽快更新

v2ray-core在v4.23.2版本之前存在重大安全漏洞主要包含两个漏洞：HTTP伪装存在潜在的特征识别风险 #2537、vmess协议设计和实现缺陷可导致服务器遭到主动探测特征识别(附PoC) #2523，截止本文发出前，最新版本是v4.23.4，已经对这两个漏洞进行了修复，请大家尽快更新。

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

这个问题并不算严重。问题主要出在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服务器。

vmess协议设计和实现缺陷可导致服务器遭到主动探测特征识别

v4.23.4及以后已经采取随机读取多个字节的方式阻止P的侧信道泄漏，目前下面的PoC（16次探测）以及概率探测（暴力发包探测）的PoC已经失效，无法准确探测vmess服务。但是，由于这是协议设计层面的问题，彻底解决问题需要引入AEAD等无法向下兼容的设计。好消息是，这一缓解可以为我们讨论制订新协议争取非常多的时间。vmess+tcp的组合仍然存在一定风险，不建议使用。

先说结论：开启了tcp+vmess的服务端，在和客户端进行通讯时，攻击者可以通过重放攻击的方式准确判定是否为vmess服务。

这个缺陷的利用基于重放攻击和密文填充攻击，需要以下条件（经过讨论，结合之前ss遭到的重放攻击，我们认为对于GFW来说，此条件并不苛刻）：

攻击者可以进行中间人攻击，捕获vmess的TCP流前16 + 38字节。

攻击者可以在30秒内据此发送16个探测包

目前的缓解方案均可以被绕过，唯一解决方案是修改协议实现 。

个人认为，最好的解决方案是采用gcm等具有认证能力的aead加密模式对指令部分进行加密，而不是cfb。这和现有vmess设计冲突且无法向下兼容，可能需要重新设计vmess协议。

mkcp+vmess和tls+vmess等底层传输不使用tcp的组合不受此问题直接影响，但有可能收到波及。