冲浪小本本儿 (二)(2-3)----伊友闹得欢，r神拉清单，小圈子大新闻始末

xujunpeng · 2024 年12 月 7 日 01:47

https://github.com/XTLS/Xray-core/pull/3884
发酵一月有余，小圈子围绕着”搭建翻墙节点用的web面板是否应强制不对公网开放明文HTTP“搞了个大新闻

来来来，我说这么两句，你们这帮炒作狗啊，你们差不多少点就得了，挖草，左一个右一个的，没完没了了，我作为一个看客觉我都看累了，啊，扣帽子的，啊，权人的，啊，表忠心的，挖草，你们这是干啥啊，最近又出来站队的，干哈啊，老铁，你们中兰海大乱斗呢，我瞅你们是要文攻武卫啊，别炒了，翻友们都看累了，翻友们都想休息休息了，一打开tg全是你们这点比事，还得我开小本本儿八卦你们，说背后的真实，马了个吧子！

前情提要:
最早的时候，想使用一个加密流量协议，就必须使用协议设计者开发的核心。协议设计者不仅要设计协议，还要开发核心。例如，要用VLESS就要使用Xray，要用Trojan就要使用Trojan核心。当然，也有一些核心不设计协议，而是支持更多协议，例如Clash。Xray本身也支持SS、Vmess等多种协议，这些工作大多数都是由开源社区共同维护完成。
为了让新手更容易地使用核心，开发者们在客户端方面直接配合核心开发GUI，让用户方便地使用协议，形成了协议设计——核心开发——配套GUI的一整套完整的上下游。

在服务端方面，一些开发者开发了可以安装在VPS上的Web面板，用户可以通过浏览器访问，点点按钮即可生成配置文件并载入、启用核心，例如基于Xray核心的X-UI。不光小白，机场主也会用这种方式，因为科技的进步就是为了降低各种高端、复杂、有上手难度的项目的使用门槛。
问题出在很多人在使用时通过公网直接用 http://ip:54321 username:admin password:admin 这样的方式登录。RPRX认为“GFW还是能通过明文HTTP拿到你的对称密码来解密流量、拿私钥来中间人攻击，或者直接封锁服务器”，于是@了一堆下游的Web UI面板制作方，提出安全的Web面板不应允许明文HTTP，应强制不对公网开放，并让用户使用SSH端口转发，或者有有效证书和网页伪装的HTTPS。

事件发生：
刚开始大伙聊挺好，几个面板制作者的意思，要强制HTTPS超出范围和责任，可以着重提醒，是否使用明文HTTP访问应该交由用户自己来决定，R神坚持观点。直到有人激怒了R神，R神权瘾犯了，化身"质疑，理解，成为"开始ban人、删文。由于最初激怒R神的对话已被删除，上下文对不上不知道哪句话整急眼了。
此时伊友入场试图与R神互动，在R神的noob嘲讽攻势下，伊友气急败坏的扣出了：您与共产党有联系的大帽 https://github.com/XTLS/Xray-core/pull/3884#issuecomment-2424692836 ，而后R神高中小迷弟入场表示他有”GFW对于XTLS-vision用的模型是专门训练的模型“的消息，R神没有通共！R神反手一记绝杀：我只能认为他们被 Iran GFW 收买了 https://github.com/XTLS/Xray-core/pull/3884#issuecomment-2434117850

事情到此还没有结束，不然也不会闹了一个月，此时已经有大量支持强制HTTPS派入场，https://github.com/XTLS/Xray-core/pull/3884#issuecomment-2437170676 声称反对者在"要求"将R神认为不安全的面板放入xray的README文件，当然我们最后确实看到了R神把不安全的面板放入了README文件，只是以另一种拉清单形式:
Please DO NOT USE plain HTTP panels like 3X-UI, as they are believed to be bribed by Iran GFW for supporting plain HTTP by default and refused to change
请不要使用诸如3x-UI之类的普通HTTP面板，因为据信伊朗GFW贿赂它们以默认支持普通HTTP，并且拒绝更改
https://github.com/XTLS/Xray-core?tab=readme-ov-file#installation

