Ssl 谁的密钥用于加密HTTPS响应？

我有一个基于HTTPS的web服务器。因此，我的服务器维护它的私钥并发布一个公钥，任何客户端都可以使用它来加密他们的请求。由于只有我的服务器拥有私钥来解密使用服务器公钥加密的任何消息，因此以这种方式发送的任何请求都可以被视为安全的

不过，我的问题在回答部分。当服务器将响应发送回客户端时，服务器将使用谁的公钥加密响应消息

我假设服务器将使用客户端的公钥加密响应（默认情况下？或在配置时？）。如果是这样，服务器是否从发送给服务器的请求中知道客户端的公钥，或者以其他方式知道客户端的公钥

更新： 如果我理解错误，那么在未来的通信中，各方如何知道如何解密另一方发送的消息？是否共享某个密钥或以某种方式共享？

谢谢

没有

公钥和私钥用于协商将在该会话期间使用的对称加密密钥。非对称加密使用两个密钥（私有和公共），对称加密只使用一个密钥

您的服务器将其公钥发送给客户端，客户端验证该密钥签名（检查CA和所有签名），然后使用它加密将用作对称加密密钥的随机选择的密钥，并将其发送给服务器。因为只有私钥才能解密该消息，所以该消息是安全的，只有服务器才能解密。然后服务器接受客户机选择的密钥，并开始使用对称加密传输数据

为什么会这样？非对称加密是相当昂贵的，所以它只是用来确保客户端和服务器可以协商一个安全的对称密钥，而无需以明文形式发送。对称加密很便宜

对称加密也是安全的，问题是双方在开始之前都必须知道密钥，这是一个大问题。通过使用非对称加密协商密钥，解决了这个问题

更新

嗯，@EJP似乎不同意我的答案，所以我试图找到一些更简单的文档来解释这个问题

SSL解释

当您访问银行网站时，银行服务器将自动 使用HTTPS协议将您重定向到其安全站点 可以登录。这将导致您的浏览器和银行网站 使用SSL协商安全通道

这个谈判有点像这样（注意我已经简化了它） 极大地）。浏览器会发送一条消息，说明最新版本是什么 它可以支持的SSL列表和它可以使用的对称算法列表。 web服务器发回一条消息，其中包含SSL版本和 将要使用的算法

它也发送它的证书。客户端验证证书 使用浏览器附带的已知证书；换句话说 换句话说，它检查它是否已由受信任的CA签名，并且 还没有过期

如果证书有效，浏览器将为其生成一次性密钥 会话，使用服务器的公钥对其进行加密（它是 证书），并将其发送到服务器。服务器对数据进行解密 密钥，然后将该密钥与约定的对称算法一起使用 在剩下的时间里

我可能会感到困惑

我的服务器维护其私钥并发布公钥

对

任何客户端都可以用来加密其请求

没有

由于只有我的服务器拥有私钥来解密使用服务器公钥加密的任何消息，因此以这种方式发送的任何请求都可以被视为安全的

这不是它的工作原理

不过，我的问题在回答部分。当服务器将响应发送回客户端时，服务器将使用谁的公钥加密响应消息

都不是

我假设服务器将使用客户端的公钥加密响应（默认情况下？或在配置时？）

不，见下文。在大多数SSL连接中，服务器甚至不知道客户机的公钥，如果客户机确实有公钥的话。这只发生在所谓的“相互”SSL中，其中两个对等方相互验证

如果是这样，服务器是否从发送给服务器的请求中知道客户端的公钥，或者以其他方式知道客户端的公钥

它只有在客户端发送其证书时才知道公钥，而只有在服务器配置为请求公钥时才会知道公钥，而服务器通常不是这样

HTTPS通过SSL运行，SSL使用由两个对等方独立协商的对称会话密钥。它从不传播。服务器的密钥对仅用于在其证书上提供数字签名，客户端可以验证该数字签名，从而证明服务器拥有该证书。从那以后，一切都是对称协商和加密

---

授权：RFC 2246和后续版本。

公钥不直接用于加密HTTPS连接上的任何底层HTTP流量；HTTP请求和HTTP响应都不是以这种方式加密的。相反，在初始SSL握手期间，客户端和服务器之间协商会话特定的对称密钥，然后使用对称密钥加密HTTP连接上双向的所有流量

协商对称密钥的特定机制取决于客户端和服务器之间协商的特定密码套件。此协商始终涉及服务器的公钥和客户端发送的值；它还可能涉及客户机公钥或服务器和客户机的独立连接特定公钥等项

更多详细信息请参见RFC 5246，从这里开始：

---

谢谢你，维托托拉。这很有道理。所以在as期间