我理解公钥加密的概念,而HTTPS在证明身份方面对我来说非常有意义。
我不明白的是它如何使用户的请求和网站的响应不可读。网站的公钥是公开的 - 因此,任何人都无法记录网络流量,捕获响应,并使用每个人可用的公钥解码它们吗?他们无法在没有私钥的情况下执行中间人攻击,但为什么他们无法读取用户获得的响应呢?
反之亦然:用户可能会在初始连接时将他们的公钥发送到服务器,因此记录用户网络流量的某人是否可以解密所有请求?
我想我所问的是:双向公钥加密如何提供除ID证明之外的任何内容?
答案 0 :(得分:3)
您对如何建立SSL连接的分析缺少初始化的重要部分,密钥交换。
作为SSL连接设置的一部分,客户端和服务器同意要使用的对称密码,以及与该密码一起使用的密钥。安全性基于密码的强度和对称密钥的保密性,只有客户端和服务器才知道。
生成和共享对称密钥的机制很复杂。
在过于简化的场景中(足以回答被问到的问题)我们可以认为客户端生成要使用的对称密钥。客户端将密钥发送到服务器,其技巧是它使用服务器的公钥在使用非对称密码加密的消息中发送密钥。
由于消息(包含" secret"密钥)是使用服务器的公钥加密的,因此只有服务器可以解密消息,对称密钥是" secret"因为只有服务器和客户端知道对称密钥。
一旦客户端和服务器建立了用于加密的对称密码和密钥,会话的其余部分就使用该密码和密钥来加密和解密消息。
问:任何人都无法解密回复吗?
任何加密"的消息都是可能的。服务器的私钥由具有服务器公钥的任何人解密。然而,这不是SSL的工作方式 - 永远不应使用私钥加密消息。
"技巧" (如果你愿意)是第二个密钥和密码。客户端生成第二个秘密"密钥,仅为自身所知,然后将第二个密钥安全地发送到服务器。 (它通过使用服务器的公钥加密消息中的第二个"密钥来安全地执行此操作。或者客户端和服务器通过执行密钥协商协议来建立密钥调用Diffie-Hellman生成密钥。
密钥建立后,会话的剩余部分使用第二个"秘密"密钥,现在客户端(生成密钥)和服务器都知道。
正如@MarteenBodewes指出的那样,客户端和服务器用于同意对称密钥的机制,包括验证服务器的真实性等。我在上面的答案中给出的过于简化的解释比较复杂。也就是说,说客户端生成对称密钥并将其发送到服务器是不正确的。
无论实际的机制和密钥交换的复杂程度如何,主要的想法是客户端和服务器同意使用对称密码,并就秘密密钥达成一致使用。安全性来自对称密码的强度和密钥的保密性。
答案 1 :(得分:0)
公钥 - 私钥系统非对称(单向)。由公钥加密的数据由私钥解密。了解公钥只能让您为预期的收件人加密邮件。
服务器公钥仅用于加密您的初始请求,该请求只能由服务器解密。使用更传统的名称Bob,Alice和Eve,Bob是我们的服务器,Alice是客户端Web浏览器,Eve是中间人。根据密钥交换的实现方式,Bob和Alice可以互相发送秘密消息,使用其他公钥加密,而Eve无法解密,即使她知道双方的公钥。公钥对解密这些消息毫无用处。 Eve需要知道私钥。尽管Eve知道公钥,并且可以为Bob加密自己的消息,但她无法破译Alice从同一公钥创建的其他消息。
如果只有Bob拥有公私非对称密钥,Alice仍然可以使用Bob的公钥和她选择的对称密钥与Bob协商安全对话。这类似于SSL当前的密钥交换。
SSL(TLS)安全性使用RSA指定其自己的密钥交换协议。 RSA密钥交换仅需要一方(Bob /服务器)具有公共 - 私有密钥对。初始消息从客户端发送到服务器,由服务器公钥加密。使用从客户端最初发送的密钥派生的密钥为客户端加密响应,允许进行安全握手,最终确定双方知道一个或多个会话密钥。交换密钥后,批量数据使用会话密钥加密,会话密钥是对称流密码(RC5,DES,Blowfish,AES)
简短(过度简化)的安全交换:
现在实际的TLS / SSL协商更复杂。但这是一般的想法。你可以在这里看到它的详细描述。