Chrome 与黑魔法师

我曾经在 Chrome 的 123 版本上停留了很长一段时间。

为什么坚持用 Chrome 的老版本？
因为如果升级到 >=124 的版本，我用的 Shadowsocks 就会出问题。时不时就卡住一两分钟。完整关掉 Chrome 重新打开，可以立即恢复，所以并不是被封锁了。但遇到的频率很高，总不能一直这样关掉整个 Chrome，所以我就不去升级了。

不去升级，Google 会自己给我升。有一次我一个疏忽，儿子不知道干了什么事情，就把版本升到了 137。我一边回退版本，一边研究如何禁止 Chrome 自动升级，后来在这方面也算是小有心得。

前不久，我发现这次是必须升级了。因为如果不升级，Google 就不让我用 Gemini 了。网页上元素出来不全。查了一下，应该是因为 123 版本的 Chrome 不支持 ch-ua-form-factors。这事让我焦虑了好一段日子，最终还是下决心动手了。
回想起我的 iPhone，当初「被迫」升级到 iOS 16，也是因为如果不升级就不让我用 ChatGPT。AI 真的是人类「进步」的第一大推动力。

---

我也曾经在 Shadowsocks-libev 3.3.5上停留了很长一段时间，比 Chrome 123 还久。

可不是因为怀旧。尽管我的确一直秉承着「东西还能用就不要去动」的理念，但作为一个从事软件开发的技术人员，跟大势如此脱节并不是什么好事情。我也心知肚明，因此 gfwreport 我都有认真看。现在技术路线是五花八门，乱花渐欲迷人眼，但食死徒对 TLS 盯得很紧，QUIC 也是风口浪尖。我这抱残守缺的做法，倒也能偏安一隅。

这次铁了心要搞个清楚，到底是 Chrome 124 的 X25519Kyber768 搞出了问题，还是伏地魔又玩出了什么鬼花样？

留意到一个现象：用新版的 Chrome 访问 HTTPS 站点，10 秒之后就会准时有 Replay Attack 报到。换成 123 版本就没有问题。还没搞明白 Replay Attack 与我遇到的现象具体有什么因果关系，但二者有关联是肯定的。

或许 X25519Kyber768 导致 TCP 流出现了特别的头部特征？我记得 Chrome 124 刚上线的时候还闹出风波，就是 Client Hello 导致了问题。从我并没被封看来，对方也拿不准，起码没有得出任何结果。但或许跟 AEAD 的抗重放机制一相互作用，就出了问题？个人能力不足，难以最终搞清楚，我不打算继续研究了。

---

这次还是用「土办法」去解决了。没去换技术路线，只是想办法把流量特征藏了起来。可能也是个小众的做法，但在第五、六集这种困难时期，隐身衣可是好东西。

图片由 Google Gemini 生成

解决方法就不在这里细说了。法师的名字要是被对手知道了，那还得了！