当您转到 google.com 时，“Subject Public Key Algorithm”下的证书显示:
Elliptic Curve Public Key
ANSI X9.62 elliptic curve prime256v1 (aka secp256r1, NIST P-256)
Key size: 256 bits
这显然是 ECDSA。我认为 ECDSA 仅用于签名/签名而不是 用于 key 交换。我错过了什么？
最佳答案
key 对此没有限制。大多数椭圆曲线 key (伯恩斯坦除外)，包括技术上的这个 key ，都可以用于 ECDSA 签名、ECDH 或 ECMQV key 协议(protocol)，或 ECIES 加密。编码由 X9.62 建立，因为它是第一个发布的，但其他操作使用相同的曲线、键值和编码。 (许多应用程序也使用由 X9.62 首次创建的点编码，但那里有一些变化。)
但证书确实如此。证书(也)有 KeyUsage extension设置为 digitalSignature(并将 ExtendedKeyUsage extension 设置为 id-kp-serverAuth)。这意味着当在 TLS 中使用时，它只能用于 ECDSA 签名以验证服务器。
TLS/SSL 通常使用仅签名证书。如今大多数 TLS 连接都使用“临时” key (不在证书中)进行 key 协议(protocol)结合由用于服务器身份验证的证书 key (或更准确地说是与公钥证书匹配的私钥)，以及可选但很少用于客户端的身份验证。 这提供了(Perfect) Forward Secrecy 这意味着即使服务器私钥后来被泄露，之前 session 的记录也无法解密，因此它们的内容仍然是安全的(至少在这次攻击中是这样；SSL/TLS 仅涵盖传输，从不保护任一端点免受泄露， session 期间或之后)。在 SSL 的早期，人们通常不会为 PFS 而烦恼，但在斯诺登让很多人意识到大规模监控程序之后——尤其是非技术人员，如经理、老板、用户和客户——这些选项变得更加广泛要求或推荐，并使用。
对于 TLS1.0-1.2(和 SSL3，但您不应再使用它，因为它已损坏) key 协议(protocol)和签名(服务器身份验证)在密码组中链接:所有使用 ECDSA 证书进行服务器身份验证的密码组ECDHE key 协议(protocol)，以及所有使用(整数)DSA* 证书进行服务器身份验证的密码组使用(整数)DHE key 协议(protocol)； DHE 中的 E 和 ECDHE 中的最后一个 E 是短暂的。由于 RSA 支持签名和加密，RSA 证书 key 可以用于 key 传输(加密)，但不再推荐这样做，或者它可以用于签署任何一种临时 key 协议(protocol)。 (*对于歇斯底里的葡萄干 SSL/TLS 标准使用 DSS 表示 DSA。)对于 TLS 1.3，这些算法现在单独选择，但在公共(public)网络上实际上需要使用一些临时 key 协议(protocol)，并且几乎需要使用一些签名证书始终如此，因此它们可能会以与现在相同的组合使用，除了不再允许仅使用 RSA 的 key 加密。
参见:
https://security.stackexchange.com/questions/20803/how-does-ssl-work (大熊史诗)
https://security.stackexchange.com/questions/3638/security-of-pki-certificates-certificate-authorities-forward-secrecy
https://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls
https://security.stackexchange.com/questions/35471/is-there-any-particular-reason-to-use-diffie-hellman-over-rsa-for-key-exchange
关于ssl - ECDSA 如何用于 key 交换？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52684809/