我有一个基于 HTTPS 的 Web 服务器。因此，我的服务器维护其私钥并发布任何客户端都可以用来加密其请求的公钥。由于我的服务器是唯一拥有私钥来解密使用服务器公钥加密的任何消息的服务器，因此以这种方式发送的任何请求都可以被认为是安全的。
但是我的问题是在响应部分。当服务器将响应发送回客户端时，服务器将使用谁的公钥来加密响应消息？
我假设服务器将使用客户端的公钥来加密响应（默认情况下？或配置？）。如果是这样，服务器是否从它发送给服务器的请求中知道客户端的公钥，或者以其他方式？
更新： 如果我理解不正确，那么在未来的通信中，每一方如何知道如何解密另一方发送的消息？某些密钥是共享的还是以某种方式共享？
谢谢！
【问题讨论】：
标签： ssl https public-key-encryption public-key
公钥不直接用于加密 HTTPS 连接上的任何底层 HTTP 流量； HTTP 请求和 HTTP 响应都不会以这种方式加密。相反，在初始 SSL 握手期间，客户端和服务器之间会协商会话特定的对称密钥，然后使用对称密钥对 HTTP 连接上双向的所有流量进行加密。
协商对称密钥的具体机制取决于客户端和服务器之间协商的特定密码套件。这种协商总是涉及到服务器的公钥和客户端发送的一个值；它还可能涉及客户端公钥或来自服务器和客户端的单独连接特定公钥等项目。
更多细节可以在 RFC 5246 中找到：
【讨论】：
无。
公钥和私钥用于协商对称加密密钥，该密钥将在该会话期间使用。非对称加密使用两个密钥（私有和公共），对称加密只使用一个。
您的服务器将其公钥发送给客户端，客户端验证该密钥签名（检查 CA 和所有内容）然后使用它来加密一个随机选择的密钥，该密钥将用作对称加密密钥，并将其发送到服务器。因为只有私钥可以解密该消息，所以消息是安全的，只有服务器可以解密它。然后服务器接受客户端选择的密钥，并开始使用对称加密传输数据。
为什么会这样？非对称加密在计算上非常昂贵，因此它仅用于确保客户端和服务器可以协商安全的对称密钥，而无需以纯文本形式发送。对称加密很便宜。
对称加密也是安全的，问题是双方都必须知道密钥才能启动，这是个大问题。通过使用非对称加密来协商密钥，解决了这个问题。
更新
嗯，@EJP 似乎不同意我的回答，所以我试图找到更多的文档来简单地解释这件事。
http://www.techradar.com/news/software/how-ssl-and-tls-works-1047412
SSL 解释
当您访问银行的网站时，银行的服务器会自动 在您之前使用 HTTPS 协议将您重定向到其安全站点 可以登录。这将导致您的浏览器和银行的网站 使用 SSL 协商安全通道。
这个谈判有点像这样（注意我已经简化了它 大大）。浏览器发送一条消息，说明最新版本是什么 它可以支持的 SSL 以及它可以使用的对称算法列表。 Web 服务器发回一条消息，其中包含 SSL 的版本和 将使用的算法。
它也发送它的证书。客户端验证证书 使用浏览器附带的已知证书；其他 换句话说，它检查它是否已由受信任的 CA 签名，并且它 还没有过期。
如果证书有效，浏览器会生成一个一次性密钥 会话，用服务器的公钥加密它（它是 证书），并将其发送到服务器。服务器解密 密钥，然后将该密钥与约定的对称算法一起使用 在接下来的会话中。
我可能会感到困惑。
【讨论】：
我的服务器维护它的私钥并发布一个公钥
是的。
任何客户端都可以用来加密他们的请求。
没有。
由于我的服务器是唯一拥有私钥来解密使用服务器的公钥加密的任何消息的服务器，因此以这种方式发送的任何请求都可以被认为是安全的。
这不是它的工作原理。
但是我的问题是在响应部分。当服务器将响应发送回客户端时，服务器将使用谁的公钥来加密响应消息？
都没有。
我假设服务器将使用客户端的公钥来加密响应（默认情况下？或配置？）。
没有。见下文。在大多数 SSL 连接中，服务器甚至不知道客户端的公钥，即使客户端确实有一个。这仅发生在所谓的“相互”SSL 中，其中两个对等方相互进行身份验证。
如果是这样，服务器是否从它发送给服务器的请求中知道客户端的公钥，或者以其他方式？
只有当客户端发送它的证书时它才知道公钥，只有在服务器配置为请求它时才会发生这种情况，而通常不是这样。
HTTPS 通过 SSL 运行，SSL 使用由双方独立协商的对称会话密钥。它永远不会被传输。服务器的密钥对仅用于在其证书上提供数字签名，客户端可以验证该数字签名，从而证明该服务器拥有该证书。从那里开始就是对称协商和加密。
授权：RFC 2246 和后续版本。
【讨论】：