“夜光”：使用域隐藏代替域前置

文章来源｜MS08067 内网安全知识星球

本文作者：Spark（Ms08067 内网小组成员）

众所周知，谷歌云和亚马逊云于2018年宣布停止支持域前置技术。在去年8月的DEFCON28上安全研究人员发布了一款名为“Noctilucent”（夜光）的开源工具。该工具使用TLS1.3协议从某种程度上复活了域前置技术。这一新技术被安全研究人员称为“域隐藏”。

1、域前置

域前置是一种隐藏连接真实端点来规避审查的技术，其原理为在不同通信层使用不同的域名：在明文的DNS请求和TLS服务器名称中使用无害的域名来初始化连接，而实际要连接的被封锁域名仅在创建加密的HTTPS连接后发出，使其不以明文暴露给网络审查者。

为了彻底地理解域前置，需要先了解一些HTTP和HTTPS的基础知识。

1.0 SNI

SNI（Server Name Indication）是一个TLS的扩展，用于允许多个网站托管在同一个服务器上。
对于TLS1.3来说，这个扩展是加密的，也就是ESNI（Encrypted Server Name Indication）。

1.1 HTTP基础

在一次HTTP连接中，用户的第一个外部请求是向DNS请求目标web服务器的IP地址
这是一个未加密的数据包，发送到UDP协议的53端口

DNS会返回一个包含目标web服务器IP地址的响应包
该响应包也是未加密的

用户得知了该域名所部署的服务器的IP地址后，会对其发送一个GET请求，并将域名作为“Host”请求头
也是未加密的数据包，通过TCP协议发送至80端口

服务器返回HTML的内容作为响应

这样的传输过程显然是有问题的：

没有任何数据是加密的
DNS和HTTP的请求包和响应包都是明文传输的形式

为了解决以上的问题，HTTPS诞生了。

1.2 HTTPS基础

最初的步骤与HTTP相同，用户向DNS请求目标web服务器的IP地址
也是一个未加密的UDP连接

DNS会返回一个包含目标web服务器IP地址的响应包
该响应包也是未加密的（与HTTP相同）

接下来才是HTTPS的不同之处：

用户会发送一个ClientHello来开始一个TLS握手
目标web服务器使用接收到“server_name”（明文）来查询如何响应

服务器返回一个带有证书的响应包SeverHello来完成TLS握手
该证书为明文传输，但TLS1.3除外
握手后客户端和服务端便会使用同样的加密算法加密数据以及交换session key

HTTPS的认证过程比HTTP安全很多，但是整个DNS的过程以及证书交换的过程仍然是未加密的。这一点导致域名和证书可能会在客户端和服务端的中间环节被泄露。

1.3 域前置原理

通过混淆HTTPS中的域名来规避审查
连接至一个被允许的服务器，但是将HTTP请求发送给真正的目标
最大的一个限制，真假域名必须来自在相同的域名供应商
Google App Engine
Amazon S3/CloudFront
Microsoft Azure CDN
Others

接下来说明域前置的原理：

DNS查询如同之前一样
客户端向服务器的握手请求也与之前相同，但是在握手时，客户端连接至被前置的域名，而不是真正的域名

握手的响应过程与之前相同

客户端将包含了真实域名的“Host”请求头的HTTP请求发送至真实目的服务器上
只要目的服务器的域名也在该服务商上，CDN就会分发该请求

任何GAE上的网站都可以被用来前置一个未经审查的GAE域名

你可以将域前置看成一个信封里的明信片：

客户端在信封上写上CDN的域名，但是真正的域名被写在信封里的明信片上
网络防火墙或者审计设备好比快递员，他们会允许并发送这封信件，因为信封上的域名是被允许的
当CDN收到信封后，打开信封，并将明信片送给真正的域名

这种技术在所有主流的CDN上都是可行的，直到2018年4月，俄罗斯政府向各大供应商施压，试图阻止全球知名的app——Telegram使用谷歌云和AWS来实现域前置。谷歌云、亚马逊云等大型云服务商先后禁止了该服务。虽然后来Telegram找到了其他的方法来躲避俄罗斯政府的审查，俄罗斯政府也取消了该禁令，但是各大云服务商再也没有恢复过域前置技术。

1.4 域前置的问题