在R神发出了：”麻烦你们有点人性，而不是冷冰冰地看着小白去送人头、坐视不管，谁当年不是小白？“的喟叹之后，一个面板作者发起了是否保留明文HTTP的投票https://github.com/XTLS/Xray-core/pull/3884#issuecomment-2448941061 ，将选票交到用户手里，最终还是投出了反对禁用公网HTTP，R神再次感叹：果然小白没有判断能力，不能把选择权交给小白。

未完待续…

事件核心：
在了解完前因后果后，还得回到问题核心，为什么用明文HTTP访问、操作web面板会泄露私钥

实验准备

x-ui 面板
nginx服务器
wireshark

实验拓扑结构

                 wireshark
                  ↓ 
client chrome-------server x-ui
192.168.136.131      192.168.136.130

在实验中，Wireshark 部署在服务器上，假定为第三方监听者。在公网环境中，客户端与服务器之间的任何途径的设备都能看到wireshark抓到的数据包。
实验用虚拟机创建的内网环境

抓包网页访问
server 启动 x-ui : web server run http on [::]:54321
client 通过chrome访问x-ui : http://192.168.136.131:54321

chrome向x-ui发起请求

GET 请求   /  根路径  HTTP/1.1 http版本
Host: 192.168.136.130:54321  请求域名和端口
...

x-ui向chrome 响应请求

HTTP/1.1 http版本 200响应代码 OK
...
<html>
... 传回的网页内容
</html>

这次HTTP的来回握手没有什么有价值的东西，就不贴HEX源数据了

抓包登录
chrome登录 x-ui username:admin password:admin

可以看到登录时用的路径是 /login ，相当于 http://192.168.136.130:54321/login，同时也传递了账号密码 username=admin&password=admin
以下是原始的 HEX 数据，您可以使用 https://hpd.gasmi.net 打开：
aabbccddeeffee1122334455080045000253075a400080065ef4c0a88883c0a88882c0c5d431eec88463610c1a0c5018402939120000504f5354202f6c6f67696e20485454502f312e310d0a486f73743a203139322e3136382e3133362e3133303a35343332310d0a436f6e6e656374696f6e3a206b6565702d616c6976650d0a436f6e74656e742d4c656e6774683a2032390d0a4163636570743a206170706c69636174696f6e2f6a736f6e2c20746578742f706c61696e2c202a2f2a0d0a582d5265717565737465642d576974683a20584d4c48747470526571756573740d0a557365722d4167656e743a204d6f7a696c6c612f352e30202857696e646f7773204e542031302e303b2057696e36343b2078363429204170706c655765624b69742f3533372e333620284b48544d4c2c206c696b65204765636b6f29204368726f6d652f3130392e302e302e30205361666172692f3533372e33360d0a436f6e74656e742d547970653a206170706c69636174696f6e2f782d7777772d666f726d2d75726c656e636f6465643b20636861727365743d5554462d380d0a4f726967696e3a20687474703a2f2f3139322e3136382e3133362e3133303a35343332310d0a526566657265723a20687474703a2f2f3139322e3136382e3133362e3133303a35343332312f0d0a4163636570742d456e636f64696e673a20677a69702c206465666c6174650d0a4163636570742d4c616e67756167653a207a682d434e2c7a683b713d302e390d0a436f6f6b69653a206c616e673d656e2d55530d0a0d0a757365726e616d653d61646d696e2670617373776f72643d61646d696e

75 73 65 72 6E 61 6D 65 3D 61 64 6D 69 6E 26 70 61 73 73 77 6F 72 64 3D 61 64 6D 69 6E =hex to ascii=> username=admin&password=admin
在这一过程中，明文HTTP会暴露 username 和 password

