SS 使用AEAD加密算法，开tls混淆

点击标签看相关主题:
翻墙技术的基本要求就是不能被GFW识别。
也就是说：
1. 给出一段流量，GFW能否识别出使用了翻墙技术？
2. 给出一个服务器，GFW能否识别出它是一个翻墙服务器？
Bandwagon一键脚本搭的SS版本不够新，技术上有个缺陷。不满足2
简单地说原理是这样的：
1. SS协议里有个关键字段的位置是固定的，定义了服务器要做的动作。
2. SS的加密本身是可靠的，第三方不能精确修改这个字段。但是SS之前的加密算法是流加密，也就是说密文和原文是一一对应的。第三方可以通过穷举这个字段的办法想办法命中这个字段的特殊值，一但发生服务器在某些情况下收到一段随机数据后没有断开连接，则猜测这个服务器是SS服务器。

最新版的SS增加了一些AEAD类的加密算法，从流加密变成了块加密。这样就不能直接只针对那个字段穷举，大大增加了探测难度。
AEAD算法包括：
AES-128-GCM
AES-192-GCM
AES-256-GCM
ChaCha20-IETF-Poly1305
XChaCha20-IETF-Poly1305
在具备 AES 加速的 CPU（桌面，服务器）上，建议使用 AES-XXX-GCM 系列，移动设备建议使用 ChaCha20-IETF-Poly1305 系列。

为了装最新版的SS，要手动跑脚本。顺便装个BBR。（原来是用的Bandwagon的一键脚本，CentOS 6，没有BBR）
1. 把Bandwagon VPS停掉，重新安装操作系统，选Debian 8 x64。
2. 装BBR

wget https://raw.githubusercontent.com/kuoruan/shell-scripts/master/ovz-bbr/ovz-bbr-installer.sh
chmod +x ovz-bbr-installer.sh
./ovz-bbr-installer.sh

3. 跑秋水逸冰的SS/SSR四合一脚本

wget --no-check-certificate -O shadowsocks-all.sh https://raw.githubusercontent.com/teddysun/shadowsocks_install/master/shadowsocks-all.sh
chmod +x shadowsocks-all.sh
./shadowsocks-all.sh 2>&1 | tee shadowsocks-all.log

选Shadowsocks-libev，安装过程中选择加密算法chacha20-ietf-poly1305，开混淆(obfs)，混淆模式选tls，同时端口开在443
*是否要开混淆，端口开在哪里，现在在SS圈子成了一个玄学，网上各有各有说法。

评论

  1. ntGeralt六月 08, 2019

    我通过google搜索来到你博客，也算一种缘吧
    我猜测GFW观测到境外ip大流量时，判断是否要封ip，根据‘’‘你这种跑法，我认不认得出来’；例如ss随机端口，它觉得你数据流不像BT，不像思科等端口流量，反而像ss模型，相似度高到一定程度就咔嚓。你跑443\80，他则分析和真实443数据包差异来是否咔嚓。太先进的未知应用层，也属于可疑。

    回复删除
    回复
    1. ǝɔɐǝԀʎzɐɹƆ五月 31, 2023

      你的思路不错哦。 从现在GFW的行为来看，应该是要开始把AI和大数据用起来了。

      删除

发表评论

The Hot3 in Last 30 Days

用浏览器 检测Reality伪装效果 是否搭建成功 排错Troubleshoot

图片
Reality的原理: 当 Reality 节点收到数据包的时候, 如果 Reality 协议的验证通过, 就走节点的翻墙逻辑; 如果 Reality 协议的验证不通过, 就把数据包转发到伪装站. 后续的整个交互过程就像是在和伪装站交互一样. 我们可以简单地用浏览器验证 Reality 伪装效果. 也相当于检测 从你自己到 Reality 节点之间的数据通路是否畅通. 以这样的一个 Reality 节点为例. IP  142.171.237.9 端口  18255 伪装站 learn.microsoft.com 在电脑的hosts文件中, 设置 learn.microsoft.com 解析的IP 为  142.171.237.9   然后在浏览器中, 访问 https://learn.microsoft.com: 18255 可以看到, TLS的锁是正常的. 验证证书, 也是正常的. 从你自己到Reality节点的数据路径是畅通的之后, 如果你的节点还不能用, 那么, 就应该检查你的Reality节点验证信息了 (UUID, 公钥) ======== update 如果是用了中转后的 Reality 节点 原 Reality 节点 IP  142.171.237.9 端口  18255 伪装站 learn.microsoft.com 中转 VPS  IP 142.171.223.56 端口 28828 那么, 在电脑的hosts文件中, 设置 learn.microsoft.com 解析的IP 为  142.171.223.56 然后在浏览器中, 访问 https://learn.microsoft.com: 28828 可以看到, TLS的锁是正常的. 验证证书, 也是正常的.
Read more »

用darkstat统计VPS上的流量

图片
感谢 https://0x3f.org/posts/darkstat-as-a-network-discharge-meter/ https://ilovn.com/2023/03/25/darkstat/ 安装 apt install -y darkstat 启用 darkstat -i 监听网卡 -p 网页端的端口号 如 darkstat -i eth0 -p 8964 页面端查看 http:// 你的vps的IP : 网页端的端口号 如 http:// 12.34.56.78 : 8964 效果类似下面这样 点 host 可以看到数字表格的统计信息. 点其中一条 可以看到更详细的信息. 能看到在本VPS上, 还有指定IP上, 分别用到了什么端口(包括TCP UDP), 以及分别跑了多少流量. 如果你有有更好的工具, 欢迎留言分享!
Read more »

233 sing-box 脚本 TCP 端口转发 Reality 协议 排错 Troubleshoot

图片
233 boy 的 TCP 端口转发的教程 https://233boy.com/sing-box/sing-box-direct/ 下图中示意, 左边的 142.171.237.9 是被墙的VPS, 右边的 142.171.223.56 是用来做端口中转的VPS. 如果你照着教程操作一遍, 发现不能正常使用. 那么本文指导你如何排查问题所在. ======== 首先, 你要理解整个原理是什么. 左边的, 本来的reality协议节点, 底层是TCP直连, 那么是从你的 翻墙客户端(手机/电脑/...) 去连接  142.171.237.9  的 18255 端口. 现在被墙了, 那么无法直接TCP连接了. 右边的, 用于中转的VPS, 设置的 TCP端口中转 的本质是,  142.171.223.56  从端口 28828 收到的TCP数据, 会转发给  142.171.237.9  的 18255 端口.  所以, 你现在可以把本来准备发送给  142.171.237.9  的  18255  端口 的realiy数据包, 发送给  142.171.223.56  的  28828  端口; 142.171.223.56  从端口  28828  收到的TCP数据, 转发给  142.171.237.9  的  18255  端口. ======== 我们延着数据路径一段一段的排查. 1. 从我们的翻墙客户端(手机/电脑/...)连接中转VPS  142.171.223.56  的  28828  端口; a) 可以用 tcp.ping.pe 检测 142.171.223.56  的  28828  端口是否正常; b) 在你自己的电脑  tcping 检测 142.171.223.56  的  28828  端口是否可连接. 2. 在中转VPS上查 sing-box 的 access.log cat /var/log/sing...
Read more »