• 时间:
  • 分类: GFW

REALITY 取代 TLS，可消除服务端 TLS 指纹特征，仍有前向保密性等，且证书链攻击无效，安全性超越常规 TLS

可以指向别人的网站，无需自己买域名、配置 TLS 服务端，更方便，实现向中间人呈现指定 SNI 的全程真实 TLS

官方的说明
https://github.com/XTLS/REALITY

通常代理用途，目标网站最低标准：

  • 国外网站，支持 TLSv1.3 与 H2，域名非跳转用（主域名可能被用于跳转到 www）
  • 加分项：IP 相近（更像，且延迟低），Server Hello 后的握手消息一起加密（如 dl.google.com），有 OCSP Stapling
  • 配置加分项：禁回国流量，TCP/80、UDP/443 也转发（REALITY 对外表现即为端口转发，目标 IP 冷门或许更好）

REALITY 也可以搭配 XTLS 以外的代理协议使用，但不建议这样做，因为它们存在明显且已被针对的 TLS in TLS 特征

REALITY 的下一个主要目标是“预先构建模式”，即提前采集目标网站特征，XTLS 的下一个主要目标是 0-RTT

{
    "inbounds": [ // 服务端入站配置
        {
            "listen": "0.0.0.0",
            "port": 443,
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "", // 必填，执行 ./xray uuid 生成，或 1-30 字节的字符串
                        "flow": "xtls-rprx-vision" // 选填，若有，客户端必须启用 XTLS
                    }
                ],
                "decryption": "none"
            },
            "streamSettings": {
                "network": "tcp",
                "security": "reality",
                "realitySettings": {
                    "show": false, // 选填，若为 true，输出调试信息
                    "dest": "example.com:443", // 必填，格式同 VLESS fallbacks 的 dest
                    "xver": 0, // 选填，格式同 VLESS fallbacks 的 xver
                    "serverNames": [ // 必填，客户端可用的 serverName 列表，暂不支持 * 通配符
                        "example.com",
                        "www.example.com"
                    ],
                    "privateKey": "", // 必填，执行 ./xray x25519 生成
                    "minClientVer": "", // 选填，客户端 Xray 最低版本，格式为 x.y.z
                    "maxClientVer": "", // 选填，客户端 Xray 最高版本，格式为 x.y.z
                    "maxTimeDiff": 0, // 选填，允许的最大时间差，单位为毫秒
                    "shortIds": [ // 必填，客户端可用的 shortId 列表，可用于区分不同的客户端
                        "", // 若有此项，客户端 shortId 可为空
                        "0123456789abcdef" // 0 到 f，长度为 2 的倍数，长度上限为 16
                    ]
                }
            }
        }
    ]
}

{
    "outbounds": [ // 客户端出站配置
        {
            "protocol": "vless",
            "settings": {
                "vnext": [
                    {
                        "address": "", // 服务端的域名或 IP
                        "port": 443,
                        "users": [
                            {
                                "id": "", // 与服务端一致
                                "flow": "xtls-rprx-vision", // 与服务端一致
                                "encryption": "none"
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "tcp",
                "security": "reality",
                "realitySettings": {
                    "show": false, // 选填，若为 true，输出调试信息
                    "fingerprint": "chrome", // 必填，使用 uTLS 库模拟客户端 TLS 指纹
                    "serverName": "", // 服务端 serverNames 之一
                    "publicKey": "", // 服务端私钥对应的公钥
                    "shortId": "", // 服务端 shortIds 之一
                    "spiderX": "" // 爬虫初始路径与参数，建议每个客户端不同
                }
            }
        }
    ]
}

客户端

REALITY 客户端应当收到由“临时认证密钥”签发的“临时可信证书”，但以下三种情况会收到目标网站的真证书：

  • REALITY 服务端拒绝了客户端的 Client Hello，流量被导入目标网站
  • 客户端的 Client Hello 被中间人重定向至目标网站
  • 中间人攻击，可能是目标网站帮忙，也可能是证书链攻击
  • REALITY 客户端可以完美区分临时可信证书、真证书、无效证书，并决定下一步动作：
  • 收到临时可信证书时，连接可用，一切如常
  • 收到真证书时，进入爬虫模式
  • 收到无效证书时，TLS alert，断开连接

REALITY 的设计哲学：

  • 在设计上就把安全等级拉满，限制人的可控范围，最大程度降低人为因素的影响，文章中再细说
  • 信任服务端，客户端不可信，甚至默认客户端持有的节点信息全泄露了，文章中再细说
  • 服务端对客户端是有选择的，比如拒绝版本过低的 Xray-core 连接，防止过时的客户端实现不当害了服务端，比如指纹过时
  • 以后服务端还可以带信息给客户端，告知客户端有新版了/告知客户端版本过低，要求更新，否则多长时间后不再支持

对于第一点，其实 Xray-core 也是类似的：

  • 某个功能有更好的实现，直接设成默认，或者简单就能配置，不加或少加选项
  • 有了全方位更优的 XTLS Vision，就把旧版 XTLS 移除，不给用户部署它的机会
  • v1.8.0 还会把 xtls-rprx-vision,none 这种配置方式移除，它已经被滥用了，群里说 Vision 封了端口的一问必是 iOS，难顶
  • 兼容性，并不是首要考虑因素，人都是懒的，只要仍兼容就动力不足，难推新的，不兼容才能有效促进革新与进步。

标签: Xray, GFW

添加新评论