x-ui 确认账号密码正确后，回传一个cookie给chrome
Set-Cookie: session=MTczMzM0NDE4OHxEdi1CQkFFQ180SUFBUkFCRUFBQVpmLUNBQUVHYzNSeWFXNW5EQXdBQ2t4UFIwbE9YMVZUUlZJWWVDMTFhUzlrWVhSaFltRnpaUzl0YjJSbGJDNVZjMlZ5XzRNREFRRUVWWE5sY2dIX2hBQUJBd0VDU1dRQkJBQUJDRlZ6WlhKdVlXMWxBUXdBQVFoUVlYTnpkMjl5WkFFTUFBQUFGUC1FRVFFQ0FRVmhaRzFwYmdFRllXUnRhVzRBfKw2nR0PWWJCE3uVUiXQq-gea7XJQbjFBkY4YvsUqh-O

chrome在cookies设置session
在这一步暴露了session

session暴露后的账号安全问题


client --- server
        ↑
      attacker

当session暴露后，attacker可以直接通过在浏览器里设置session的方式来登录，甚至都不需要知道账号密码
步骤：
1. http://ip 访问网站
2. 在cookies 里设置 Name为session，value为MTczMzM0NDE4OHxEdi1CQkFFQ180SUFBUkFCRUFBQVpmLUNBQUVHYzNSeWFXNW5EQXdBQ2t4UFIwbE9YMVZUUlZJWWVDMTFhUzlrWVhSaFltRnpaUzl0YjJSbGJDNVZjMlZ5XzRNREFRRUVWWE5sY2dIX2hBQUJBd0VDU1dRQkJBQUJDRlZ6WlhKdVlXMWxBUXdBQVFoUVlYTnpkMjl5WkFFTUFBQUFGUC1FRVFFQ0FRVmhaRzFwYmdFRllXUnRhVzRBfKw2nR0PWWJCE3uVUiXQq-gea7XJQbjFBkY4YvsUqh-O
3. 刷新页面即可直接登录

通过设置session的方式登录和账号密码登录的区别就是，session登录方式在关闭浏览器后会清空session，所以重新访问网站不会维持登录状态；而账号密码登录方式在关闭浏览器后不会自动清空session，因此会维持登录状态

x-ui 在客户端登出后不会销毁session问题
在client logout后，通过session登录依然能够登录，甚至在重启x-ui后依然能够通过session登录
起初我对此感到困惑，为什么重启 x-ui 后还能通过 session 登录。后来我发现，在 etc\x-ui 文件路径下有一个 x-ui.db 文件，只有删除这个文件才能使 session 失效。登出后 session 不失效应该也算是不安全的。

在浏览器端，session 存放在cookies里，而cookies是存在硬盘里的 C:\Users\xxx\AppData\Local\Google\Chrome\User Data\Default\Network\cookies，cookies是个SQLite3 database ，可以用DB Browser for SQLite https://sqlitebrowser.org/dl 打开，通过工具打开后，可以看到一些字段信息已经是加密保存的，当然也有办法解密，本文不做展开
参考：https://blog.csdn.net/u014163312/article/details/131295680 (csdn被挂马谨慎)
解密cookies加密字段： https://blog.csdn.net/jyttttttt/article/details/134972038 (csdn被挂马谨慎)

因此，即便获得了 Cookies 文件，也无法直接解密出 session。想要在客户端获得 session，例如通过木马或脚本，也只能在浏览器运行时从内存中读取 session。

抓包节点配置

客户端在Inbounds 配置节点信息

remark: xijinping
id: 38ea5fba-2c11-4269-eff6-8e1305226d09
端口: 8964
protocol: vless

查看客户端向x-ui post了什么数据

我直接把 HEX原数据放上来

