加密通信的最后一公里 - ECH(Encrypted Client Hello)

admin 2024年5月15日19:03:06评论5 views字数 3310阅读11分2秒阅读模式

加密通信的最后一公里 - ECH(Encrypted Client Hello)

熟悉我的人都知道,我是蛮喜欢 Cloudflare 这家厂商的,说他们是赛博慈善家(赛博菩萨)绝不夸张。今天主要想讲一讲 CF 在大概 2021 年发起的一项提案:

https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

也就是 Encrypted Client Hello,算 ESNI 的后继者吧。

TLS 与 DH 算法

首先我们需要理解,TLS(安全传输层协议)位于 TCP 与应用层之间,HTTPS 相对于 HTTP 来说,协议本身没什么改变,而是在 TCP 与 HTTP 间添加了一层 TLS 用作加密以保证信息安全。

TLS 同时使用对称和非对称做加密,大家都知道非对称速度慢,对称速度快,那 TLS1.3 为保证安全性同时兼顾性能先使用 Diffie–Hellman 交换密钥,DH 大概套路是客户端和服务器都生成一对公私钥,再把各自公钥发送给对方,双方得到对方的公钥后,用数字签名确保公钥没有被篡改,然后与自己的私钥结合,就可以计算得出相同的密钥。DH 算法就不细说了,它的核心是基于有限域中计算离散对数的困难性设计出来的,而离散对数的求解是数学界公认的无解难题,想了解原理的可以看下图(我特地找到了本科上课时的课本,然后拍照下来...这上面解释的虽然很学术,但仔细看也是很容易理解的):

加密通信的最后一公里 - ECH(Encrypted Client Hello)

加密通信的最后一公里 - ECH(Encrypted Client Hello)

通信双方协商完毕获得加密的密钥后,接下来的数据就都通过协商产生的密钥做对称加密。

为什么 TLS 1.3 抛弃了用 RSA 交换密钥

RSA 不是前向安全的,通俗的讲,前向安全是指如果攻击者保存了之前加密会话的流量,并设法获取到了私钥,他就能解密全部流量。但是对于 DH 算法来说,只要每次通信生成新的密钥对,那么解密的密钥每次通信都会不同。

TLS 中还有什么安全问题?

以 TLS1.3 的握手流程为例,分析这里面存在哪些不安全的地方:

  1. 客户端Hello(ClientHello)

    • 客户端发送“ClientHello”消息,包括所支持的最高TLS协议版本、客户端生成的随机数、可接受的密码套件列表、压缩方法,以及其他扩展(如支持的群组、预共享密钥(PSK)标识符等)。

  2. 服务端Hello(ServerHello)

    • 服务端选择一个与客户端共同支持的协议版本和一个密码套件。服务端也生成一个随机数。

    • 服务端发送“ServerHello”消息,包括选定的协议版本、服务端随机数、选定的密码套件,以及其他必要的扩展。

  3. 服务端参数和证书

    • 服务端发送其数字证书,以便客户端可以验证服务端的身份。

    • 如果需要客户端证书(双向TLS),服务端将请求客户端证书。

    • 服务端可能还会发送一些额外的密钥交换信息和证书验证信息,如数字签名。

  4. 服务端完成(Server Finished)

    • 服务端发送“Finished”消息,该消息包含前面所有消息的加密验证代码(验证数据),以确认消息的完整性和真实性。

  5. 客户端参数和证书

    • 客户端验证服务端的证书和签名,确认服务端的身份。

    • 客户端发送包含预主密钥材料的密钥共享信息(如果使用密钥交换)。

    • 如有需要,客户端也发送自己的证书。

  6. 客户端完成(Client Finished)

    • 客户端发送“Finished”消息,同样包含前面所有消息的加密验证代码。

  7. 主密钥的派生

    • 在双方发送和接收“Finished”消息之后,双方利用之前交换的随机数和预主密钥材料,利用密钥派生函数(KDF)生成会话密钥。

  8. 加密通信

    • 握手完成后,所有后续的通信都使用派生的会话密钥进行加密。

缺陷

先说 SNI(Server Name Indication):

为什么会有 SNI ?因为许多 Web 服务器(单个 IP)会托管多个网站,并且可能每个网站都有自己的 TLS 证书。如果服务器向客户端显示错误的证书,客户端是无法安全连接到网站的;SNI 告诉 Web 服务器在客户端与服务器之间的连接开始时用哪个 TLS 证书,是 TLS 协议的补充。

但是,这里有个很重要的点是,TLS 握手中的第一条消息"ClientHello"中,客户端会要求查看 Web 服务器的 TLS 证书,服务器也会发送给客户端,可是只有在使用 SNI 成功完成 TLS 握手后,才能进行加密啊!

