RT ,
一直用 a 域名的自签名证书做的 tls over ss 代理。
最近阻断的频率有点高。
重新注册了新的 域名, 重新生成 tls 证书,重新部署,发现流畅了不少。
可能 gfw 对长期使用 同一个 域名的 tls 加密数据包 做了重点监控。
ps: gfw 不会验证 ca ,不会验证证书是否合法,只检测 common name ,按照这个思路,是不是可以定期用访问量大的 境外 白名单 网站,fake 下 tls 证书。
1
Jirajine 2022-09-10 15:37:33 +08:00
你甚至可以用真正的白名单域名证书 https://www.v2ex.com/t/875975
|
2
cloudsigma2022 OP @Jirajine 他的思路有点怪怪的。
我用的是 ss ( no encryption ) over TLS. ss no encryption , 我已经实现,并放在了 github 上。服务端,用的最老的 ss python 改写的。 https://github.com/0neday/shadowsocks-libev-no-encryption/commit/89b8b63f53fa051e5200683cf394f3f02a973564 ss no encryption 是因为 tls 本身就是加密的,没必要再加一次。 |
3
jim9606 2022-09-10 16:05:13 +08:00 via Android
@cloudsigma2022 你这不靠谱吧,除非你用了 tls 双向认证,不然知道端口的人都能盗用了。
之前用 xray 以为支持客户端认证的,结果有次忘记配客户端证书都能连,麻了。 |
4
cloudsigma2022 OP @jim9606 对,我是双向认证的。
|
5
Jirajine 2022-09-10 16:12:11 +08:00
@cloudsigma2022 他的思路就是握手的时候直接转发到白名单 HTTPS 服务器,握手完成后直接传输无特征加密字节流。
另外你既然不用 ss 加密,直接用 trojan 不就行了。ss over tls 是不信任 tls 的情况使用的,如使用 CDN 这样的中间人。 |
6
cloudsigma2022 OP @Jirajine trojain 有 http 特征太明显了。直接用 tls 更方便
|
7
etnperlong 2022-09-11 03:31:57 +08:00 via Android
@cloudsigma2022 包裹在 TLS 加密的数据流里 也是没有特征的
|