↓ 跳过正文

TLS 1.3 科普:为什么代理都用它

·2455 字·5 分钟
作者
吾便宜

打开任何代理客户端的配置,十有八九能看到 TLS 的身影:VLESS+TLS、Trojan、Reality……为什么大家都用它?因为 TLS 1.3 是目前性价比最高的"隐身衣"。

TLS 1.3 强在哪
#

对比老版本,1.3 有三处关键改进:

  1. 握手只要 1-RTT:以前 TLS 1.2 要两次往返,1.3 一次搞定,延迟直接砍半。对代理来说,握手越快,用户体验越好。
  2. 前向安全强制化:废除了 RSA 密钥交换等老旧算法,每次会话密钥独立,长期密钥泄露也不会解密历史流量。
  3. 握手过程加密更多:证书等信息在加密后传输,中间人能看到的东西更少。

为什么代理都用它
#

核心逻辑一句话:你的代理流量看起来和正常 HTTPS 访问一模一样。

审查者看到的是:你和一个网站建立了 TLS 1.3 连接。至于里面跑的是网页还是代理数据,他看不见。Trojan 干脆把自己伪装成正常网站流量,Reality 更进一步,连证书都是借大站的。这就是为什么 TLS 系协议在 2024 年是主流:不是因为它最快,而是因为它最"正常"。

自查步骤:你的连接用上 TLS 1.3 了吗
#

  1. 看客户端配置:security 项是不是 tls,版本支不支持 1.3(2024 年的客户端默认都是)。
  2. 浏览器验证:访问 https://www.cloudflare.com/cdn-cgi/trace,看 tls 字段。
  3. 抓包看一眼:Wireshark 抓个包,ClientHello 里看 supported_versions,有 1.3 就行。
  4. uTLS 指纹:客户端的 uTLS 设置选 chrome / firefox,让指纹更像真浏览器。

常见误区
#

  • “TLS 会让速度变慢”:1.3 的握手开销很小,现代 CPU 的加解密几乎无感,别为了省这点开销裸奔。
  • “开了 TLS 就绝对安全”:TLS 只解决传输层伪装,DNS 泄漏、WebRTC 泄漏一样会暴露你,该做的防护一样不能少。

新闻解读:TLS 1.3 的普及现状
#

2024 年,TLS 1.3 已经是互联网的默认配置:

  • 浏览器:Chrome、Firefox、Safari 全默认开启 1.3,老版本基本绝迹。
  • CDN:Cloudflare、AWS CloudFront 默认 1.3,你访问的大网站基本都是。
  • 代理协议:VLESS、Trojan、Reality、NaiveProxy 全构建在 TLS 之上,uTLS 指纹伪装是标配。

这意味着:在 2024 年的互联网上,一个 TLS 1.3 连接是最"普通"的存在。代理流量的隐身逻辑就是"泯然众人"——当所有人都在用 TLS 1.3,你的代理流量混在其中,审查成本最高。

各协议的 TLS 用法
#

  • VLESS + TLS:标准用法,套一层 TLS,和正常网站访问无异。
  • Trojan:把流量伪装成 HTTPS,服务端是"真网站",客户端是"访客"。
  • Reality:TLS 的进阶玩法,借用大站的证书和指纹,连 SNI 都是真的。
  • NaiveProxy:直接用 Chrome 的网络栈,TLS 指纹就是 Chrome 本人。
  • Hysteria2:UDP 系,但握手也用 TLS,证书自签,特征相对明显。

选协议就是选"像正常流量的程度":Reality > Trojan > VLESS+TLS > Hysteria2。越像,抗封锁越强,但配置也越讲究。

自查进阶:指纹一致性
#

光有 TLS 1.3 还不够,指纹要和"正常人"一致:

  1. uTLS:客户端设成 chrome,对应的 TLS ClientHello 指纹就是 Chrome 的。
  2. ALPN:h2 / http/1.1 别乱设,和目标网站保持一致。
  3. SNI:Reality 的 SNI 必须是真实存在的大站,别填个不存在的域名。
  4. 时间:系统时间差太多,TLS 握手直接失败,先对时。

什么时候 TLS 也救不了你
#

  • IP 被墙:TLS 加密的是内容,IP 是明文的。IP 被封,什么协议都连不上。
  • SNI 阻断:ClientHello 里的 SNI(要访问的域名)是明文的,针对 SNI 的阻断,TLS 1.3 防不住(得靠 ECH)。
  • 主动探测:服务端被主动探测,TLS 伪装再好也白搭,Reality 的防探测就是干这个的。

理解 TLS 的边界,才能理解为什么 2024 年是"Reality 年":大家都在 TLS 之上卷,卷的就是谁更像正常流量。

TLS 握手全过程(简化版)
#

  1. ClientHello:客户端说"你好,我支持这些加密套件、这是我的 SNI(要访问的域名)"。这一步是明文的(除非 ECH)。
  2. ServerHello:服务端回应,选定加密套件,发来证书。
  3. 密钥交换:双方用非对称加密协商出会话密钥(1.3 只用 1 个 RTT)。
  4. 加密通信:之后的所有数据都用会话密钥加密。

代理的"伪装",本质上就是让第 1 步看起来像正常浏览器,让第 4 步的内容无法被识别。

ECH:SNI 的终极答案
#

SNI 明文是 TLS 1.3 最大的短板。ECH(Encrypted ClientHello)把它也加密了:

  • 2024 年 Cloudflare 已经大规模支持 ECH。
  • 客户端(新版 Chrome / Firefox)+ 服务端都支持,才能生效。
  • 对科学上网的意义:SNI 阻断失效,审查者连你想访问哪个域名都看不到。

但 ECH 还没完全普及,2024 年把它当"未来",Reality 当"现在"。

实战:检查你的 TLS 配置
#

拿 VLESS+Reality 举例,客户端配置里这几个值决定成败:

  • security: tls / reality:别设成 none,裸奔等于裸奔。
  • SNI:填真实存在的大站域名,和服务端 dest 一致。
  • fingerprint:uTLS 选 chrome,和 SNI 站点的真实指纹匹配。
  • allowInsecure:永远 false,设成 true 等于自废武功。
  • 证书时间:服务端证书过期会导致握手失败,自建的注意续期。

一句话总结
#

TLS 1.3 是 2024 年代理协议的共同地基:它不提供"隐身",它提供"合群"。在这个人人用 HTTPS 的时代,最安全的伪装就是和大家一样。而 Reality、uTLS 这些,是在"合群"的基础上再卷一层——卷到和真的一模一样。

理解了 TLS,就理解了 2024 年代理协议的江湖:大家都在一层楼里,只是装修不同。选协议,就是选装修风格。但地基,永远是 TLS。

TLS 加密插画

插图来源:Storyset

相关阅读:Rabbit R1 发布:一台 AI 硬件能走多远 · Kimi 200 万字长上下文:实测体验