tls

[hzlmy2002]

No description provided.

[VictoriaRaymond]

Golang的TLS有指纹A，OpenSSL有指纹B，Chrome的TLS有指纹C，这没问题。但有指纹A的必然是Golang的TLS，这个推论是不成立的。即使能推论出指纹A对应的Golang的TLS，那从Golang的TLS对应到V2Ray，还有很长的路要走。

[caonimac]

不要用移动 会被限速 8m/s会被限速到130k

[Cwek]

对于加密流量的识别，主要是还是表面协议的元数据指纹和传输时的流量特征。前者的确可以修正元数据来抹除指纹；后者我认为可以用Mux来解决，因为大部分流量分析是基于一个浏览器一条连接的访问，或者在一个加密通道上负载一个浏览器一条连接的访问（这是常规TLS访问中不同寻常的操作），用Mux的话，会引入多一个随机变量，不知道加密通道上负载了多少个连接访问，应该能一定程度上破坏流量模式的分析。

[caonimac]

楼上两位说的有道理，我移动宽带，不开mux墙外下载一分钟内必掉速到130k/s，开了以后速度保持在4到7M/s之间。我只是测试了一个大文件，几分钟，等多测试几天再来回报。

[caonimac]

好像开了mux，连上后是不掉速。但是也很容易连不上。不开mux一直很好，除了慢。

[caonimac]

昨天fast测速，电信200M宽带，cloudflare，开mux，下行1.6Gbps。

[liberal-boy]

@hzlmy2002 首先这不算漏洞，因为不能证实会产生预料外的结果。要访问 v2ray 的 path 得到 400 的前提是知道 path，但 tls 最多只明文传输 domain，所以这种侦测方法不可行。TLS 握手信息不应该随机，握手信息不停变化无异于此地无银三百两，但可以考虑提供选项，让每个用户的握手信息有差异。

[liberal-boy]

@hzlmy2002 我说的只明文传 domain 是配置文件中的信息只有 domain 明文传输。cipher 顺序的问题我也有异议，因为目前无论什么平台，outbound 都把 chacha20 放最前面，对 AES-NI 不太友好。除了 cipher，其他 TLS 明文传输的信息基本不能改了，所以不需要讨论。一键脚本应该使用随机 path，这个问题不应该有 V 解决。

[liberal-boy]

@hzlmy2002 我对我用语不规范表示抱歉，因为我们只是在讨论问题，不是写论文，所以没有逐字逐句检查。我对 cipher 的异议针对 v2ray，而不是您提出的 issue。一键脚本使用默认路径的问题是您先提出的，我只是再次强调这个问题应该由一键脚本解决。

[VictoriaRaymond]

Moving to discussion, unless there is strong evidence of TLS fingerprint.

[liberal-boy]

@hzlmy2002 如上面教主所言。此外昨晚我们讨论了性能问题，考虑各个平台，chacha20 是比较好的选择。因此目前不考虑在配置文件中提供选项。如果您仍然希望修改 cipher 顺序，可以修改这里的源代码重新编译（仅在 allowInsecureCiphers == false 时有效）。

[klzgrad]

基于TLS参数的指纹检测的实例（Tor）和商业产品（思科Stealthwatch）参见这里的文献综述。一个更加极端的例子见这里和这里（“模仿老版Firefox指纹？我直接把老版Firefox全封了”）。这些应该可以回答TLS参数指纹检测的技术可行性的问题。

和主流客户端（chrome，Firefox）看齐（上策）

正好，我做了一个跟Chrome指纹一模一样的客户端。见：https://github.com/klzgrad/naiveproxy

[skywfan]

最近一个月我连续两个域名被污染了，不知道有没有关系

[github-actions]

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