<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>SNI Encryption on 飞鸽跳转</title><link>https://feige301.com/zh-cn/tags/sni-encryption/</link><description>Recent content in SNI Encryption on 飞鸽跳转</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Thu, 05 Feb 2026 01:19:55 +0800</lastBuildDate><atom:link href="https://feige301.com/zh-cn/tags/sni-encryption/index.xml" rel="self" type="application/rss+xml"/><item><title>TLS的最后一块拼图：ECH（加密SNI）</title><link>https://feige301.com/zh-cn/posts/2026/tls-final-puzzle-piece-ech-encrypted-sni-preventing-domain-blocking.html</link><pubDate>Thu, 05 Feb 2026 01:19:55 +0800</pubDate><guid>https://feige301.com/zh-cn/posts/2026/tls-final-puzzle-piece-ech-encrypted-sni-preventing-domain-blocking.html</guid><description>&lt;p>今天，我们来聊一个看似深奥，实则与每一位网站管理员、运维工程师和开发者息息相关的技术话题：TLS的最后一块拼图——ECH（Encrypted Client Hello），即加密SNI。&lt;/p>
&lt;h3 id="背景日益复杂的网络连通性挑战">
 背景：日益复杂的网络连通性挑战
 &lt;a class="anchor" href="#%e8%83%8c%e6%99%af%e6%97%a5%e7%9b%8a%e5%a4%8d%e6%9d%82%e7%9a%84%e7%bd%91%e7%bb%9c%e8%bf%9e%e9%80%9a%e6%80%a7%e6%8c%91%e6%88%98">#&lt;/a>
&lt;/h3>
&lt;p>在当今数字时代，网站的连通性是其生命线。然而，随着网络环境的复杂化，网站运营者常常面临各种意想不到的连接障碍。这些障碍不仅影响用户体验，更直接损害业务连续性和数据安全。其中，尤为突出的挑战来自以下几个方面：&lt;/p>
&lt;ol>
&lt;li>&lt;strong>区域性网络封锁：&lt;/strong> 特定网络区域内的用户可能无法访问某些域名，这并非因为服务器故障，而是由于网络路径中的“中间设备”对流量进行了识别和阻断。&lt;/li>
&lt;li>&lt;strong>ISP劫持：&lt;/strong> 某些“某地区运营商”可能会在用户访问特定域名时，未经授权地将流量重定向到其他页面，甚至篡改内容，严重侵犯了用户和网站所有者的权益。&lt;/li>
&lt;li>&lt;strong>域名污染：&lt;/strong> 这是指DNS解析结果被篡改，导致用户请求的域名被解析到错误的IP地址，从而无法正常访问目标网站。&lt;/li>
&lt;/ol>
&lt;p>这些问题的根源，往往在于当前网络协议设计中某些“明文”元数据的暴露。尽管我们普遍采用TLS（传输层安全协议）来加密传输内容，确保数据在传输过程中的机密性和完整性，但在TLS握手阶段，一些关键信息却依然以明文形式传输，成为了“中间设备”进行识别和干预的突破口。&lt;/p>
&lt;h3 id="困境与痛点明文sni的阿喀琉斯之踵">
 困境与痛点：明文SNI的阿喀琉斯之踵
 &lt;a class="anchor" href="#%e5%9b%b0%e5%a2%83%e4%b8%8e%e7%97%9b%e7%82%b9%e6%98%8e%e6%96%87sni%e7%9a%84%e9%98%bf%e5%96%80%e7%90%89%e6%96%af%e4%b9%8b%e8%b8%b5">#&lt;/a>
