V2ray-core: TLS請禁止不安全的ciphers

[okudayukiko]

提交 Issue 之前请先阅读 Issue 指引，然后回答下面的问题，谢谢。
除非特殊情况，请完整填写所有问题。不按模板发的 issue 将直接被关闭。
如果你遇到的问题不是 V2Ray 的 bug，比如你不清楚要如何配置，请使用Discussion进行讨论。

1) 你正在使用哪个版本的 V2Ray？（如果服务器和客户端使用了不同版本，请注明）
最新版

2) 你的使用场景是什么？比如使用 Chrome 通过 Socks/VMess 代理观看 YouTube 视频。
看直播影片

4) 你期待看到的正确表现是怎样的？
我用OpenSSL追了下，V2Ray TLS的TLS1.2沒有禁止ECDHE-RSA-AES128-SHA、ECDHE-RSA-AES256-SHA、ECDHE-RSA-AES128-SHA256這些不安全的算法（即使用"allowInsecureCiphers": false也如此）
openssl s_client -cipher ECDHE-RSA-AES128-SHA -tls1_2 host:port
openssl s_client -cipher ECDHE-RSA-AES256-SHA -tls1_2 host:port

V2Ray TLS也沒禁用TLS 1.1和TLS 1.0

OpenSSL ECDHE-RSA-AES128-SHA256就是TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

openssl s_client -tls1_1 host:port
openssl s_client -tls1 host:port
現在GFW可以降級攻擊TLS。

5) 请附上你的配置（提交 Issue 前请隐藏服务器端IP地址）。

服务器端配置:

    // 在这里附上服务器端配置文件

客户端配置:

    // 在这里附上客户端配置

6) 请附上出错时软件输出的错误日志。在 Linux 中，日志通常在 /var/log/v2ray/error.log 文件中。

服务器端错误日志:

    // 在这里附上服务器端日志

客户端错误日志:

    // 在这里附上客户端日志

7) 请附上访问日志。在 Linux 中，日志通常在 /var/log/v2ray/access.log 文件中。

    // 在这里附上服务器端日志

8) 其它相关的配置文件（如 Nginx）和相关日志。

9) 如果 V2Ray 无法启动，请附上 --test 输出。

通常的命令为 /usr/bin/v2ray/v2ray --test --config /etc/v2ray/config.json。请按实际情况修改。

10) 如果 V2Ray 服务运行不正常，请附上 journal 日志。

通常的命令为 journalctl -u v2ray。

请预览一下你填的内容再提交。

[okudayukiko]

https://github.com/v2ray/v2ray-core/blob/master/transport/internet/tls/config.go#L189
if !c.AllowInsecureCiphers && len(config.CipherSuites) == 0 {
config.CipherSuites = []uint16{
tls.TLS_AES_128_GCM_SHA256,
tls.TLS_AES_256_GCM_SHA384,
tls.TLS_CHACHA20_POLY1305_SHA256,
tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
tls.TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
}
}
改為
if !c.AllowInsecureCiphers && len(config.CipherSuites) == 0 {
config.CipherSuites = []uint16{
tls.TLS_AES_128_GCM_SHA256,
tls.TLS_AES_256_GCM_SHA384,
tls.TLS_CHACHA20_POLY1305_SHA256,
tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
}
}
AES-CBC已經不安全。AES-CCM效能又比AES-GCM低。
@kslr
我沒時間手動編譯。

[kingwilliam]

如真的介怀v2 tls ciphers这刻安全系数不足够, 可考虑在v2前安装如haproxy程式.

再修改config到

    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tlsv12 no-tls-tickets

这样应该如您所需吧

[okudayukiko]

如真的介怀v2 tls ciphers这刻安全系数不足够, 可考虑在v2前安装如haproxy程式.

再修改config到

    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tlsv12 no-tls-tickets

这样应该如您所需吧

AES-CBC已經不安全。dynamic port如果用web server就配置很麻煩。

[kslr]

可以考虑移除掉一部分包含tls 1.0, 1.1不会放弃

[okudayukiko]

可以考虑移除掉一部分包含tls 1.0, 1.1不会放弃

AES-CBC已經不安全。

[kingwilliam]

抱歉, 您的主题是 "TLS请禁止不安全的ciphers" 是讨论安全问题, 而不是讨论“效能”。如想有最佳“效能”, 不做加密就最快。

[tomac4t]

我测了24次，无论是 OpenSSL 还是 BoringSSL，使用 TLS 1.3 平均耗时明显低于 TLS 1.2。例子：

$ time curl --tls-max 1.3 https://example.com/ > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1256  100  1256    0     0    773      0  0:00:01  0:00:01 --:--:--   773

real    0m1.631s
user    0m0.084s
sys 0m0.000s
$ time curl --tls-max 1.2 https://example.com/ > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1256  100  1256    0     0    421      0  0:00:02  0:00:02 --:--:--   421

real    0m2.986s
user    0m0.068s
sys 0m0.020s

当然这已经离题了。

[darhwa]

GFW可以降級攻擊TLS？有什麼證據嗎？

即使有，何不直接在服務器端限制只允許TLS 1.3連接？

[okudayukiko]

GFW可以降級攻擊TLS？有什麼證據嗎？

即使有，何不直接在服務器端限制只允許TLS 1.3連接？

可以的，AES-CBC可以被攻擊了。

[tomac4t]

@darhwa 他删掉了一条记录，说他测试 TLS 1.3 性能比 TLS 1.2 差，他想禁用 TLS 1.3，这就是他不使用 TLS 1.3 的原因：

經測試OpenSSL TLS 1.3 server效能不如OpenSSL TLS 1.2 server

这一指控是虚假的，也证实了某人实质并不在乎安全；至于 GFW 降级攻击，从未发生过，他没有证据。

[darhwa]

至于 GFW 降级攻击，从未发生过，他没有证据。

@tomac4t 多謝提供信息。看來樓主提了個典型的XY problem

[darhwa]

多说几句。TLS每个连接只使用一个CipherSuite，所以不是你写进CipherSuites列表里的都会用到。考虑到v2ray的使用场景，可以假定客户端与服务器都是在你自己控制下，那么每次连接协商出来的肯定都是TLS 1.3连接。至于说有没有降级攻击，即便有，你在服务器端限制只使用TLS 1.3，或者再加上TLS 1.2里安全的那6个（参考 https://ssl-config.mozilla.org 的intermediate或modern配置），并且使用权威机构签发的证书，那么中间人基本上做不了啥。

而且，降级攻击即使实现了，也绝不可能无差别对所有出口流量使用。哪怕是个RC4-MD5，破解起来都至少以小时计，计算成本远非基于机器学习的流量分类可比。反而是在客户端设定CipherSuites更加危险，直接留下肉眼可见特征。

[kotori2]

aes-cbc的问题在于，如果服务端对padding错误显式地返回了错误，才有攻击的可能。然而对于v2ray来说并非如此。
Ref

The standard implementation of CBC decryption in block ciphers is to decrypt all ciphertext blocks, validate the padding, remove the PKCS7 padding, and return the message's plaintext. If the server returns an "invalid padding" error instead of a generic "decryption failed" error, the attacker can use the server as a padding oracle to decrypt (and sometimes encrypt) messages.