aabbccddeeffee112233445508004500045023964000800640bbc0a88883c0a88882c97cd4318f9c8e5fade1425c50183fd765a8000075703d3026646f776e3d3026746f74616c3d302672656d61726b3d78696a696e70696e6726656e61626c653d747275652665787069727954696d653d30266c697374656e3d26706f72743d383936342670726f746f636f6c3d766c6573732673657474696e67733d253742253041253230253230253232636c69656e7473253232253341253230253542253041253230253230253230253230253742253041253230253230253230253230253230253230253232696425323225334125323025323233386561356662612d326331312d343236392d656666362d386531333035323236643039253232253243253041253230253230253230253230253230253230253232666c6f7725323225334125323025323278746c732d727072782d646972656374253232253243253041253230253230253230253230253230253230253232656d61696c2532322533412532302532322532322532432530412532302532302532302532302532302532302532326c696d6974497025323225334125323030253243253041253230253230253230253230253230253230253232746f74616c47422532322533412532303025324325304125323025323025323025323025323025323025323265787069727954696d6525323225334125323025323225323225304125323025323025323025323025374425304125323025323025354425324325304125323025323025323264656372797074696f6e2532322533412532302532326e6f6e6525323225324325304125323025323025323266616c6c6261636b732532322533412532302535422535442530412537442673747265616d53657474696e67733d2537422530412532302532302532326e6574776f726b25323225334125323025323274637025323225324325304125323025323025323273656375726974792532322533412532302532326e6f6e6525323225324325304125323025323025323274637053657474696e677325323225334125323025374225304125323025323025323025323025323261636365707450726f787950726f746f636f6c25323225334125323066616c7365253243253041253230253230253230253230253232686561646572253232253341253230253742253041253230253230253230253230253230253230253232747970652532322533412532302532326e6f6e6525323225304125323025323025323025323025374425304125323025323025374425304125374426736e696666696e673d253742253041253230253230253232656e61626c656425323225334125323074727565253243253041253230253230253232646573744f7665727269646525323225334125323025354225304125323025323025323025323025323268747470253232253243253041253230253230253230253230253232746c73253232253041253230253230253544253041253744

这一次https://hpd.gasmi.net 不再能够那么清晰解析http报文内的数据，我们改用Hex to ASCII (google:Hex to ASCII) 手动解析数据
Hex 转换到 ASCII 后，包含以下一段数据。前面的数据是 MAC 头、IP 头、TCP 头，可以通过 hpd.gasmi.net 确认，与本文重点的 HTTP 报文内容无关：
up=0&down=0&total=0&remark=xijinping&enable=true&expiryTime=0&listen=&port=8964&protocol=vless&settings=%7B%0A%20%20%22clients%22%3A%20%5B%0A%20%20%20%20%7B%0A%20%20%20%20%20%20%22id%22%3A%20%2238ea5fba-2c11-4269-eff6-8e1305226d09%22%2C%0A%20%20%20%20%20%20%22flow%22%3A%20%22xtls-rprx-direct%22%2C%0A%20%20%20%20%20%20%22email%22%3A%20%22%22%2C%0A%20%20%20%20%20%20%22limitIp%22%3A%200%2C%0A%20%20%20%20%20%20%22totalGB%22%3A%200%2C%0A%20%20%20%20%20%20%22expiryTime%22%3A%20%22%22%0A%20%20%20%20%7D%0A%20%20%5D%2C%0A%20%20%22decryption%22%3A%20%22none%22%2C%0A%20%20%22fallbacks%22%3A%20%5B%5D%0A%7D&streamSettings=%7B%0A%20%20%22network%22%3A%20%22tcp%22%2C%0A%20%20%22security%22%3A%20%22none%22%2C%0A%20%20%22tcpSettings%22%3A%20%7B%0A%20%20%20%20%22acceptProxyProtocol%22%3A%20false%2C%0A%20%20%20%20%22header%22%3A%20%7B%0A%20%20%20%20%20%20%22type%22%3A%20%22none%22%0A%20%20%20%20%7D%0A%20%20%7D%0A%7D&sniffing=%7B%0A%20%20%22enabled%22%3A%20true%2C%0A%20%20%22destOverride%22%3A%20%5B%0A%20%20%20%20%22http%22%2C%0A%20%20%20%20%22tls%22%0A%20%20%5D%0A%7D
这串数据，再使用URL解码（google：url decode）得到

