Chrome/Firefox中的X25519支持是怎么回事？

Question

RFC8446 8446/TLSv1.3 9.1节说“实现应该支持X25519”。

一个支持列表的在线软件Curve25519将火狐和/Chrome都列为对TLS的支持。

我做了一个实验，用Ed25519创建了一个自签名的TLS证书.Chromium84和Firefox 79都抱怨无法协商密码列表/版本。我还注意到，当连接到本地主机时，他们会启动TLSv1.2握手，但在连接到google时使用TLSv1.3握手。另一方面，wget在连接上没有问题(我使用了--no-check-certificate，但是afaik在这里并不重要)

然后我看了看TLSv1.3握手。两种浏览器都不提供Ed25519作为ClientHello的签名(即使是通过TLSv1.3连接到谷歌时也是如此)。同样，wget也提供它作为ClientHello的一部分。

所以我想这可能是我的发行版(Fedora)的一个平台问题，但是这个博客邮报也声称主要的浏览器不支持X25519。虽然ChromeStatus说它是支持自Chrome 50 (我假设铬和上游铬在这一点上没有不同)。

我完全糊涂了。目前主流浏览器上的X25519支持状况如何？这是谷歌铬与上游铬的问题吗？

Answer 1

..。第9.1节说“实现应该支持X25519”

虽然你似乎引用了RFC的话，但这个短语实际上与你引用的内容有很大的不同：

9.1。强制执行密码套件.应该支持与X25519 RFC7748的密钥交换。

但是，您尝试的是使用带有基于Ed25519的公钥的证书进行身份验证，这与使用X25519进行密钥交换完全不同。X25519密钥交换似乎实际上是在浏览器中实现的，但是Ed25519证书没有实现。

..。两个浏览器都不提供Ed25519作为其ClientHello中的签名。

在Ed25519中不涉及X25519签名。X25519是一个键交换--浏览器支持它。相反，Ed25519是一种签名算法--它不受支持。因此，X25519和Ed25519是使用Curve25519的不同事物。

Answer 2

正如@steffan所指出的，我把X25519 ( Exchange)和ED25519 (数字签名)搞混了。

Chrome支持X25519 (用于DH密钥交换)，但不支持ED25519。

此外，握手中有多个地方列出了协议不同方面的支持算法。

比较wget和for的握手方式：

wget

铬

支持密钥交换的曲线在supported_groups扩展中传递。正如屏幕截图所显示的，Chrome在那里确实提供X25519。

还有另外两个扩展，可以在其中出现ED25519。

首先，用于签署握手的CertificateVerify扩展。"supported_signatures“扩展声明了客户端支持的签名算法。

第二，证书支持的签名算法。根据RFC，应该在"signature_algorithms_cert“扩展中声明这一点，但根据4.2.3节：

"signature_algorithms_cert“扩展适用于证书中的签名，而最初出现在TLS1.2中的"signature_algorithms”扩展适用于CertificateVerify消息中的签名。

但是：

如果没有"signature_algorithms_cert“扩展，那么"signature_algorithms”扩展也适用于出现在证书中的签名。

最后，第9.1节说：

符合TLS标准的应用程序必须支持rsa_pkcs1_sha256 (用于证书)、rsa_pss_rsae_sha256 (用于CertificateVerify和证书)和ecdsa_secp256r1_sha256的数字签名。兼容TLS的应用程序必须支持与secp256r1 (NISTP-256)的密钥交换，并应支持与X25519 RFC7748的密钥交换。