为什么ssl的密码套件包含认证算法?

发布于 2024-11-28 18:33:08 字数 98 浏览 5 评论 0原文

SSL 的握手应协商对等方之间的密码组,其中包含身份验证、密钥交换、加密和摘要算法。但服务器发送给客户端的X.509证书中已经包含了认证算法,那么为什么SSL还要重新协商认证算法呢?

SSL's handshake should negotiate the ciphersuite between peers which contains authentication, key exchange, encryption and digest algorithms. But the X.509 certificate which server sends to client already contains the authetication algorithm, so why does SSL negotiate the authentication algorithm again?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

臻嫒无言 2024-12-05 18:33:08

“密码套件”是关于支持的:客户端和服务器尝试选择一组他们都知道如何处理的算法。例如,如果客户端宣布它可以使用 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,那么服务器就知道客户端将知道如何处理 DSS 签名(通过 Diffie-Hellman 密钥交换计算),从而服务器可以使用带有 DSS 公钥的证书。如果我们假设服务器有多个证书(具有不同的密钥类型),这是有道理的:服务器希望向客户端发送“正确的”证书。

(这有点理论化,因为实际上每个人都支持和使用 RSA —— 或者有时是用 RSA 签名的短暂 Diffie-Hellman。)

The "cipher suite" is about support: the client and the server try to select a set of algorithms that they both know how to handle. For instance, if the client announces that it can use TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, then the server knows that the client will know what to do with a DSS signature (computed over a Diffie-Hellman key exchange), and thus the server can use a certificate with a DSS public key. This makes sense if we suppose that the server has several certificates (with different key types): the server wants to send the client the "right" certificate.

(This is somewhat theoretical because in practice everybody supports and uses RSA -- or sometimes ephemeral Diffie-Hellman signed with RSA.)

时光与爱终年不遇 2024-12-05 18:33:08

首先,正如托马斯的回答中提到的,密码套件是关于支持的(首先)。接下来,SSL/TLS 不仅支持用于身份验证的证书,还支持其他几种机制。

First of all, as mentioned in Thomas' answer, cipher suite is about support (first of all). Next, SSL/TLS supports not only certificates for authentication, but also several other mechanisms.

这个俗人 2024-12-05 18:33:08

但是服务器已经发送给客户端的X.509证书
包含了认证算法,那么SSL为什么要协商
再次验证算法?

因为你把它从后到前。首先协商身份验证算法,然后发送与该算法匹配的证书。

But the X.509 certificate which server sends to client already
contains the authetication algorithm, so why does SSL negotiate the
authentication algorithm again?

Because you have it back to front. The authentication algorithm is negotiated first, then certificates that match that/those algorithm(s) are sent.

安静被遗忘 2024-12-05 18:33:08

除了前面的回复(这是正确的 - 服务器将选择与所选身份验证算法相匹配的证书)之外,我应该注意 X.509 证书不包含身份验证算法。 X.509(或 PKIX)证书包含算法参数。也就是说,RSA 公钥、椭圆曲线参数等。证书不强制要求您使用哪种身份验证方法(RSA 加密或带有 RSA 签名的 Diffie-Hellman)。这是与 TLS 协商的部分。

In addition to the previous replies (which are correct - the server will choose a certificate that matches the selected authentication algorithm), I should note that the X.509 certificate does not contain an authentication algorithm. An X.509 (or PKIX) certificate contains algorithm parameters. That is, RSA public keys, parameters for elliptic curves etc. Which authentication method you use (RSA encryption, or Diffie-Hellman with RSA signatures) is not mandated by the certificate. This is the part that is negotiated with TLS.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文