up=0&down=0&total=0&remark=xijinping&enable=true&expiryTime=0&listen=&port=8964&protocol=vless&settings={
  "clients": [
    {
      "id": "38ea5fba-2c11-4269-eff6-8e1305226d09",
      "flow": "xtls-rprx-direct",
      "email": "",
      "limitIp": 0,
      "totalGB": 0,
      "expiryTime": ""
    }
  ],
  "decryption": "none",
  "fallbacks": []
}&streamSettings={
  "network": "tcp",
  "security": "none",
  "tcpSettings": {
    "acceptProxyProtocol": false,
    "header": {
      "type": "none"
    }
  }
}&sniffing={
  "enabled": true,
  "destOverride": [
    "http",
    "tls"
  ]
}

在POST时上传了remark、端口、协议、和密钥id
在这一步暴露一条链接的整个配置，包括密钥（id）

事实上x-ui在后续回包的时候还会把数据回传一次

里面也会包含链接的配置，就不赘述了

到这里，我们已经清楚了在明文 HTTP 下会暴露哪些信息。但我们仍然需要对已经提出的一些解决方案进行检查。

1.1 全过程明文HTTP情况下，把x-ui部署在nginx反代后面

                        server
client ---http--->  nginx ---http---> x-ui

nginx 反代配置参考：https://github.com/MHSanaei/3x-ui?tab=readme-ov-file#nginx-reverse-proxy

   server {
           listen 12345;
           server_name  bu.huan.jian;
           location / {
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
           proxy_set_header Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header Range $http_range;
           proxy_set_header If-Range $http_if_range; 
           proxy_redirect off;
           proxy_pass http://127.0.0.1:54321;
         }
    }

nginx启动
x-ui 启动: web server run http on [::]:54321
chrom访问 http://bu.huan.jian:12345

在明文 HTTP 的情况下，将 x-ui 部署在 Nginx 后面仍然无法解决暴露账号密码、session 和配置文件的问题。

1.2 增加子路径

                             server
client ---http--->  nginx ---http---> x-ui
                     /sub             /sub

nginx反代配置参考： https://github.com/MHSanaei/3x-ui?tab=readme-ov-file#nginx-sub-path

location /sub {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Range $http_range;
    proxy_set_header If-Range $http_if_range; 
    proxy_redirect off;
    proxy_pass http://127.0.0.1:54321;
}

在x-ui 的面板设置 url 根路径成 /test/
nginx启动
x-ui 启动: web server run http on [::]:54321
chrom访问 http://bu.huan.jian:12345/test/

增加子路径后，问题依然无法解决。

为nginx 增加https+增加子路径

                     server
client ---https--->  nginx ---http---> x-ui

 server {
     listen 12345 ssl;
         server_name bu.huan.jian;
         ssl_certificate      ./cert/server.crt; 
         ssl_certificate_key  ./cert/server.key;
         location /test {
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
         proxy_set_header Host $http_host;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header Range $http_range;
         proxy_set_header If-Range $http_if_range; 
         proxy_redirect off;
         proxy_pass http://127.0.0.1:54321;
         }
    }

nginx启动
x-ui 启动: web server run http on [::]:54321
chrom访问 https://bu.huan.jian:12345/test/

即便不加子路径，也不再能看得到传输内容。
增加子路径是为了防止主动探测，就是说通过 https://域名 不再能直接看到页面，需要了解https://域名/sub的sub是什么，sub由于可以自定义，可以叫/xi /jin /ping 想怎么取就怎么取，降低了被识别的可能性

x-ui 启用https

                    server
client ---https--->  x-ui

x-ui本身就能设置证书，过程不再赘述

                       server
client ---https--->  nginx ---https---> x-ui

实际上，前端和后端都可以使用 HTTPS，这种配置更适合在 Nginx 和 x-ui 分别部署在两台公网服务器上。以及是典型的MITM拓扑结构，这部分我会再提

