假设我有一些服务器希望与之安全通信。我连接到它，并且它为我提供了一个证书，其中包含它的公钥（假设证书有效）。然后，我接受请求，并使用此公共密钥对其进行加密，然后将所得密文传输到服务器。可以防止这种通信被窃听。但是服务器如何安全地将我的结果返回给我？我缺少公用/专用密钥对，并且没有证书。
#1 楼
那不是很正确。在SSL中，会发生两件事：首先，使用Diffie-Hellman方法之类的协议协商会话密钥。这样会生成一个共享的会话密钥，但不会在各方之间传输密钥。其次，该会话密钥在连接期间用于常规对称加密。
SSL确实使用public /私有是一种方式，因为X509证书用于标识连接的至少一端。这些证书使用非对称密钥对进行签名。
评论
$ \ begingroup $
SSL可以使用Diffie-Hellman生成会话密钥
$ \ endgroup $
–Géal
2011年7月13日在7:48
$ \ begingroup $
@ Soumya92，不，不是，请重新阅读说明并单击en.wikipedia.org/wiki/…的链接，请注意TLS实际上与SSL并不相同。但是原始的SSL握手就像有一个空的PreMasterSecret。
$ \ endgroup $
–查理·马丁（Charlie Martin）
2011年7月13日19:25
$ \ begingroup $
@CharlieMartin注意并更正
$ \ endgroup $
– Soumya
2011年7月13日在19:41
$ \ begingroup $
，不要相信维基百科所说的一切。
$ \ endgroup $
– Jus12
11年7月16日在18:00
$ \ begingroup $
Netscape开发了SSL 2.0，该SSL 2.0现已被完全放弃。开发了SSL 3.0，Netscape蒸发了协议规范，并将其交给IETF，IETF立即将其重命名为TLS 1.0（以符合其命名法）。 SSL 3.0和TLS 1.0几乎相同。没有人（给予或接受）使用TLS 1.1或1.2。使用Diffie-Hellman同意临时密钥是客户端和服务器可以选择同意的一种选择，但是这完全是一种选择，并且由于计算量大而在大多数站点中都不是首选。
$ \ endgroup $
–沼泽雷
2011年8月5日在3:37
#2 楼
结果很大程度上取决于服务器拥有的证书类型和选择的算法-已经给出的答案仅在某些情况下提供。如果客户端没有证书，如您的示例，那么有以下三种可能性：
RSA密钥交换算法：客户端选择一个随机的主密码，并将其发送到服务器，并使用RSA密钥对密码进行加密。服务器证书，其密钥用法中必须启用keyEncipherment位。DH_DSS，DH_RSA，ECDH_ECDSA或ECDH_RSA密钥交换算法：客户端生成一个临时的（几乎随机生成的）Diffie-Hellman密钥来做密钥服务器证书中存在的固定密钥达成协议，该密钥必须在其密钥使用中启用keyAgreement位。 Diffie-Hellman密钥以及证书和客户用自己的临时Diffie-Hellman键回答。服务器证书仅用于通过签名对服务器进行身份验证，主密码完全来自Diffie-Hellman算法。如果客户端确实有证书，则选择是相同的，但是区别在于，在非临时性Diffie-Hellman案例中，客户可以发送包含用于密钥协议的固定密钥的客户证书。
因此，为了简化起见：如果客户没有证书后，客户端要么将加密的“共享机密”发送到服务器，要么生成随机密钥并进行密钥协商。此后，有一个安全共享的密钥，其他所有都只是使用该密钥的对称加密。
评论
$ \ begingroup $
在最新的TLS 1.2中，* DH_ *算法名称被声明为“历史的”（RFC 5246，第49页，位于底部）。
$ \ endgroup $
–PaŭloEbermann
2011年8月16日在21:08
$ \ begingroup $
在TLS 1.2中，有一个特殊的“ signature_algorithms”扩展名，它指定了可能的签名类型。这取代了密钥交换名称中签名算法的定义。因此，TLS 1.2中的密钥交换算法可以只是“ DH”和“ ECDH”。这就是* DH_ *名称具有历史意义的原因-算法本身不会以任何方式被弃用。
$ \ endgroup $
–可以裸体
11年8月16日在22:17
$ \ begingroup $
谢谢。我认为，我将不得不重新阅读整个文档。
$ \ endgroup $
–PaŭloEbermann
11年8月16日在22:19
#3 楼
如果您在一个方向上进行安全通信，则始终可以在两个方向上进行安全通信。发送者可以只生成一个随机字符串，然后将其发送到另一端，然后可以使用该随机字符串作为密钥进行双向通信。公私钥对的唯一目的是为了身份验证，而不是加密。如果我想将我的信用卡信息发送到Amazon，请确保我是在真正地与Amazon对话，而不是其他人。由于Amazon不在乎我是谁（因为无论如何我都会发送用户名和密码），所以我没有理由需要公钥-私钥对或证书。
两边都没有证书，我们仍然可以建立防止窃听的连接。但是双方都不知道他们在跟谁说话。
#4 楼
本质上，客户端生成一个随机对称密钥，并使用服务器的公钥将其发送到服务器。客户端已经知道此对称密钥，因此服务器不需要发回任何信息，从而消除了每个客户端都拥有公共密钥的需求。然后使用相同的随机密钥对请求进行加密，现在双方都拥有了，所以双向通讯仍在继续。
评论
$ \ begingroup $
客户端和服务器都有助于生成主密钥，然后从中导出加密和身份验证密钥。客户端对MSK的贡献使用服务器的公钥加密，服务器的邮件以防滑钉的形式发送。服务器需要具有认证的公共密钥，但是不需要证明自己知道相关的秘密密钥。通过表明他可以解密客户的贡献来暗中实现。
$ \ endgroup $
– Giuper
2011年7月13日在12:37
$ \ begingroup $
@giuper，他们俩都贡献了力量，但是我认为这是不太重要的细节。我认为Soumya92的答案提供了最佳的细节水平。鉴于最初的提问者似乎主要是在询问基本概念和直觉，因此我认为Soumya92的答案是在正确的细节级别上，任何更多细节都有可能使其混淆。
$ \ endgroup $
– D.W.
2011年8月15日，下午3:57
$ \ begingroup $
感谢您回答可以回答问题的术语。不需要更多细节。
$ \ endgroup $
– Bodman
16年6月6日，下午2:53
#5 楼
SSL / TLS是一种协议，允许使用几种算法组合（密码套件）进行密钥交换，身份验证，加密和完整性保护。您问题的答案取决于使用哪一个。在会话启动期间，客户端和服务器协商将使用哪种算法。所有算法都依赖至少一侧（通常是服务器）的身份验证来避免中间人攻击。
主通信将对称加密。以下是获取对称密钥的一些方法：客户端随机选择会话密钥（或会话密钥的某些重要部分），并使用服务器的公共密钥对其进行加密。然后，服务器可以对其解密。
客户端和服务器使用Diffie-Hellman密钥交换算法来获取密钥，然后服务器通过其私钥（可以是私钥）对生成的密钥（和其他会话参数）进行签名。
在两种情况下，客户端都必须检查服务器的证书，以确保它确实与认为要与之交谈的人讲话。
在客户端身份验证的情况下，客户端也必须对会话数据进行签名，以便服务器可以对其进行验证。
在这些签名方案中，每个签名方都有一个证书，该证书将公钥链接到其他证书
还有无证书的身份验证（和密钥交换）方案，例如SRP中基于密码的身份验证。但是，如果没有至少一侧的认证，它将无法正常工作。
评论
$ \ begingroup $
注意：我认为您是指通过证书进行的身份验证。你没提
$ \ endgroup $
– Jus12
11年7月16日在19:06
$ \ begingroup $
当然，客户端也需要证书来支持客户端身份验证。
$ \ endgroup $
– Jus12
11年7月16日在19:07
$ \ begingroup $
@Jus：你是对的。
$ \ endgroup $
–PaŭloEbermann
11年7月16日在19:47
$ \ begingroup $
不是所有人都依赖至少一侧的身份验证。有“ DH_anon”算法无法对任何一方进行身份验证-这些通常无法启用。如果没有其他方法可以验证同行，那么这些人显然很容易受到中间人的攻击。
$ \ endgroup $
–可以裸体
11年8月16日在22:45
$ \ begingroup $
是否有仅执行客户端身份验证的密码套件？哪个？
$ \ endgroup $
–马腾·博德威斯♦
2014年9月8日14:07
#6 楼
服务器向用户提供其证书后，应使用服务器的公共密钥对其进行加密后，应生成一个新的秘密值并由用户返回。双方的初始消息还应包含一个新的随机数。然后，应该使用这三个随机值来派生（通常是值的SHA-1散列）新的共享密钥，以用于将来的对称加密。由于窃听者无法识别第三个值，因此他们将无法派生用于将来通信的对称密钥。只有在派生对称密钥之后，用户才可以开始发送请求。
评论
$ \ begingroup $
随机数用于避免重播攻击，而不是用于“保护”秘密值以防窃听者。并且，TLS不需要服务器具有加密密钥。 DSA密钥也将起作用。在这种情况下，双方将使用DH密钥交换。
$ \ endgroup $
– Jus12
11年7月16日在18:25
$ \ begingroup $
我从没说过现时用于保护秘密价值...
$ \ endgroup $
–布兰登·卡特（Brandon Carter）
11年7月16日在19:21
$ \ begingroup $
我假设您的意思是“窃听者无法辨别的第三个值”是一个随机数。至少多数民众赞成在文字上看起来是这样。
$ \ endgroup $
– Jus12
2011年7月16日19:37
#7 楼
以前所有的答案都解决了这个问题。但我想指出http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html，其中提供了SSL验证的完整工作示例以及使用Firefox连接到amazon.com的使用过程。它很好地解释了如何导出密钥（在证书验证之后）以进行对称加密以实现安全通信。评论
$ \ begingroup $
请编辑仅链接的答案。鼓励链接到外部资源，但是您应该在链接周围添加上下文，以便其他用户可以知道它的含义和原因。此外，如果目标站点无法访问或永久脱机，则应始终引用重要链接中最相关的部分。有关详细信息，请阅读如何写一个好的答案？。
$ \ endgroup $
– e-sushi
2014年9月8日10:34
评论
公共密钥仅在连接建立期间使用，以协商密钥对（或其中两个？）以进行对称加密。您不想对整个连接使用非对称加密。如果考虑一下，如果您具有安全的单向通信，那么您就具有安全的双向通信（假设您完全有一个双向通信通道）。如果我有一条通往您的安全路径，我可以组成一个随机密钥，然后通过该路径将其发送给您，然后您可以使用该密钥对发给我的消息进行加密，从而为您提供一条通往我的安全路径。