ESNI 加密装甲中的最后一个缝隙

1

随着TLS 1.3问世,网络流量迈入了新时代,DoH和DoT都是将不同形式的数据包通过TLS 1.3加密,网络中可嗅探的数据变得越来越少,我前面发过一篇透过公共Wi-Fi 热点上网究竟安不安全,DNS加密后并且全程使用HTTPS协议,网关中依然会泄露访问的域名。

这里就需要普及一个名词叫做SNI,简单说因为服务器和客户端建立加密连接之前,客户端需要请求证书并明文发送主机名给服务器,服务器发送证书后,本地客户端再加以校验,这是因为通常同一个服务器端会部署多个域名服务,TLS握手发生在建立加密连接之前,如果直接扔过来一个加密包服务器端无法知道包的内容,也无法决定返回哪一个证书,所以网关仍然可以获取客户端访问的域名列表。

题外话:由于SNI的特性,通常NGINX服务器直接通过域名访问会泄露配置文件中的第一个证书,而有心者这可以通过证书内容获取很多信息,这个“漏洞”暂时还无法解决。

IETF在最新的草案中设计了一种新的加密SNI机制 Encrypted Server Name Indication(ESNI),ESNI要求DNS服务器负责随解析记录分发一个公钥,这样在TLS握手时,客户端就可以将通过加密DNS获取的公钥一并发送给服务器来直接建立加密连接,从而堵上了信息泄露的最后一个口子。

ESNI目前还在草案中,甚至还有很多可用性修复工作正在进行中,不过各大浏览器上已经在积极适配,Cloudflare在ESNI上特别积极,他们已经在1.1.1.1和所有Cloudflare节点部署ESNI完成。

目前浏览器支持方面比较悲观,仅Firefox 62+可以开启,Chrome开发组表示ESNI需要基于安全稳定的DNS服务,将会放在DoH适配之后,Cloudflare还煞有介事的制作了一个ESNI支持检测

Firefox 开启 ESNI 方法
在地址栏输入about:config进入设置页面,修改network.trr.mode选项,设置为2优先使用DoH,设置为3则仅使用DoH。
修改network.trr.uri选项可以指定DoH服务器,默认是https://mozilla.cloudflare-dns.com/dns-query,我们也可以手动修改为https://dns.google.com/experimental或者https://1.0.0.1/dns-query

也可以修改network.trr.resolvers值后,在选项 网络设置中配置服务器。

[{ "name": "Cloudflare", "url": "https://mozilla.cloudflare-dns.com/dns-query" },{ "name": "1.0.0.1", "url": "https://1.0.0.1/dns-query" },{ "name": "Google", "url": "https://dns.google/dns-query" },{ "name": "朽木", "url": "https://dns.xiumu.org/dns-query" }]

接下来点击修改network.security.esni.enabled即可开启ESNI。

共 1 条评论

  1. 回复

    文章不错支持一下吧,非常喜欢

回复 今日头条新闻 X

您的邮箱不会公开,当您的评论有新的回复时,会通过您填写的邮箱向您发送评论内容。 必填字段 *

为何看不到我发布的评论?

正在提交, 请稍候...