真实不存在—REALITY杂谈

发布于 2023-07-23  1701 次阅读


AI 摘要

"真实不存在---REALITY杂谈"文章摘要: 在这篇文章中,作者谈论了Reality的工作机制和使用方法。Reality是一种基于魔改过的tls库的传输层加密,具有前向安全等高级安全特性。它通过端口转发将流量转发给指定的网站,同时在一定条件下对Client Hello进行验证。作者还分享了选取Reality的dest网站的方法和注意事项,建议选择国外网站,并检查是否有国内CDN节点和是否套用了Cloudflare的CDN。最佳选择是将dest指向自己搭建的网站。

前言

最近Reality的各种问题被炒很火,正好我也好久没有更新文章了,不妨顺便记录一下我对reality的理解。

以下对Reality的阐述仅为个人理解,如有错误请指出

Reality工作机制简述

Reality和Shadowtls有一点类似,但又有很大的区别,Reality本身并不是一种协议,是由tls库魔改过来的传输层加密,拥有前向安全等高级安全特性,部署了Reality的服务端对外表现为端口转发,即 dest 指向的网站的某个反向代理节点。

因此,Reality服务端始终是双向转发流量,同时在符合一些条件时才会对 Client Hello 进行验证,验证成功才会自己处理,除此之外的任何流量,Reality都会是转发给 dest 指向的网站。所以当我们使用Reality进行代理时的行为特征与在访问 dest 指向的目标网站相同(当然是正确配置Reality的条件下)

dest 选取

有很多小白在选取 dest 时感到为难,其实dest 配置只需要满足以下3点最低要求即可

  • 国外网站
  • 支持 TLSv1.3 与 H2
  • 域名非跳转用(主域名可能被用于跳转到 www)

满足以上三点要求的网站域名,就可以作为Reality的 dest ,当然还有一些加分项:

  • IP 相近(更像,且延迟低)
  • Server Hello 后的握手消息一起加密(如 dl.google.com)
  • 有 OCSP Stapling

你可以使用 Reality - TLS - Scanner 来进行扫描,也可以利用以下Python脚本简单的进行判断

import requests
import ssl
import socket

def check_minimum_requirements(url):
    try:
        # 获取网站信息
        response = requests.get(f"https://{url}", timeout=10)

        # 1. 支持 TLSv1.3 与 H2
        if 'h2' not in response.headers.get('Alt-Svc', '') or \
           'TLSv1.3' not in response.headers.get('Strict-Transport-Security', ''):
            return False

        # 2. 域名非跳转用
        if response.history:
            return False

        return True

    except Exception as e:
        # 发生异常时,认为网站不符合最低要求
        return False

def check_perfect_requirements(url):
    # 完美符合要求需要满足最低要求,并且满足 Server Hello 握手消息一起加密和有 OCSP Stapling
    if not check_minimum_requirements(url):
        return False

    try:
        # 使用 OpenSSL 库来检查握手消息的加密
        context = ssl.create_default_context()
        with socket.create_connection((url, 443)) as sock:
            with context.wrap_socket(sock, server_hostname=url) as ssl_sock:
                negotiated_protocol = ssl_sock.selected_alpn_protocol()
                if negotiated_protocol != 'h2':
                    return False

                # 4. 有 OCSP Stapling
                if not ssl_sock.ocsp_response:
                    return False

        return True

    except Exception as e:
        # 发生异常时,认为网站不符合完美要求
        return False

if __name__ == "__main__":
    url = input("请输入要检测的网站域名:")
    if check_perfect_requirements(url):
        print("该网站完美符合要求!")
    elif check_minimum_requirements(url):
        print("该网站符合最低要求!")
    else:
        print("该网站不符合要求!")

通常,我们只需要找一些vps附近的旅游网站,大学网站作为 dest 就行

需要注意的一点是,在选取国外网站时,一定要先检查该网站在国内有无cdn节点。

因为如果这个网站在国内有cdn,并且你将它作为Reality的 dest ,当你正常访问这个网站时,应该连接的是国内IP,然而你却连接着国外的IP(你VPS的IP),这显然不正常

最好还要检查一下这个网站是否套用了Cloudflare的CDN(防止流量偷跑,具体等会说)

比如,之前有很多人将 dl.google.com,www.microsoft.com作为reality的dest,导致被封锁

当然最好将 dest 指向自己搭建的网站,指向他人搭建的网站可能会导致很多问题(下面会讲到)

Reality优势

我们不妨来先看看reality的设计哲学

REALITY 的设计哲学

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

我们可以看到,Reality解决了服务端tls指纹的问题,完美消除了服务端特征,如果我们在使用reality的同时配置 utls 和xtls-rprx-vision流控可以做到近乎完美的代理行为,reality解决了服务端指纹的问题,utls解决了客户端指纹的问题,xtls-rprx-vision流控解决了 tls in tls 的问题,这似乎是目前代理协议的最优解了

一些局限性

上文我们提到了最好不要选择套有Cloudflare CDN网站的域名作为 Reality dest ,因为Reality服务端表现为端口转发,其他人可能将你的Reality节点作为一个免费的中转机,但我并不认为这是一个什么大问题,毕竟很多大网站都用的是Cloudflare CDN 的商业套餐,我们反代的是商业段的CDN节点,偷跑我们的流量的人的free套餐用不了。而且我们可以使用nginx等软件进行SNI分流,防止流量偷跑。

综合来看,Reality + xtls-rprx-vision + utls 已经是目前代理协议的最优解了,但是并不代表着它可以完美隐藏你的代理行为

比如说一些钓鱼有一些宏观上的行为是消除不掉的(比如说可以通过钓鱼来判断你在进行代理),这与你使用什么代理协议无关。

还有在 dest 指向一些大网站时,如果该ip确实是这些大网站的一个节点,那么访问量应该很多,而且访问的源ip应该来自全国各地,并且不会有太明显的时序特征,比如晚上睡觉时间还会有来自全国各地的许多访问

而如果是用于代理,那么源ip通常只有国内固定地区的某些ip,且访问量相对于正常的域名来说应当很低

所以,需要明确的是,世界上没有完美的事物,我们常常把世界看错,反说它欺骗了我们。有些时候,让你从更高的维度去看一件个事物时,所谓的天衣无缝,也会变得漏洞百出。

无知和弱小不是生存的障碍,傲慢才是

届ける言葉を今は育ててる
最后更新于 2023-07-23