SSL and man-in-the-middle misunderstanding
我已经阅读了大量与这个问题相关的文档，但是我仍然无法将所有的部分集中起来，所以我想问几个问题。
首先，我将简要描述我理解的身份验证过程，因为在这方面我可能弄错了：客户机启动一个连接，服务器通过公钥、一些元数据和受信任机构的数字签名的组合响应该连接。然后，客户机作出决定，如果她信任服务器，用公钥加密一些随机会话密钥并将其发送回服务器。只能使用存储在服务器上的私钥解密此会话密钥。服务器执行此操作，然后开始HTTPS会话。
所以，如果我在上面是正确的，问题是中间人如何在这种情况下发生攻击？我的意思是，即使有人用公钥截取服务器(例如www.server.com)的响应，并且有某种方法让我认为他是www.server.com，如果没有私钥，他仍然无法解密我的会话密钥。
说到相互身份验证，这都是关于服务器对客户机身份的信任吗？我的意思是，客户机已经可以确定她正在与正确的服务器通信，但是现在服务器想知道客户机是谁，对吗？
最后一个问题是关于相互认证的替代方案。如果我在描述的情况下充当客户机，那么在建立SSL会话之后，如果我在HTTP头中发送登录名/密码会怎么样？正如我看到的，这个信息不能被截取，因为连接已经是安全的，服务器可以依赖它来识别我的身份。我错了吗？与相互认证相比，这种方法的缺点是什么(只有安全问题很重要，而不是实现的复杂性)？
只有在SSL的前提条件之一被打破的情况下，中间人对SSL的攻击才是真正可能的，以下是一些例子；
服务器密钥被盗-意味着攻击者可能是服务器，客户机无法知道。
客户机信任一个不可信的CA(或者根密钥被盗的CA)——任何持有可信CA密钥的人都可以生成一个假装是服务器的证书，客户机将信任它。由于目前浏览器中已经存在CA的数量，这可能是一个真正的问题。这意味着服务器证书似乎会更改为另一个有效证书，这是大多数客户机都会对您隐瞒的。
客户不需要根据其可信CA列表正确验证证书-任何人都可以创建一个CA。如果没有验证，"Ben的汽车和证书"看起来和Verisign一样有效。
客户机受到攻击，并在其受信任的根权限中注入了一个伪造的CA-允许攻击者生成他喜欢的任何证书，客户机将信任它。例如，恶意软件往往会将您重定向到伪造的银行网站。
尤其是2相当讨厌，即使您支付了高度信任的证书，您的站点也不会以任何方式锁定到该证书，您必须信任客户端浏览器中的所有CA，因为它们中的任何一个都可以为您的站点生成一个同样有效的假证书。它也不需要访问服务器或客户机。
First of all I'll describe briefly the authentification procedure as I understand it, maybe I'm mistaken on that step. So, a client starts a connection and a server responds it with combination of public key, some metadata and digital signature of a trusted authority.
号
服务器用一个X.509证书链和一个用自己的私钥签名的数字签名来响应。
Then the client takes the decision if she trusts the server
号
对的。
encrypts some random session key with the public key and sends it back.
号
不。客户机和服务器进行相互会话密钥生成过程，在此过程中会话密钥本身不会被传输。
This session key can be decrypted only with private key stored on the server.
号
不。
Server does this
号
不。
and then the HTTPS session begins.
号
TLS/SSL会话开始，但首先还有更多步骤。
So, if I'm correct above, the question is how does the man-in-the-middle attack can occur in such scenario?
号
通过伪装成服务器并充当SSL端点。客户机必须省略任何授权步骤。遗憾的是，大多数HTTPS会话中唯一的授权步骤是主机名检查。
I mean that even if somebody intercepts the server (e.g. www.server.com) response with public key and then with some means let me think that he is www.server.com, he still wouldn't be able to decrypt my session key without the private key.
号
见上文。没有要解密的会话密钥。SSL连接本身是安全的，与之交谈的人可能不安全。
Speaking about the mutual authentication, is it all about the server confidence about the client identity? I mean, that the client can already be sure that she is communicating with the right server, but now the server wants to find out who is the client, right?
号
对的。
And the last question is about the alternative to the mutual authentication. If I act as a client in the situation described, what if I send a login/password in the HTTP header after the SSL session is established? As I see, this information can't be intercepted because the connection is already secured and the server can rely on it for my identification. Am I wrong?
号
不。
What are the downsides of such approach comparing with mutual authentication (only security issues are important, not the implementation complexity)?
号
它只和用户名/密码一样安全，这比私钥更容易泄露。
在客户机和服务器之间的任何人都可以利用HTTPS发动中间人攻击。如果您认为这不太可能或很少发生，请考虑使用商业产品系统地解密、扫描和重新加密Internet网关上的所有SSL通信。它们的工作原理是向客户机发送一个即时创建的ssl证书，其中的详细信息是从"真正的"ssl证书复制而来的，但使用不同的证书链签名。如果此链以浏览器的任何受信任CA终止，则用户将看不到此MITM。这些产品主要销售给"安全"(警察)公司网络的公司，应在用户知情和同意的情况下使用。不过，从技术上讲，没有什么能阻止ISP或任何其他网络运营商使用它们。(假设NSA至少有一个受信任的根CA签名密钥是安全的)。
如果您正在服务一个页面，那么您可以包含一个HTTP头，指示该页面应该用什么公钥进行签名。这可能有助于向用户提示其"安全"连接的MITM，但这是对首次使用技术的信任。如果Bob还没有"真正的"公钥密码的记录，Mallory只需重写文档中的pkp头。使用这种技术的网站列表(hpkp)令人沮丧的短。其中包括谷歌和Dropbox。通常，一个HTTPS拦截网关会从几个使用hpkp的大型受信任站点的页面中挥动。如果您在不期望的情况下看到hkp错误，请小心。
关于密码，HTTPS连接上的所有内容都由HTTPS保护，但域名除外，域名必须清楚，以便可以路由请求。一般来说，建议不要将密码放在查询字符串中，在该字符串中，密码可以挂在日志、书签等中，但除非HTTPS受到破坏，否则查询字符串不可见。
您所说的一切都是正确的，除了关于会话密钥的部分。CAS的要点是在中间攻击中击败一个人——其他一切都是由SSL本身完成的。客户端身份验证是用户名和密码方案的替代方案。