对某网络认证系统的研究

警告:技术无罪,莫用作非法用途。

如进行不合理使用所造成任何法律责任,笔者概不负责。

迁入大学校内的宿舍后,我对垄断该宿舍的网络公司所使用的认证系统进行了一番研究。


1.初探

该认证系统在未登录时封锁除80及443以外的所有TCP端口;UDP未予详细测试,但至少知道UDP/53(DNS)应该未被其封锁/篡改——经测试,未登录时DNS也能返回正确的记录。

该系统登录页面具有域名(下以a.net代称),并使用了HTTPS。值得注意的是,这个系统可以在未连接该网络时访问,此时登陆账户,不能上线,只能查看账户信息或充值等;通过nslookup可知其使用了CloudFlare的CDN。

未登录时,通过HTTP(TCP/80)访问任何网站,会被其网关302重定向至https://a.net,而使用HTTPS(TCP/443)访问任何网站,网关会发回https://a.netServerHello包,此时:

  • 一些浏览器提示"证书错误",阻止用户继续访问
  • 另一些(更聪明的)浏览器会提示WiFi需要登录,并询问是否跳转至登陆页面

我发现,此时访问https://a.net的IP与用手机网路访问时一样,都属于CloudFlare。于是我做了一个尝试。


2.猜测

  • 将HTTP无条件301到https://a.net
  • 对HTTPS试图识别访问的主机名,如不是a.net,则充当TCP代理,将用户的ClientHello发至https://a.net,并返回https://a.netServerHello等后续数据包……

    3.尝试

获取HTTPS所访问的主机名,方法大抵有两种:

  1. 通过TLS SNI扩展中的servername字段
  2. 通过证书的subjectAltName(下简称SAN)

于是我试图构建一个HTTPS连接,但其具有如下特点

  • SNI扩展中的servername字段为a.net
  • Host这一HTTP Header的值为hardrain980.com

返回了本站首页的HTML。由此证明,该系统是通过TLS SNI扩展来识别HTTPS所请求的主机名,并根据此做出对应操作。


4.后记

  1. 似乎Stunnel能自定义SNI。Server配合后端,将其监听于TCP/443,Client模式下使用a.net做主机名或能绕过此系统。
  2. 此系统若通过证书来识别HTTPS主机名,自签名一个SAN包含a.net的证书或仍可绕过。
  3. 若此系统同时通过PKI检查证书有效性,则无解。
  4. 不明白此计费系统在未登录时为何不使用IP白名单,是因为CloudFlare CDN的IP会变化吗?
  5. 我付费使用该公司提供的网路,未使用信息技术谋取非法利益。

这网路的无线覆盖很垃圾,AP看起来是后安装的(墙壁上有走明线的管子),既没安在房顶上,也没放在靠中间的位置。奇怪的是网络信号5格却时常掉线,令我不得不使用USB网卡(XPS15没有RJ45端口)。

发表评论

电子邮件地址不会被公开。