看起来好像是个死循环了,那怎么办?只能先不加密 SNI 凑活用咯。

PS:不加密 SNI 会引发很多问题,例如网络过滤、监控 or 审查,也就是说通过 SNI 有人可以知道你在访问 TG PornHub or X 哦~

ESNI 如何解决 SNI 不加密的问题呢?

Firefox 和 CF 在18年就支持了,这个技术就不细说了,否则文章太长了,大致方案就是使用公钥加密 SNI,首先在DNS 记录中添加一个服务端公钥,当客户端查找到服务器地址时,同时也能找到该服务端的公钥。然后,客户端使用公钥来加密 SNI 记录,只有服务端才能解密。

有了 ESNI 就够了吗?

铁铁,不要想太多了,链路还有一环:DNS 查询是明文啊,用了 ESNI 确实是不能从 TLS 握手时看到你访问量啥,但你总要查 DNS 吧!那怎么办呢?继续打补丁!基于 TLS 的 DNS(DoT)、基于 HTTPS 的 DNS(DoH) 和 DNSSEC。

前两个方法是使用 TLS 加密 DNS 查询,DNSSEC 确认 DNS 记录真实并来自合法的 DNS 服务器,而非来自冒充 DNS 服务器。

那 ECH 的优势呢?

先说说 ESNI DNSSEC DoT DoH的局限性:

  1. ESNI 的局限性

    • ESNI 并非广泛支持:ESNI的支持不是特别好(当然 ECH 用的更不多);

    • ESNI 只加密SNI字段:ESNI仅仅加密了SNI字段,而整个ClientHello消息中还包含其他可能泄露用户隐私的元素,如密码套件、TLS版本等。这些信息可以被用来推断用户的浏览习惯或设备类型;

  2. DNSSEC、DoT、DoH 的局限性

    • 这些技术主要针对DNS查询和响应的安全性:DNSSEC确保DNS响应的真实性和完整性,防止DNS欺骗。DoT和DoH加密DNS查询,保护查询内容不被窃听;

    • DNS层面的加密不影响TLS握手:即使DNS查询被加密,TLS握手时发送的ClientHello消息仍然可以暴露用户信息。例如,即使你通过DoH安全地解析了一个网站的IP地址,TLS握手过程中明文的ClientHello信息还是可以让中间人知道你正在尝试连接到哪个网站;

  3. ECH 的优势

    • 全面加密ClientHello消息:ECH不仅加密SNI,还加密整个ClientHello消息的其他部分。这意味着除了服务器名,其他可能泄露信息的元素(如TLS版本和密码套件偏好)也被保护,防止被外部观察者分析;

    • 增强隐私保护:通过 ECH,即使是能够观察到你网络流量的本地网络运营商或某些"合法"监视者也无法确定你正在访问哪个具体网站,因为整个 ClientHello 包括服务器名都被加密了;

ECH 怎么做到的呢?

使用ECH时,ClientHello消息部分被分为两个单独的消息:一个内部和一个外部。外部部分包含非敏感信息,例如使用哪些加密算法和TLS版本。它还包括一个“外部SNI”。内部部分被加密,并包含一个“内部真实SNI”。外部SNI是一个通用名称,CF的服务中 cloudflare-ech.com 就是所有托管在 Cloudflare 网站上共享的 SNI 。

由于 Cloudflare 控制这个域名和证书,所以能够为该服务器名称协商 TLS 握手。内部 SNI 包含用户试图访问的真实服务器名称,在这里是使用公钥加密过后的数据,也只有 Cloudflare 能够读取。

在实践中,这意味着任何试图确定我们正在访问哪个网站的人只会看到正常的TLS握手,每当我们访问在 Cloudflare 上启用 ECH 的网站时,服务器名称看起来是一样的,都是在尝试加载 cloudflare-ech.com 的网站,而不是真实的网站。这也解决了保护用户隐私的最后一公里:用户不喜欢中间人看到他们正在访问哪些网站。

如何在服务端启用:

在 CF 的 Dashboard 中开启就好了:

加密通信的最后一公里 - ECH(Encrypted Client Hello)

检查客户端有没有开启 ECH:

https://www.cloudflare.com/zh-cn/ssl/encrypted-sni

点点关注 点点赞 点点在看,抱拳了铁铁们!

原文始发于微信公众号(imBobby的自留地):加密通信的最后一公里 - ECH(Encrypted Client Hello)

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2024年5月15日19:03:06
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   加密通信的最后一公里 - ECH(Encrypted Client Hello)https://cn-sec.com/archives/2742335.html

发表评论

匿名网友 填写信息