V2ray-core: [Feature Request] 非硬编码的CipherSuite?(比如从配置文件读取)

[gzzchh]

有这种想法是来自让V2Ray伪装成浏览器的TLS指纹.
但是考虑到浏览器更新速度蛮快的,总不可能让V2Ray跟着Firefox/Chrome同步更新吧.
所以想出了从配置文件指定密码套件的想法
可以在配置文件中留下一个

"cipher":[]

来让高级用户自己挑选加密套件

[tomac4t]

但是考虑到浏览器更新速度蛮快的,总不可能让V2Ray跟着Firefox/Chrome同步更新吧.

Firefox/Chrome 的 ClientHello 的变动某种程度上取决于 OpenSSL/BoringSSL 变动。拿 Chrome 来说，Chrome 72 - 81 （目前稳定版）的 ClientHello 一直没有变动。不能算频繁。（Edited：uTLS 预置了一组常见浏览器指纹，utls.HelloChrome_Auto 就可以模拟最新版本的 Chrome 指纹。Chrome 83 指纹发生变化了，uTLS 也及时更新了。）

所以想出了从配置文件指定密码套件的想法[...]来让高级用户自己挑选加密套件

ClientHello 并不只包含 CipherSuite，它还有一系列的 TLS extension 等等。仅指定 CipherSuite 不能解决问题；此外允许任意修改 CipherSuite 对于不清楚这项特征的用户是有风险的，他们可能会随意指定 CipherSuite。所以我不认为这是个好主意。

[k79e]

目前这类参数不仅仅有cipherlist
他一共是个列表的有
cipher suites //这个东西是二进制值 不是用户随意能指定的 chrome第一个是grease保留项0xeaea
Extension: supported_groups
Extension: signature_algorithms
其实他们都是二进制的 如果用字符串的话 还要程序识别一切然后再正确转换回去 恐怕更容易出问题把 XD

不仅如此还有最致命的一点. Extension: SessionTicket TLS (len=0) 这其实是个服务器端的参数但是不清楚为什么浏览器会发个空的标识.

不仅如此 最后这一切人们真是自己制造了强特征
总共所有的extension的顺序又是个规律. 如论这一切装的多像 结果这些extension的顺序跟浏览器的不一样 一切都是白搭
而且浏览器的tls支持版本里面也有个0xeaea 某些浏览器可能就喜欢这样乱来.

所以总之这个看起来改几下参数就ok的事情最后不仅没有装的更像反而更不像了. 所以这个问题没那么简单 不是一个自定义列表就能ok的. 因为参数值一律都是二进制的 写什么字符串意义不大.

更坑人的是浏览器有个类51 类27的未知padding 然后最后是个正常的padding 而其他程序就一个51的未知padding(原来是分析工具该更新了 ;-))

fq工具我好像没见过最后padding 填零的事情. 这个东西怎么填 什么规范又是个问题. 貌似chrome浏览器喜欢填充为512字节的 (517字节tcp payload)

问题就是这个extension的顺序 能随意更换么? 这个不改 其他装的一模一样也没用啊!
所以这个破参数真是不看不知道一看吓一跳哇!!! 根本没人么想的那么简单!!!!

我又仔细看了看 grease 看起来每个连接都会改变的样子
这真不是随便乱填就行的 还得开启tls相应功能. https://tools.ietf.org/html/draft-ietf-tls-grease-01
如果不能开那个特性 还得指定一个表 每个链接换一个grease值.

所以如果要那样搞的话应该把不同浏览器的配置封装成设置 让用户选择

[github-actions[bot]]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days