我试图理解一个中间人攻击会如何影响我的Web服务器。
我有一个自签名证书。 这个证书可以通过中间人攻击来伪造，这意味着我从浏览器发送的所有东西都会被拦截和修改。
如果请求被修改，则不会被Web服务器解密，因为服务器上的证书是不同的。 它是否正确？
浏览器发送的请求可能会被拦截，并可能被redirect，但是我的服务器上的数据不会受到影响，这是正确的吗？
我开始理解证书背后的理论，但是如果有人能够提供一个现实世界的中间人攻击的例子并且看看它造成了什么问题，那将是非常好的。
谢谢
正如我在之前对你的问题的回答中指出的那样，中间人攻击（如果成功的话）可以拥有encryption通道来回传递的所有数据。
从受信任的根签发并自行签发的证书可能是伪造的，所以如果从受信任的根颁发给您的用户，那么不要被误解为虚假的安全感。 我唯一需要解决的问题就是如果我的计算机遭到arp中毒，那么请求用户接受我的请求 。 如果你考虑大多数最终用户，这将是多么容易？
你现在能看到问题吗？
一旦最终用户接受我的证书，我就拥有从这一点的连接，所有的数据通过我的机器。
基本上会发生什么是你自己签署了你的证书，所以你没有办法certificate它是有效的。 所以它encryptionstream量就好，但你不能certificate它是你的。 如果一个黑客可以在你的站点和用户的计算机之间切换，并拦截stream量，他可以解密stream量并阅读正在发生的事情。 （他也可以这样做，注册一个类似于您的域名，并等待input错误或发送电子邮件，将他们引导至他的网站，而不是您的网站）
User ****** Hacker **** Your website
他能做到这一点的原因是他也可以提供一个自签名的证书。 那么用户确实在与黑客通信，而不是你。 用户无法区分。 事实上，如果他希望黑客可以重新encryptionstream量，并将其发送回您的网站，并使用用户凭据与您的网站开始自己的通信stream。 或者只是在来回移动时观察交通状况。
这不是他可以修改stream量。 这就是SSL握手开始未encryption，服务器发送一个SSL证书供客户端使用。 如果攻击者从一开始就在那里，他可以用自己的replace这个初始证书，然后使用服务器发送的那个encryption/解密来自/来自服务器的stream量，使用他自己的证书发送给你。
如果证书是由证书颁发机构签署的，那么用一个也由CA签名的假证书replace它会有点困难。 攻击者可以很容易地用自签名证书replace这个证书，因此是警告。
validation证书时需要考虑两点：
公钥基础设施使用X.509证书。 规范定义了为此设置的结构。 这是一个分层模型，你得到一棵树，根源是证书颁发机构（CA），它的叶子是最终实体证书（特别是服务器证书）。
根CA证书往往是自签名的。 其中一堆默认包含在您的操作系统或浏览器中。 这就是“信仰的飞跃”部分，你相信你的操作系统/浏览器供应商已经审核了CA来正确地工作。 一些大的商业CA是Verisign，Thawte，…
CA然后可以签署其他证书。 您可以通过检查是否已由您信任的CA签名来validation以前从未见过的证书。 也可能有中间的CA。 例如， https://www.google.com/的证书已由“ Thawte SGC CA ”签署，该证书本身已由“ VeriSign，Inc./Class 3公共主要authentication机构 ”（我正在签名这里的名字简化了）。 CA的工作是通过PKI之外的手段来validation其签发证书的个人/机构是该主机名的合法所有者（例如www.google.com here）。 这种带外validation的方式对于非EV证书而言是不同的，这通常是通过发送电子邮件到注册域名的地址（在whois目录中可用）来完成的。
完成此操作后，假设您不知道是否信任https://www.google.com/ ，则客户端会根据其拥有的信任锚来validation此证书（CA通常由操作系统/浏览器供应商预先导入） 。 如果连接到www.google.com ，浏览器将获得证书，然后能够找出最高发行者（每个证书中都有一个发行者条目）的链条，直到find它信任的一个（在这种情况下，一个来自Verisign）。 到目前为止，这么好，证书是可信的。 第二步是检查这个证书是否确实用于这台机器。 对于HTTPS，这是通过检查主机名是否位于证书的主题备用名称扩展名中，或者作为回退来完成的，它位于主题专有名称中的“通用名称”（CN）条目中。 这在RFC 2818（服务器标识）中进行了解释 。
这里可能的攻击尝试如下：
www.example.com 。 您正尝试连接到www.google.com ，他们会将stream量redirect到他们的框中，该框将显示一个可以由您信任的CAvalidation的证书，但对于www.example.com 。 这是主机名称validation重要的地方。 你的浏览器会警告你，你没有连接到你想要的主机。 该系统旨在确保如果MITM将stream量redirect到其机器，客户端将不会接受连接。 这当然只在用户不忽略浏览器显示的警告时才有效。
除了你是CA之外，这个原则是一样的，这个自签名证书也可以直接作为服务器证书。 如果您创build自己的自签名证书并将其放在您的机器上，则还可以将其作为可信任的权威机构在浏览器中导入，在这种情况下，您将按照上述相同的步骤进行操作。
一些浏览器，比如Firefox，会让你为这些规则添加永久的例外。 如果您知道，通过其他方式（例如，pipe理员亲自颁发证书），您要连接的计算机的证书是什么，您可以select明确地信任它们，即使它们没有被签名您信任的CA或名称不匹配。 当然，对于这一点，您确实需要事先知道这个特定的证书应该是什么。
如果在任何情况下，用户select忽略警告并接受redirect到不可信证书的连接，则MITM（使用该不可信证书）可以看到/redirect/更改stream量。