Forwarded from 愛玉大麻 🍼 ฅ(✖ᴥ🔺️)ノ 阿巴阿巴的貓尾海獺q= •̀∞•́ =p
Forwarded from 叮当喵喵-今天你也很可爱
This media is not supported in your browser
VIEW IN TELEGRAM
#在线旅游
千里共婵娟哈
千里共婵娟哈
Forwarded from Project X Channel
警惕 SNI 白名单地区隐蔽的大规模“降级攻击”
根据长期的观察，以及多位身处 SNI 白名单地区的群友的反馈，这些地区的 IPv4 TCP 并不封锁 SS、VMess 这类全随机数裸协议，与其它地区的封锁策略形成了鲜明的反差，是一种非常反常的现象。
我们已知对于封锁翻墙流量，SNI 白名单是一种附带伤害极高的方式，我们也知道，其它地区的 GFW 正在轻易识别并封锁全随机数裸协议。那么请大家思考：为什么某些地区并不在乎附带伤害，对 TLS 采用 SNI 白名单这样的强过滤策略，却“完全不管”全随机数裸协议？
只有一种可能：故意留的口子，除此之外没有任何其它合理解释。我们已知相较于 TLS，全随机数裸协议相当于是把翻墙写在了脸上，更便于识别、掌握情况。且它们普遍缺乏 TLS 的“前向安全”等高级安全特性，非常原始，通过某种方式拿到密码就可以解密以前、以后的所有流量，非常利于监控。所以我认为，这种 SNI 白名单+不封锁全随机数裸协议的组合策略，实质上是在迫使人们从较为安全的 TLS 协议迁移到不够安全的全随机数裸协议，是一场隐蔽的大规模“降级攻击”。
SNI 白名单地区存在的这种非常反常的现象也从侧面证实了，我在多个场合曾提醒过的关于全随机数裸协议的种种风险切实存在，就连 GFW 也明确希望你们使用全随机数裸协议而不是 TLS。目前，这些地区仍可直接使用 REALITY，且它解决了 TLS 令人诟病的 CA 风险。或者，配置 REALITY over SS：https://github.com/XTLS/Xray-core/discussions/1811#discussioncomment-5355075
根据长期的观察，以及多位身处 SNI 白名单地区的群友的反馈，这些地区的 IPv4 TCP 并不封锁 SS、VMess 这类全随机数裸协议，与其它地区的封锁策略形成了鲜明的反差，是一种非常反常的现象。
我们已知对于封锁翻墙流量，SNI 白名单是一种附带伤害极高的方式，我们也知道，其它地区的 GFW 正在轻易识别并封锁全随机数裸协议。那么请大家思考：为什么某些地区并不在乎附带伤害，对 TLS 采用 SNI 白名单这样的强过滤策略，却“完全不管”全随机数裸协议？
只有一种可能：故意留的口子，除此之外没有任何其它合理解释。我们已知相较于 TLS，全随机数裸协议相当于是把翻墙写在了脸上，更便于识别、掌握情况。且它们普遍缺乏 TLS 的“前向安全”等高级安全特性，非常原始，通过某种方式拿到密码就可以解密以前、以后的所有流量，非常利于监控。所以我认为，这种 SNI 白名单+不封锁全随机数裸协议的组合策略，实质上是在迫使人们从较为安全的 TLS 协议迁移到不够安全的全随机数裸协议，是一场隐蔽的大规模“降级攻击”。
SNI 白名单地区存在的这种非常反常的现象也从侧面证实了，我在多个场合曾提醒过的关于全随机数裸协议的种种风险切实存在，就连 GFW 也明确希望你们使用全随机数裸协议而不是 TLS。目前，这些地区仍可直接使用 REALITY，且它解决了 TLS 令人诟病的 CA 风险。或者，配置 REALITY over SS：https://github.com/XTLS/Xray-core/discussions/1811#discussioncomment-5355075
GitHub
REALITY + socks5 = ? · XTLS Xray-core · Discussion #1811
由于 socks 和 http 代理都被无脑阻断，所以这个方法没用，是我云了 最近想到一个“偷证书”类型的代理的加强使用方式(补充：REALITY 不是偷证书)：偷白名单的证书 + socks5 代理 Xray 服务端使用以下配置： { "inbounds": [ { "listen": "127.0.0.1", "por...