我已经阅读了大量与此问题相关的文档，但我仍然无法将所有内容整合在一起，所以我想问几个问题。
首先，我将简要介绍一下我理解的身份验证过程，因为我在这方面可能会弄错：客户端启动连接，服务器使用公钥的组合响应，一些受信任机构的元数据和数字签名。然后客户端决定是否信任服务器，使用公钥加密一些随机会话密钥并将其发回。该会话密钥只能用存储在服务器上的私钥解密。服务器执行此操作，然后HTTPS会话开始。
所以，如果我在上面是正确的，问题是在这种情况下中间人攻击怎么会发生？我的意思是，即使有人用公钥拦截服务器（例如www.server.com）的响应并且有一些方法让我认为他是www.server.com，他仍然无法解密我的会话密钥没有私钥。
谈到相互身份验证，服务器对客户端身份的信心是什么？我的意思是，客户已经可以确定她正在与正确的服务器进行通信，但现在服务器想知道客户端是谁，对吧？
最后一个问题是关于相互认证的替代方案。如果我在所描述的情况下充当客户端，如果在SSL会话建立后在HTTP头中发送登录名/密码怎么办？正如我所看到的，这些信息无法被截获，因为连接已经被保护，服务器可以依赖它进行识别。我错了吗？与相互认证相比，这种方法的缺点是什么（只有安全问题很重要，而不是实现的复杂性）？
答案 0 :(得分：95)
如果SSL中的一个先决条件被破坏，那么SSL中的中间人攻击真的是可能的，这里有一些例子;
服务器密钥被盗 - 意味着攻击者可能看起来像是服务器，并且客户端无法知道 。
客户信任不值得信任的CA（或者其根密钥被盗的CA） - 持有可信CA密钥的人可以生成假装为服务器且客户端信任它的证书。由于今天浏览器中预先存在CA的数量，这可能是一个真正的问题。这意味着服务器证书似乎会更改为另一个有效证书，这是大多数客户隐藏的内容。
客户端无需根据其可信CA列表正确验证证书 - 任何人都可以创建CA.没有验证，“Ben的汽车和证书”似乎与Verisign一样有效。
客户端遭到攻击，并在其受信任的root权限中注入了假CA.允许攻击者生成他喜欢的任何证书，客户端将信任它。恶意软件倾向于这样做，例如将您重定向到虚假的银行网站。
特别是＃2非常讨厌，即使您支付高度可信的证书，您的网站也不会以任何方式锁定该证书，您必须信任客户端浏览器中的所有 CA因为他们中的任何一个都可以为您的网站生成一个同样有效的假证书。它也不需要访问服务器或客户端。
答案 1 :(得分：17)
首先，我将简要介绍一下我理解的认证程序，也许我在这一步上错了。因此，客户端启动连接，服务器使用公钥，某些元数据和受信任机构的数字签名的组合来响应它。
服务器响应X.509证书链和使用自己的私钥签名的数字签名。
然后客户端决定是否信任服务器
正确。
使用公钥加密一些随机会话密钥并将其发回。
没有。客户端和服务器参与相互会话密钥生成过程，从而根本不传输会话密钥本身。
此会话密钥只能使用存储在服务器上的私钥进行解密。
没有
服务器执行此操作
没有
然后开始HTTPS会话。
TLS / SSL 会话开始，但首先有更多步骤。
所以，如果我上面的说法正确，问题是在这种情况下中间人攻击会如何发生？
伪装成服务器并充当SSL端点。客户端必须省略任何授权步骤。遗憾的是，大多数HTTPS会话中唯一的授权步骤是主机名检查。
我的意思是即使有人用公钥拦截服务器（例如www.server.com）的响应然后用某种方式让我认为他是www.server.com，他仍然无法解密没有私钥的会话密钥。
见上文。没有会话密钥可以解密。 SSL连接本身是安全的，您正在与交谈的可能不安全。
谈到相互身份验证，是关于服务器对客户端身份的信心吗？我的意思是，客户端已经可以确定她正在与正确的服务器通信，但现在服务器想要找出谁是客户端，对吧？
正确。
最后一个问题是关于相互认证的替代方案。如果我在所描述的情况下充当客户端，如果在SSL会话建立后在HTTP头中发送登录名/密码怎么办？正如我所见，这些信息无法被截获，因为连接已经被保护，服务器可以依赖它进行识别。我错了吗？
没有
这种方法与相互身份验证相比有哪些缺点（只有安全问题很重要，而不是实现复杂性）？
它只与用户名/密码一样安全，它比私钥更容易泄露。
答案 2 :(得分：16)
Anyone on the road between client and server can stage a man in the middle attack on https. If you think this is unlikely or rare, consider that there are commercial products that systematically decrypt, scan and re-encrypt all ssl traffic across an internet gateway. They work by sending the client an ssl cert created on-the-fly with the details copied from the "real" ssl cert, but signed with a different certificate chain. If this chain terminates with any of the browser's trusted CA's, this MITM will be invisible to the user. These products are primarily sold to companies to "secure" (police) corporate networks, and should be used with the knowledge and assent of users. Technically though, there's nothing stopping their use by ISPs or any other network carrier. (It would be safe to assume the NSA has at least one trusted root CA signing key).
If you're serving a page, you can include an HTTP header indicating what public key the page should be signed with. This may help to alert users to the MITM of their "secure" connection, but it's a trust-on-first-use technique. If Bob doesn't already have a record of the "real" public key pin, Mallory just rewrites the pkp header in the document. The list of web sites using this technology (HSTS) is depressingly short. It includes google and dropbox, to their credit. Usually, a https-intercepting gateway will wave through pages from the few big trusted sites that use HSTS. If you see an HSTS error when your not expecting it, be wary.
Regarding passwords, everything on an https connection is secured by https, except the domain name, which needs to be in the clear so the request can be routed. In general, it's recommended not to put passwords in the query string, where they can hang around in logs, bookmarks etc. But the query string is not visible unless https is compromised.
答案 3 :(得分：2)
答案 4 :(得分：1)
除了关于会话密钥的部分外，您所说的一切都是正确的。 CA的目的是打败中间人攻击 - 其他一切都是由SSL本身完成的。客户端身份验证是用户名和密码方案的替代方案。