从 pixiv 免代理直连看 SNI 阻断及其绕过方法——域前置

最近在使用某 pixiv 第三方客户端时发现这个客户端可以直连 pixiv。然而，众所周知，使用 hosts 访问被屏蔽的网站的方式很早就行不通了。所以我相当好奇，就乘着五一假期做点研究。

pixiv 受屏蔽情况

目前 GFW 屏蔽“违规网站”所用的方法有两种——DNS污染和TCP重置抢答。所以如果只用 hosts 解析到正确的 IP 地址，连接会被 GFW 抢先发送的 RST 报文重置：

直连方案

那么那些可以直连的软件是如何做到直连的呢？我开启直连功能后抓了下这个软件发送的包：

欸这个Client Hello怎么和我之前看到的不一样呢？太短了吧这也！？（以下是访问百度的Client Hello）

和前面的包一对比就可以看出来，这个软件在访问 pixiv 时把数据包里的 Server Name 字段搞乱了（变成了 ?124），这样GFW理论上就无法通过这个字段来探知连接到的域名。

~~但我还是不明白，GFW 的动态路由投毒大法（又称 IP 黑洞）是拿来干嘛用的？直接 ban 掉这个 IP 不就好了？210.140.131.0/24这个 IP 段属于日本的 IDC Frontier Inc.，隶属于 SoftBank。目前这个IP段似乎只有 pixiv 一家在使用。按理来说屏蔽了也没什么影响。~~查了一下，发现这家是个云计算服务提供商，价格死贵：https://www.idcf.jp/english/cloud/

那么为什么即使不发送有效的 Server Name 字段，依然能正常完成 SSL Handshake 呢？这就要谈到 pixiv 服务器所用的技术之一—— SNI

SNI

Server Name Indication，SNI，服务器名称指示；简单来说，是用于在一台服务器的相同端口上部署不同证书的方法，我们熟知的 Cloudflare 在启用 CDN 后提供的证书就是基于 SNI 部署的。当然，pixiv 也是。 实现 SNI 的重要过程之一，就是在客户端与服务器建立连接的时候就发送要连接的域名，以便服务器可以返回一张颁发给指定域名的证书。

这个过程中，如果用户请求了一个不存在的域名后，服务器会发送一张默认证书给客户端以便连接能够继续。有趣的是，pixiv 服务器设置的默认证书正好是颁发给 *.pixiv.net 的泛域名证书。所以无论请求什么东西，返回来的证书总是能用的。
下图是 pixiv 返回的默认证书，使用者是*.pixiv.net：

这张则是正常访问主页时，使用 SNI 技术签发的证书，使用者是 www.pixiv.net：

事实上，GFW 目前检测某个数据包是否“违规”的手段就是基于深度数据包检测的 SNI 阻断，即通过 Server Name 字段来检查域名，判断是否阻止对这个IP的连接。而这种通过混淆 Server Name 来绕过阻断的方法也已经不是什么新鲜技术，这叫做域前置，Domain fronting. 维基百科对这一技术有介绍。

这种方法的最大局限性在于其实用性取决于服务器如何响应无效的 Server Name. 如果 pixiv 服务器在收到这样的数据包后没有返回这个泛域名证书而是拒绝连接，那这种方法显然会失效。

题外话

前期的审查还不算严格，但是到了现在，已经不能用“严格”来形容了，完全到了变态的地步。举个例子，B站手机APP的启动图曾一度长这样

（此图片来自萌娘共享，采用知识共享(Creative Commons) 署名-非商业性使用-相同方式共享 3.0 协议授权）

由于授权协议冲突，现停止从萌娘共享直接引用图片，请点击下面链接查看： https://zh.moegirl.org.cn/File:B站原起始页面.png

但后来就变成了这样（此图片来自萌娘共享，采用知识共享(Creative Commons) 署名-非商业性使用-相同方式共享 3.0 协议授权）

由于授权协议冲突，现停止从萌娘共享直接引用图片，请点击下面链接查看： https://zh.moegirl.org.cn/File:B站新起始页面.png

B站对内容审查已不是一天两天，但这次竟把代表了“哔哩哔哩干杯”这句口号，代表了众多还喜欢这个网站的用户心中情怀的两杯人畜无害的啤酒都抹消掉；结合前文所述的被央视钦点和下架番剧自审等风波，可见国内网站审查环境之严峻、生存空间之狭窄。（摘自萌娘百科）

最后，放两个视频，自己体会。