我试图了解中间人攻击会如何影响我的网络服务器。
我有一个自签名证书。这个证书可以通过中间人攻击伪造，这意味着我从浏览器发送的所有内容都会被拦截和修改？
如果请求被修改，则 Web 服务器将无法解密，因为服务器上的证书不同。这是正确的吗？
从浏览器发送的请求可以被拦截并可能被重新重定向，但我的服务器上的数据不会受到影响，对吗？
我开始了解证书背后的理论，但如果有人可以提供中间人攻击的真实例子并看看它导致了什么问题，那就太好了。
谢谢
答案1
正如我之前在你的问题，中间人攻击（如果成功）可以拥有加密通道中来回传递的所有数据。
无论是自签名证书还是由受信任根颁发的证书，都可能被伪造，因此，如果您从受信任根向用户颁发证书，请不要被虚假的安全感所蒙骗。使用由受信任根颁发的证书时，我唯一需要克服的问题是当我的计算机遭受 arp 攻击时，让你的用户接受我的建议。如果你考虑一下大多数最终用户，这会有多容易？
现在你能看到问题所在了吗？
一旦最终用户接受我的证书，从那时起我就拥有连接，并且所有数据都会通过我的机器。
答案2
基本上，这种情况是，您已自行签署了证书，因此无法证明其有效性。因此，它可以很好地加密流量，但您无法证明它是您的。如果黑客可以进入您的网站和用户的计算机之间并拦截流量，他就可以解密流量并了解正在发生的事情。（他也可以这样做，注册一个与您的域名相似的域名，然后等待输入错误或发送电子邮件，将他们引导到他的网站而不是您的网站）
User ****** Hacker **** Your website
他之所以能这样做，是因为他也能提供自签名证书。这样一来，用户实际上就是在与黑客通信，而不是与您通信。用户无法分辨两者的区别。事实上，如果黑客愿意，他可以重新加密流量并将其发送回您的网站，然后使用用户凭据开始与您的网站进行通信。或者只是在流量来回移动时清晰地观察流量。
答案3
这并不是说攻击者可以修改流量。而是 SSL 握手开始时未加密，服务器从那时起发送 SSL 证书供客户端使用。如果攻击者从一开始就在那里，他可以用自己的证书替换这个初始证书，然后使用服务器发送的证书加密/解密往返于服务器的流量，使用他自己的证书将其发送给您。
如果证书是由证书颁发机构签名的，那么用同样由 CA 签名的假证书替换它会稍微困难一些。然而，攻击者可以很容易地用自签名证书替换此证书，因此需要警告。
答案4
验证证书时需要考虑两点：
- 验证它是由你信任的实体发出的，并且
- 验证它是否与您尝试联系的服务器的身份相匹配。
CA 颁发的证书
这使用 X.509 证书规范的公钥基础设施定义为此设置的结构。这是一个分层模型，其中有一棵树，其根是认证机构 (CA)，其叶是终端实体证书（特别是服务器证书）。
根 CA 证书通常是自签名的。您的操作系统或浏览器中默认包含许多证书。这就是“信心的飞跃”部分，您相信您的操作系统/浏览器供应商已经审查了 CA，以确保它们能够正确完成工作。一些大型商业 CA 包括 Verisign、Thawte、...
然后，CA 可能会签署其他证书。您可以通过检查证书是否由您信任的 CA 签署来验证从未见过的证书。也可能存在中间 CA。例如，的证书https://www.google.com/已由“Thawte SGC CA”，该协议本身已由“VeriSign, Inc./3 类公共主要认证机构“（我在这里缩短了名称以简化）。 CA 的工作是验证（通过 PKI 外部的方式）向其颁发证书的个人/机构是否是该主机名的合法所有者（例如www.google.com此处）。对于非 EV 证书，这种带外验证的方式有所不同，这通常只需向注册域名的地址发送电子邮件即可（可在谁是目录）。
完成此操作后，假设您不知道是否信任https://www.google.com/，客户端将根据其拥有的信任锚（CA，通常由操作系统/浏览器供应商预先导入）验证此证书。如果您连接到www.google.com，浏览器将获取证书，然后能够找出最顶层颁发者的证书链（每个证书中都有一个颁发者条目），直到找到它信任的证书（在本例中是 Verisign 的证书）。到目前为止，一切顺利，证书是可信的。第二步是检查此证书是否确实适用于此机器。对于 HTTPS，这可以通过检查主机名是否在证书的主题备用名称扩展中来完成，或者作为后备，检查主机名是否在主题可分辨名称的“通用名称”（CN）条目中。这在RFC 2818（服务器身份）。
可能的攻击尝试如下：
- 攻击者使用自己的 CA 伪造证书（无论是否针对该主机名）。由于您的浏览器无法识别他们的 CA，因此无法验证证书。即使他们伪造了颁发者名称，他们也无法伪造签名（因为您使用已经信任的 CA 证书的公钥进行验证）。这里最大的问题之一是签名的强度：使用 MD5 摘要算法已经证明了碰撞攻击，因此 CA 现在改用 SHA-1，这被认为更为可靠。如果您认为 RSAwithSHA1 或 DSAwithSHA1 足够可靠，那么您就不应该遇到问题。
- 攻击者从知名 CA 获得合法证书，但使用不同的主机名（因为 CA 不应将其发送给其他人）。假设他们获得
www.example.com。您尝试连接到www.google.com，他们会将流量重定向到他们的盒子，这将显示可由您信任的 CA 验证的证书，但对于www.example.com。这是主机名验证很重要的地方。您的浏览器将警告您未连接到您想要的主机。
该系统旨在确保，如果 MITM 将流量重定向到他们的机器，客户端将不会接受连接。当然，这只有在用户不忽略浏览器显示的警告时才有效。
自签名证书
原理是一样的，只不过您是 CA，而这个自签名证书也可能直接是服务器证书。如果您创建自己的自签名证书并将其放在您的机器上，您也可以将其作为受信任的颁发机构导入到您的浏览器中，在这种情况下，您可以按照上述相同的步骤进行操作。
某些浏览器（例如 Firefox）会允许您为这些规则添加永久例外。如果您通过其他方式（例如管理员亲自向您提供证书）知道要连接的计算机的证书是什么，您可以选择明确信任它们，即使它们没有由您信任的 CA 签名或名称不匹配。当然，为此，您确实需要事先明确地知道这个特定的证书应该是什么。
如果在任一情况下，用户选择忽略警告并接受重定向到具有不受信任的证书的连接，则 MITM（使用该不受信任的证书）可以查看/重定向/更改流量。