欢迎 OpenSSL 4 以及加密的 Client Hello

asecuritysite 发布于 2026-04-24 阅读 202

本文介绍了 OpenSSL 4.0.0 新增的 ECH（Encrypted Client Hello）相关能力，以及如何通过 openssl ech 命令生成、查看和导出 ECH 配置与密钥，并提到可指定 X25519、HKDF-SHA256、AES-128-GCM 等套件。

欢迎 OpenSSL 4 —— 以及加密的 Hello

我一直很喜欢迎来 OpenSSL 的新版本，而本周我们看到了 OpenSSL 4.0.0 这一重大版本升级。

> openssl version
OpenSSL 4.0.0 14 Apr 2026 (Library: OpenSSL 4.0.0 14 Apr 2026)

现在，我们看到新增了 ECH 命令：

> openssl ech -help
Usage: ech [options]

General options options:
 -help              Display this summary
 -verbose           Provide additional output
 -text              Provide human-readable output

Key generation options:
 -out outfile       Private key and/or ECHConfig [default: echconfig.pem]
 -public_name val   public_name value
 -max_name_len int  Maximum host name length value [default: 0]
 -suite val         HPKE ciphersuite: e.g. "0x20,1,3"
 -ech_version int   ECHConfig version [default: 0xff0d (13)]

ECH PEM file downselect/display options:
 -in infile         An ECH PEM file
 -select int        Downselect to the numbered ECH config

如果我们想生成一对密钥，首先需要定义一个 public name：

> openssl ech -public_name asecuritysite.com -out echconfig.pem

然后我们可以查看 ECH 配置的详细信息：

C:\openssl_4_0\bin>openssl ech -in echconfig.pem -text
ECH entry: 0 public_name: asecuritysite.com age: 0 (has private key) (will be sent in retry-configs)
        [fe0d,e2,asecuritysite.com,[0020,0001,0001],\
  9db1f8695deb7a7757745cc8661a118b66f5bd4f91a4fedf044652b3de025803,00,00]

接下来我们可以只导出公钥：

C:\openssl_4_0\bin>openssl ech -in echconfig.pem -out ech-public.pem

C:\openssl_4_0\bin>openssl ech -in echconfig.pem -text

> type ech-public.pem
-----BEGIN ECHCONFIG-----
AET+DQBA4gAgACCdsfhpXet6d1d0XMhmGhGLZvW9T5Gk/t8ERlKz3gJYAwAEAAEA
AQARYXNlY3VyaXR5c2l0ZS5jb20AAA==
-----END ECHCONFIG-----

以及私钥（和配置）：

C:\openssl_4_0\bin>type echconfig.pem
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VuBCIEIEDG41OApI2ecZeZHX1O2afxtphctAcUw5oYk/G1wOx2
-----END PRIVATE KEY-----
-----BEGIN ECHCONFIG-----
AET+DQBA4gAgACCdsfhpXet6d1d0XMhmGhGLZvW9T5Gk/t8ERlKz3gJYAwAEAAEA
AQARYXNlY3VyaXR5c2l0ZS5jb20AAA==
-----END ECHCONFIG-----

如果需要，我们还可以为特定的 cipher suite 生成配置，例如指定 KEM_ID、HKDF_ID 和 SYMMETRIC_KEY_ID。在这个例子中，我们定义了 X25519、HKDF-SHA256 和 AES-128-GCM：

openssl ech  -public_name example.com -suite x25519,hkdf-sha256,aes-128-gcm
  -out echconfig.pem

OpenSSL 4.0.0 的另一个新增内容，是加入了带有 ML-KEM-768 的中国 SM2 曲线：

