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