对Tencent Cloud ban 未备案域名的 https 站点方式初步流量分析

[san3Xian]

实验环境

1. tencent cloud 服务器一台[学生机]
2. 未备案域名一个
3. frp
4. https站点若干

现象

服务器为172.16.0.3/111.230.xxx.xxx

客户端为219.128.xxx.xxx/192.168.xxx.xxx

浏览器发起访问请求，客户端和服务端同时抓取报文分析 可以发现

1. 其实客户端与服务器握手成功

2. 客户端浏览器报错信息为connection reset

3. 服务器抓取报文分析，在接收到客户端的client hello后，服务器进行了ack应答，接着服务器收到了一个来自[假]客户端的连接reset报文

4. 然而实际上，客户端在此期间从未发送过reset报文，同理，客户端收到了reset报文，所以浏览器报连接reset错误，但是服务器并没有发送过reset报文(server发送的最后一个ack报文被处理掉了)

唠叨1

在这个实验中可以发现，某厂商的中间设备在对https流量分析了ssl挥手阶段中的client hello报文中的server name字段值(ssl.handshake.extensions_server_name)[Server Name Indication, 缩写SNI]，进而伪造reset报文进行服务器和客户端的连接重置(T_T) okay, 事件发生点找到了，那该怎么解决呢？ (咕咕咕)

唠叨2

1. 天方夜谭设想: 基于iptables编写自定义模块，在服务器上对client hello的下一个ack报文进行TCP flag修改，将SYN标志位->置1，不清楚可否绕过此ban，如果可行的话，那就是某厂商人员。。。的 if 判断没写好？红红火火恍恍惚惚
2. 基于ESNI解决：ESNI是 TLS 1.3 协议的扩展，他可以加密SNI使HTTPS流量更难以被分析(也就是域名值加密了)，基于ESNI还可以达到畅快访问某些学术网站的目的(相关技术加成: DNSSEC)，然而目前各大浏览器对ESNI并没有很好的支持(chrome不支持，据说火狐实验支持)，所以这个方法需要时间去落实。检测浏览器是否支持ESNI等技术的网址: https://www.cloudflare.com/ssl/encrypted-sni/

文章未完待续

[san3Xian]

一个有意思的repo https://github.com/macronut/phantomsocks Related Articles:

• https://2047.one/t/16729
• https://zeallr.com/read/443.html