>openssl list -kem-algorithms
  { 1.2.840.113549.1.1.1, 2.5.8.1.1, RSA, rsaEncryption } @ default
  { 1.2.840.10045.2.1, EC, id-ecPublicKey } @ default
  { 1.3.101.110, X25519 } @ default
  { 1.3.101.111, X448 } @ default
  { 2.16.840.1.101.3.4.4.1, id-alg-ml-kem-512, ML-KEM-512, MLKEM512 } @ default
  { 2.16.840.1.101.3.4.4.2, id-alg-ml-kem-768, ML-KEM-768, MLKEM768 } @ default
  { 2.16.840.1.101.3.4.4.3, id-alg-ml-kem-1024, ML-KEM-1024, MLKEM1024 } @ default
  X25519MLKEM768 @ default
  X448MLKEM1024 @ default
  SecP256r1MLKEM768 @ default
  SecP384r1MLKEM1024 @ default
  curveSM2MLKEM768 @ default

TLS 加密 Hello

使用 TLS 的一个主要问题是，用户正在连接的服务器名称可能会被中间方看到——因为 TLS 握手的前几个部分是可以被截获的。这意味着你的 ISP 和咖啡店的 Wi-Fi 网络可以窥探你的访问情况（但看不到你所查看内容的细节）。

记住我以便更快登录

IETF 提供了一个替代 ESNI（Encrypted server name indication）的方案，并在 TLS 连接中隐藏 Server Name Identification（SNI）[ here]：

最终，只有用户、受信任的加密主机以及服务器能够看到正在连接的主机。咖啡店仍然可以在其他方面窥探你，例如目标 IP 地址以及 DNS 查询；不过，这至少是在支持隐私方面向前迈出的一步。如果你关心 DNS 的隐私，应该研究 DNS over HTTP（DoH）；而要隐藏 IP 地址，则可以使用代理。

TLS 连接的问题在于，在建立加密隧道之前，会话密钥尚未定义，因此连接的所有细节都会暴露出来。但是，借助 ECH（Encrypted Hello），我们现在可以与一个代理实体执行握手，从而使他人无法看到最终服务器连接，并且服务器也无法看到是哪个客户端正在连接。最早实现集成 ECH 和 DoH 方法的公司之一是 Cloudflare，他们概述的流程如下：

https://blog.cloudflare.com/announcing-encrypted-client-hello/

下面是 TLS 握手的概述：

ESNI

Cloudflare 最近宣布，他们已经实现了 ESNI (encrypted Server Name Indication (SNI) TLS extension)。其目的是阻止 ISP 和公共 Wi-Fi 提供商窥探你的 Web 访问（或任何监听你网络数据包的人）。首次集成是在 Firefox Nightly 中，你可以在 here 测试你的浏览器：

Cloudflare 也在推动 DNS 请求的安全，同时推动向 DNSSEC 和 TLS 1.3 迁移。一旦启用 ESNI，它应该显示如下内容：

Cloudflare 已经发布了 Wireshark 抓包记录来展示差异。下面显示的是普通 TLS 的情况，我们可以在 TLS 数据包中看到服务器名称（cloudflare.com）：

如果现在加入加密的 SNI 扩展，我们会得到：

TLS 连接本应是安全并通过隧道传输的，但在初始协商的 Client Hello 中，我们暴露了服务器名称，任何监听我们网络数据包的人都可以看到它。

使用 ESNI 时，拥有 DNS 记录的服务器会发布其公钥。然后客户端将 SNI 扩展改为加密版本。所使用的密钥是从服务器公钥派生出的对称密钥（使用 Elliptic Curve Diffie Hellman key exchange）。持有对应私钥的服务器也可以派生出相同的对称密钥，并解密该扩展。这只能在 TLS 1.3 及以上版本中工作。在 TLS 1.2 及以下版本中，窃听者可以检查从服务器发送到客户端的数字证书，从而确定用户正在连接到哪个网站。

结论

OpenSSL 在修复 TLS 协议中的这一弱点方面做得很好。

  • 原文链接： medium.com/asecuritysite...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
微信扫码分享

相关文章

0 条评论

登录后发表评论