Gre*_*gle 4 security https cryptography
我了解公钥密码学的概念，HTTPS 在证明身份方面对我来说非常有意义。
我不明白的是它如何使用户的请求和站点的响应不可读。该站点的公钥是公开的——所以任何人都不能记录网络流量、捕获响应并使用每个人都可用的公钥对其进行解码吗？如果没有私钥，他们将无法执行中间人攻击，但为什么他们不能读取用户得到的响应？
反之亦然：用户可能在初始连接时将他们的公钥发送到服务器，那么记录用户网络流量的人不能解密所有请求吗？
我想我要问的是：双向公钥密码学如何提供身份证明以外的任何东西？
您对 SSL 连接如何建立的分析缺少初始化的一个重要部分，即密钥交换。
作为 SSL 连接设置的一部分，客户端和服务器就要使用的对称密码以及要与该密码一起使用的密钥达成一致。安全性基于密码的强度和对称密钥的保密性，只有客户端和服务器知道。
生成和共享对称密钥的机制很复杂。
在一个过于简单的场景中（足以回答提出的问题），我们可以考虑客户端生成要使用的对称密钥。客户端将密钥发送到服务器，诀窍在于它使用服务器的公钥将其发送到使用非对称密码加密的消息中。
由于消息（包含“秘密”密钥）是使用服务器的公钥加密的，只有服务器才能解密消息，对称密钥是“秘密”的，因为只有服务器和客户端知道对称密钥。
一旦客户端和服务器建立了用于加密的对称密码和密钥，会话的其余部分将使用该密码和密钥来加密和解密消息。
问：任何人都不能解密回复吗？
任何使用服务器私钥“加密”的消息都有可能被拥有服务器公钥的任何人解密。然而，这不是 SSL 的工作方式 - 永远不应该使用私钥对消息进行加密。
“技巧”（如果你愿意的话）是第二个密钥和密码。客户端生成第二个“秘密”密钥，只有自己知道，然后安全地将第二个密钥发送到服务器。（它通过使用服务器的公钥加密消息中的第二个“秘密”密钥来安全地做到这一点。无论是客户端还是服务器通过执行称为 Diffie-Hellman的密钥协商协议来生成秘密钥匙。
密钥建立后，会话的其余部分使用第二个“秘密”密钥，现在客户端（生成密钥的）和服务器都知道该密钥。
正如@MarteenBodewes 指出的那样，客户端和服务器用于就对称密钥达成一致的机制，包括验证服务器的真实性等。比我在上面的答案中给出的过于简化的解释更复杂。也就是说，说客户端生成对称密钥并发送给服务器是不正确的。
无论实际的机制和密钥交换有多复杂，主要思想是客户端和服务器就使用的对称密码达成一致，并就使用的秘密密钥达成一致。安全性来自对称密码的强度和密钥的保密性。
公钥-私钥系统是不对称的（一种方式）。由公钥加密的数据由私钥解密。了解公钥仅使您能够为预期收件人加密消息。
服务器公钥仅用于加密您的初始请求，只能由服务器解密。使用更传统的名称 Bob、Alice 和 Eve，Bob 是我们的服务器，Alice 是客户端 Web 浏览器，而 Eve 是中间的人。根据密钥交换的实现方式，Bob 和 Alice 可以各自向对方发送一条秘密消息，并使用对方的公钥加密，而 Eve 无法解密该消息，即使她知道双方的公钥。公钥对于解密这些消息没有用处。Eve 需要知道私钥。尽管夏娃知道公钥，并且可以为鲍勃加密她自己的消息，但她无法破译爱丽丝根据同一公钥创建的其他消息。
如果只有 Bob 拥有公私非对称密钥，Alice 仍然可以使用 Bob 的公钥和她选择的对称密钥与 Bob 协商安全对话。这与 SSL 当前的密钥交换类似。
SSL (TLS) 安全指定其自己的使用 RSA 进行密钥交换的协议。RSA密钥交换只需要一方（Bob/服务器）拥有公钥-私钥对。初始消息从客户端发送到服务器，并由服务器公钥加密。使用从客户端最初发送的密钥派生的密钥对客户端的响应进行加密，从而允许进行安全握手，最终双方都知道一个或多个会话密钥。交换密钥后，大量数据将使用对称流密码（RC5、DES、Blowfish、AES）会话密钥进行加密
一个简短的（过于简化的）安全交换：
现在实际的 TLS/SSL 协商更加复杂。但这是一般的想法。您可以在此处查看详细描述。
http://en.wikipedia.org/wiki/Transport_Layer_Security
| 归档时间： |
|
| 查看次数： |
1945 次 |
| 最近记录： |