需要一些关于 Https 的见解

Question

如果这个问题真的很幼稚，请原谅，但我尽可能多地搜索，但无法找到相关答案。

过去三天我一直在尝试了解 https 的工作原理。 这些天之前我所知道的只是对称和非对称密码学是如何工作的。 是时候了解一下这两者是如何应用在 ssl-https 上，实现所谓的数据加密和服务器身份验证了。

关于数据加密和防止中间人攻击的一切都很清楚

我似乎并不完全了解服务器身份验证的工作原理，因此非常感谢您的帮助。

目前我的理解如下：

当客户端通过 https 连接到服务器时，服务器会发送一个由 CA 签名的证书。 此服务器证书是一个文本文件，其中包含有关服务器的信息（名称、所有者电子邮件、公钥等）以及数字签名。

此签名是服务器信息内容的哈希，由 CA 私钥加密。

客户端通过再次自己生成服务器信息的哈希并使用 CA 的公钥解密签名来检查签名的有效性。如果解密后的签名值与产生的哈希值相同，则签名和证书后续都是有效的。

请注意，公私加密方案具有双重性质。消息可以用公钥加密，用私钥解密。相同的消息可以用私钥加密，也可以用公钥解密。

我们需要记住的是，证书是一个静态且不可更改的文件。对文件的任何更改都会导致签名不匹配。

我现在将描述一种欺骗https的方法：

假设有一个 URL = https://wwww.TheBank.com/ebanking 的电子银行网站（公共 IP = 195.134.0.1） 我连接到这个 URL，我的浏览器获得了服务器证书。 (theBank.cer)

同时，我是一家网吧的老板。我的网吧有自己的路由器、DNS 和 DCHP 服务器，我可以控制这些服务器。它也有一个网络服务器。

我将网络服务器配置为拥有 ip 195.134.0.1，与银行的相同 我创建了一条到我的路由器的路由，它将 195.134.0.1 的连接请求发送到我的 Web 服务器 我将我的 DNS 配置为将上述银行 URL 指向 195.134.0.1（我的 Web 服务器） 我在我的网络服务器上放置了一个欺诈性银行网站。对于此站点上的任何连接，我都会指示 Web 服务器将我之前下载的证书发送给客户端。（theBank.cer）

一位用户来到我的咖啡馆，连接到我的网络并尝试连接到这家银行。我的服务器将银行证书发送给他。他的浏览器将确认证书的有效性，因为它确实是有效的，并允许连接到我的假网站，因为它的 URL、IP 和主机名与真实的相同。

所以我的欺诈成功了。

当然，这个安全漏洞太明显了，不可能是真的。意思是我在这个服务器身份验证过程中没有理解一些东西。有人可以向我解释一下我在这里缺少什么吗？

Answer 1

一位用户来到我的咖啡馆，连接到我的网络并尝试连接到这家银行。我的服务器将银行证书发送给他。他的浏览器将确认证书的有效性，因为它确实是有效的，并允许连接到我的假网站，因为它的 URL、IP 和主机名与真实的相同。

一旦他的浏览器确认了有效性，它就会知道银行的真实公钥，因为它在证书中。由于您的服务器无法使用与该公钥对应的私钥签署任何内容，也无法解密使用该公钥加密的任何内容，因此您根本无法冒充银行。您所能做的就是让用户相信银行的真实身份，这是您无法冒充的。

我认为您缺少的关键是证书的主要目的是让受信任的权威机构将真实世界的身份绑定到公钥，这样只有该真实世界身份的所有者才知道对应的私钥。

Answer 2

theBank.cer 是 公共 密钥。
你不能用它来解密或签署任何东西。

Answer 3

这个签名是服务器信息内容的哈希值， 由 CA 私钥加密。

客户端通过再次生成-on来检查签名的有效性 他自己的 - 服务器信息的哈希并使用解密签名 CA 的公钥。如果解密后的签名值与 生成的哈希、签名和证书随后是 有效。

这或多或少是 RSA 的情况，但不是 DSA，它只是签名（无加密）。

一般来说，您不应该谈论使用私钥“加密”。这没有任何意义，因为任何人都可以使用公钥解密（因为它是公开的）。加密就是隐藏信息。

您可以使用私钥进行签名和解密/解密。您可以使用公钥来加密和验证签名。

如果您在需要加密和需要签名时混淆（尽管算法与 RSA 非常相似），您最终可能会设计出不提供任何安全性的系统。

更一般地说，公钥证书（X.509 证书，甚至 PGP 证书）的目的是将身份（例如服务器主机名）绑定到公钥。 （见this question on Security.SE。）

我的网络服务器将收到的数据将由公众加密 银行的钥匙

请注意，SSL/TLS 流量不是使用证书的私钥加密的，而是在 SSL/TLS 握手期间协商的共享密钥。

在 SSL/TLS 握手期间，该公钥用于加密预主密钥或签署其他参数（取决于密码套件），最终向客户端证明它正在与服务器通信拥有此公钥的私钥。

由于证书还将服务器名称绑定到公钥，因此客户端知道它正在与正确的服务器进行通信。

这就是为什么验证 (a) 证书是受信任的以及 (b) 它被颁发给客户端想要连接的服务器名称的重要原因。