&lt;/h3>
&lt;p>想象一下，你正在给远方的朋友寄送一封加密的信件。信件内容被严密包裹，无人能窥视。但信封上，你却不得不清晰地写上收件人的姓名和地址。对于网络流量而言，TLS协议在加密数据内容方面做得非常出色，但它在握手阶段，尤其是早期版本中，却暴露了一个“信封上的地址”——这就是我们今天要重点讨论的SNI（Server Name Indication，服务器名称指示）字段。&lt;/p>
&lt;p>在TLS 1.2及更早版本中，客户端在发起TLS握手时，会在&lt;code>ClientHello&lt;/code>消息中包含一个SNI字段，明确告知服务器它希望访问哪个域名。这个设计是为了解决虚拟主机（Virtual Hosting）的问题：一台服务器上可能托管着成百上千个不同的网站，服务器需要知道客户端请求的是哪个域名，才能提供正确的TLS证书并建立连接。&lt;/p>
&lt;p>然而，SNI的明文传输，成为了“中间设备”进行流量过滤和阻断的关键依据。这些“流量网关”或“DPI（深度包检测）设备”能够轻易地读取到用户正在尝试访问的域名。一旦某个域名被列入“关注列表”，这些设备便可以根据明文SNI信息，对相应的连接进行阻断、重置或重定向。&lt;/p>
&lt;p>&lt;strong>这给网站运营者带来了巨大的痛点：&lt;/strong>&lt;/p>
&lt;ul>
&lt;li>&lt;strong>业务中断与用户流失：&lt;/strong> 对于“高并发商业站点”、“数字娱乐平台”等依赖稳定连接的业务而言，基于SNI的阻断意味着用户无法访问，直接导致流量损失、交易中断，甚至品牌声誉受损。&lt;/li>
&lt;li>&lt;strong>安全隐患：&lt;/strong> ISP劫持者可以利用明文SNI来识别目标网站，进而实施各种中间人攻击或流量篡改，危及用户数据安全。&lt;/li>
&lt;li>&lt;strong>运维成本增加：&lt;/strong> 为了应对这些阻断，网站管理员可能需要投入大量资源寻找替代域名、配置复杂的跳转规则，甚至部署昂贵的“隧道传输技术”，但这些方案往往治标不治本，且维护成本高昂。&lt;/li>
&lt;li>&lt;strong>隐私泄露：&lt;/strong> 即使内容被加密，但用户访问了哪个网站这一元数据仍然对网络路径上的监听者可见，这严重侵犯了用户的上网隐私。&lt;/li>
&lt;/ul>
&lt;p>现有的解决方案，如DNS over HTTPS (DoH) 或 DNS over TLS (DoT)，虽然能够加密DNS查询，防止DNS污染，但它们并不能解决SNI明文传输的问题。用户在进行DNS查询后，依然会在TLS握手时暴露目标域名。因此，我们需要一个更根本的解决方案，来加密这“TLS的最后一块明文拼图”。&lt;/p>
&lt;h3 id="正文echtls的最后一块拼图">
 正文：ECH——TLS的最后一块拼图
 &lt;a class="anchor" href="#%e6%ad%a3%e6%96%87echtls%e7%9a%84%e6%9c%80%e5%90%8e%e4%b8%80%e5%9d%97%e6%8b%bc%e5%9b%be">#&lt;/a>
&lt;/h3>
&lt;p>为了解决明文SNI带来的隐私和连通性问题，互联网工程任务组（IETF）一直在努力推进一项新技术：&lt;strong>Encrypted Client Hello (ECH)&lt;/strong>。ECH是ESNI（Encrypted SNI）的演进版本，旨在将整个&lt;code>ClientHello&lt;/code>消息（包括SNI）进行加密，从而彻底消除TLS握手阶段的明文元数据泄露。&lt;/p>
&lt;h4 id="1-tls握手与sni的运作原理回顾">
 1. TLS握手与SNI的运作原理回顾
 &lt;a class="anchor" href="#1-tls%e6%8f%a1%e6%89%8b%e4%b8%8esni%e7%9a%84%e8%bf%90%e4%bd%9c%e5%8e%9f%e7%90%86%e5%9b%9e%e9%a1%be">#&lt;/a>
&lt;/h4>
&lt;p>在深入ECH之前，我们先快速回顾一下TLS握手的核心流程，以便更好地理解ECH所解决的问题：&lt;/p>
&lt;ol>
&lt;li>&lt;strong>ClientHello (客户端问候)：&lt;/strong> 客户端向服务器发送一个&lt;code>ClientHello&lt;/code>消息，其中包含客户端支持的TLS版本、密码套件、随机数等信息。在TLS 1.2及更早版本中，这个消息中还会包含明文的SNI字段，告诉服务器它想要访问哪个域名。在TLS 1.3中，SNI仍是明文。&lt;/li>
&lt;li>&lt;strong>ServerHello (服务器问候)：&lt;/strong> 服务器收到&lt;code>ClientHello&lt;/code>后，从中选择一个TLS版本和密码套件，并回复&lt;code>ServerHello&lt;/code>消息，其中也包含服务器的随机数。&lt;/li>
&lt;li>&lt;strong>证书交换：&lt;/strong> 服务器发送其数字证书给客户端，客户端验证证书的有效性。&lt;/li>
&lt;li>&lt;strong>密钥交换：&lt;/strong> 客户端和服务器通过密钥交换算法（如Diffie-Hellman）协商出一个共享的会话密钥。&lt;/li>
&lt;li>&lt;strong>加密通信：&lt;/strong> 双方使用协商出的会话密钥对后续的应用层数据进行加密和解密。&lt;/li>
&lt;/ol>
&lt;p>从上述流程可以看出，&lt;code>ClientHello&lt;/code>是整个TLS会话的起点，也是唯一在加密通信开始前，包含敏感域名信息（SNI）的明文消息。这就是“中间设备”进行识别和阻断的绝佳时机。&lt;/p></description></item></channel></rss>