xingzhi's blog

2.1 VLESS：无状态的轻量级传输#

  VLESS（VMess Less）是一种无状态的轻量级传输协议。它不依赖系统时间，不需要复杂的握手确认。这也在一定程度上减少了服务器CPU和内存的消耗。同时，VLESS 本身不进行加密运算，它将数据的机密性完全交给底层的 TLS 或 XTLS 处理。这种分层设计符合 OSI 模型的解耦原则。然而，这就出现问题了。

  单纯的TLS加密(如VLESS+WS+TCP)虽然可以防御 DPI 的静态指纹分析，但无法防御防火墙发起的主动探测。你为服务器配置 TLS 时，服务端必须向发起握手的客户端出示证书。由于普通用户难以获取 Google 或 Microsoft 等大厂域名的私钥，通常只能使用 Let’s Encrypt 等机构签发的廉价域名证书。当防火墙检测到你的服务器与客户端之间的 IP 和端口有流量时，它不确定这是正常的网站还是代理，于是它会伪装成一个普通用户，向你的服务器 443 端口发起 HTTPS 请求。因为你配置了 TLS，你的服务端必须持有证书和私钥。当防火墙发起握手时，你的服务端不得不把那个廉价域名的证书发给防火墙以完成握手。这时，防火墙就会去访问你的ca证书上的域名，防火墙随后对比该域名与流量特征，一旦发现如域名无实际业务或证书信誉度低等身份不符的情况，便会直接阻断。而为了应对这种情况，这时就出现了一个新的协议 REALITY。

2.2 REALITY：消除指纹的终极伪装#

  这是该技术栈中最具创新性的部分。传统的 TLS 伪装通常需要攻击者自己注册域名并申请证书，容易身份暴露而被防火墙阻断，为了解决这一‘身份暴露’问题，REALITY 协议应运而生。它不再申请证书，而是通过消除服务端 TLS 指纹特征，并实现对合法大厂域名的**‘身份借用’。在未通过身份验证的探测者看来，你的服务器表现得就像真正的目标网站（如微软官网）一样，从而彻底解决了证书被探测的问题。” REALITY 通过端口复用和中间人**技术，直接“借用”互联网上高信誉站点的证书。

1. 无需域名： 攻击者无需拥有域名。

2. 无需证书： 服务端在 TLS 握手阶段，会实时抓取目标网站 （如 www.microsoft.com 或 www.apple.com） 的真实证书呈现给客户端。

3.1 实验环境拓扑#

服务端 ： 运行于 ThinkPad T440 (Ubuntu Server 22.04 LTS)，模拟被控制的内网节点或外部 C2 服务器。

客户端 ： Windows 11 开发机，配置 V2Ray/Xray 内核。

分析工具： Wireshark 4.0, TCPView。

3.2 流量转发逻辑#

REALITY 的核心逻辑在于它能够根据客户端发来的 Client Hello 数据包特征，决定流量的去向：

正常流量（Fallback）： 如果防火墙或爬虫访问该端口，REALITY 服务端判定其不具备特定的身份签名，直接将流量透明转发给配置的目标网站（例如 Microsoft）。此时，访问者看到的是真实的微软官网，收到的也是微软真实的 TLS 证书。

恶意流量（Proxy）： 如果客户端发送的 Client Hello 中包含了预设的 ShortId 或特定公钥特征，服务端拦截流量，建立加密隧道，进行数据传输。

1
{
2
  "streamSettings": {
3
    "network": "vless",
4
    "security": "reality",
5
    "realitySettings": {
6
      "dest": "www.microsoft.com:443",
7
      "serverNames": [
8
        "www.microsoft.com"
9
      ],
10
      "privateKey": "**************"
11
    }
12
  }
13
}

4.1 Client Hello (SNI 欺骗)#

  客户端发起 TLS 1.3 握手。在 Client Hello 报文中，Extension: server_name 字段明确指向了 www.microsoft.com。 对于网关防火墙而言，这看起来就是一个普通的访问微软服务的请求。

1
Frame: Client Hello
2
└── TLSv1.3 Record Layer: Handshake Protocol: Client Hello
3
    └── Handshake Protocol: Client Hello
4
        ├── Version: TLS 1.2 (0x0303)
5
        ├── Random: 5d12a3b4... (Reality Handshake Logic)
6
        └── Extension: server_name (len=17)
7
            └── Server Name Indication Extension
8
                └── Server Name: [www.microsoft.com](https://www.microsoft.com)  <-- [伪装目标]

4.2 Server Hello (证书验证)#

这是最精彩的部分。服务端返回的 Server Hello 报文中，包含的证书链是由 DigiCert Global Root CA 签发的真实证书。

1
└── TLSv1.3 Record Layer: Handshake Protocol: Multiple Handshake Messages
2
    ├── Handshake Protocol: Server Hello
3
    │   └── Version: TLS 1.3 (0x0304)
4
    └── Handshake Protocol: Certificate
5
        └── Certificates (Length: 2850)
6
            └── Certificate (id-at-commonName=[www.microsoft.com](https://www.microsoft.com))
7
                ├── Issuer: CN=DigiCert TLS RSA SHA256 2026 CA1
8
                └── Subject: CN=[www.microsoft.com](https://www.microsoft.com)

常规代理： 使用自签名证书 -> 容易被阻断。

REALITY： 呈现真实的微软证书 -> 防火墙放行。

由于该协议利用了 TLS 1.3 的 0-RTT 或 1-RTT 特性，且数据载荷具有高熵值（简单说就是比较混乱），在统计学特征上与正常的 HTTPS 视频流或文件下载几乎无法区分。