结语：
ss作者曾说过“最适合这个民族的其实是一群小白围着大大转，大大通过小白的夸奖获得自我满足，然后小白的吃喝拉撒都包给大大解决的模式。”，现如今大大又单方面的不认为小白有判断能力主动帮小白做出选择，也算是双方奔赴了。毕竟民主投票投不出历史的正确选择
在支持与反对之间，存在一个中间地带，称为“不支持也不反对”。原本我不想过多评价此事，只是看到没有人进行详细的解释，那么我尽我能力来做（有错误也请指出），在让尽可能多的人有了判断能力后再来做出选择
从技术方面讲，其实我非常认同他的说法“对于小白来说，快速上线是最重要的” https://github.com/XTLS/Xray-core/pull/3884#issuecomment-2439588263 ，从情感层面来讲，我也看到了有人一直在努力试图弥合社区的争执 https://github.com/XTLS/Xray-core/pull/3884#issuecomment-2434811745，最后只能说希望多一点科普、少一点"定于一尊，一锤定音"

[1] 冲浪小本本儿(一)
[2] 冲浪小本本儿(一)(1-1) byedpi/zapret/spoofdpi
[3]冲浪小本本儿(二)---- http-https-ECH 最广泛、最真实、最管用的互联网隐私保护[1]— 简单说两句http；查看http报文；HTTP的TCP握手;OSI模型下的HTTP
[4] 冲浪小本本儿(二)(2-1)---- http-https-ECH 最广泛、最真实、最管用的互联网隐私保护[2]— 简单说两句https；非常重要的自签证书；后量子加密
[5] 冲浪小本本儿 (二)(2-2)----http-https-ECH 最广泛、最真实、最管用的互联网隐私保护[3]— ECH详谈
[6]冲浪小本本儿 (二)(2-3)----伊友闹得欢，rprx拉清单，小圈子大新闻始末
[7]冲浪小本本儿 (三) — 什么是desync类工具，还有哪些直连类型工具；什么是正代反代，如何完成反代；steam++这类工具是怎么完成不连接第三方服务器直连的；简易反代制作；当你直连一个网站时外部能看到什么
[8]冲浪小本本儿 (三)(3-1) 什么是tun模式，为什么clash的tun模式叫tun模式，而不叫tunnel
[9] 冲浪小本本儿 (四) — 当你通过proxy翻墙时，会在日志里、服务器上留下什么，通过代理连接有哪些风险
[10] 冲浪小本本儿 (五) — 被墙的网站有哪些分级，一些简单的dns污染名单，sni阻断名单，直连有哪些风险
[11] 冲浪小本本儿 (六) — 如何对网站方隐藏自身，什么是浏览器指纹，怎么改变；分析怎么逃过宏迪追杀
[12] 冲浪小本本儿 (七) — 如何处理dns污染；低延迟但被污染的dns、高延迟但正确的dns怎么选？域名分流；doh本身被封了怎么办
[13] 冲浪小本本儿 (七)(7-1)— 测试doh/dot/doq 是否被墙方法；adguard home自签证书让局域网内浏览器用上doh
[14]冲浪小本本儿(七) (7-2) — 旧文新更，从“DNS 在代理环境中的应用”说起；Firefox 使用自带的代理设置时， "使用 SOCKS v5 时代理 DNS 查询"开还是不开？令人尴尬的代理解析选择
[15]冲浪小本本儿(七) (7-3) — 不知道什么时候会开始写、能用得上的ODOH

huxijin · 2024 年12 月 7 日 02:17

闹麻了。觉得需要默认htts( 据说也被党国破解了)自己fork一个带加密的面板不就完了。

xujunpeng · 2024 年12 月 7 日 22:44

破解一眼炒作。
x-ui 本来就有证书、密钥填入选项来启用HTTPS

xijinping · 2024 年12 月 8 日 10:23

伊朗那边的傻逼挺多，和老中不相上下，我也不止一次看到他们问弱智问题了
rprx最近搞的xhttp挺有意思，上下行拆分，有种用i2p的感觉

xujunpeng · 2024 年12 月 22 日 20:47

谁不是从小白过来的呢，其实我跟R神没有交流过，连群都没加过，纯吃瓜
xhttp在玩了，精甚细腻， PACKET-UP配通了，上下行分离还没整