我读过有关这个问题吨文档，但我仍然不能所有的作品扎堆，所以我想问几个问题。
首先，据我了解，因为我可以在这方面被误认为我将简要地描述了验证过程：客户端启动一个连接，其中一个服务器响应公钥，一些元数据和数字签名的组合信任的机构。 然后，客户机需要的决定，如果她信任的服务器，加密用公钥一些随机会话密钥并将其发送回。 该会话密钥只能存储在服务器上的私钥进行解密。 服务器执行此操作，然后将HTTPS会话开始。
所以，如果我是正确的上面，问题是在这样的情况下如何发生的中间人攻击？ 我的意思是，即使有人截获与公共密钥服务器（例如www.server.com）响应，并有一些手段来让我觉得他是www.server.com，他仍然会无法解密我的会话密钥没有私钥。
在谈到相互认证，是一回事有关客户身份的服务器有信心吗？ 我的意思是，客户端已经可以肯定，她是用正确的服务器进行通信，但是现在服务器要找出谁是客户端，对不对？
最后一个问题是关于替代的相互认证。 如果我作为描述的情况下客户端，如果我在SSL会话后的HTTP头发送登录/密码是否成立？ 在我看来，不能被截获该信息，因为连接已被保护，服务器可以依靠它为我的身份。 我错了吗？ 什么是与相互认证相比，这种方法的缺点的（唯一的安全问题是重要的，而不是实现的复杂性）？
人在这方面的中间人的攻击SSL实际上只可能的，如果SSL的前提条件之一是坏了，这里有一些例子;
服务器密钥被窃取-意味着攻击者可以出现在服务器，有没有办法让客户知道。
客户信任一个不可信赖的CA（或者是一个已经有它的根密钥被盗） - 谁拥有可信CA密钥生成一个证书假装是在服务器和客户端将信任它。 随着CA的数量在今天的浏览器预先存在的，这可能是一个真正的问题。 这意味着服务器证书将出现改变到另一个有效的，这是大多数客户将隐藏你。
客户端不打扰正确验证证书针对其的信任的CA的名单 - 任何人都可以创建CA. 由于没有确认，“奔的汽车和证书”会显得就像威瑞信为有效。
该客户端已遭到袭击，假CA已经在他的受信任的根当局已注射 - 允许攻击者产生他喜欢的任何证书，并在客户端将信任它。 恶意软件往往这样做是为了例如您重定向到虚假银行网站。
特别是＃2是相当恶劣的，即使你付出了一个高度受信任的证书，您的网站将不会在锁定该证书的任何方式，你必须相信在客户端的浏览器中所有 CA，因为任何人都可以生成一个假证书您的网站，也同样有效。 它也不需要访问服务器或客户端。
首先，我将简要描述我所理解的认证过程，也许我错在那一步。 因此，客户端启动的连接和服务器将其与可信机构的公钥，一些元数据和数字签名的组合响应。
服务器用X.509证书链，并用自己的私钥签名的数字签名响应。
然后，客户机需要的决定，如果她信任的服务器
正确。
使用加密的公钥一些随机会话密钥并将其发送回。
号的客户端和服务器搞相互会话密钥生成过程，其中会话密钥本身从来没有在所有传输。
该会话密钥只能存储在服务器上的私钥进行解密。
没有。
服务器执行此
没有。
然后HTTPS会话开始。
该TLS / SSL会话开始，但也有更多的步骤第一。
所以，如果我是正确的上面，问题是如何在中间人攻击可以在这样的情况发生？
通过伪装成服务器和充当SSL端点。 客户端将不得不省略任何授权步骤。 可悲的是在大多数HTTPS会话的唯一授权步骤是主机名检查。
我的意思是，即使有人截获与公钥，然后用一些方法让我觉得他是www.server.com的服务器（例如www.server.com）的回应，他仍然不能够解密我的会话密钥没有私钥。
往上看。 没有会话密钥进行解密。 SSL连接本身是安全的，这是谁，你在跟谁说话 ，可能是不安全的。
在谈到相互认证，是一回事有关客户身份的服务器有信心吗？ 我的意思是，客户端已经可以肯定，她是用正确的服务器进行通信，但是现在服务器要找出谁是客户，对不对？
正确。
最后一个问题是关于替代的相互认证。 如果我作为描述的情况下客户端，如果我在SSL会话后的HTTP头发送登录/密码是否成立？ 依我之见，不能被截获该信息，因为连接已被保护，服务器可以依靠它为我的身份。 我错了吗？
没有。
什么是这种方法的缺点进行相互验证比较（仅适用于安全问题是重要的，而不是实现的复杂性）？
这是唯一的用户名/密码，这是一个更容易比私有密钥泄漏的安全。
任何客户端和服务器之间的道路上可以暂存在HTTPS的中间人攻击。 如果你认为这是不可能或很少见，认为有商业产品系统地解密，扫描和整个互联网网关重新加密所有 SSL流量 。 他们通过发送一个SSL证书上即时与“真正的” SSL证书复制的详细信息，创建客户端的工作，但有不同的证书链签名。 如果这条产业链与任何浏览器是可信任CA的终止，这MITM将是对用户不可见。 这些产品主要销售给公司以“安全”（警察）的企业网络，并应与用户的知识和同意使用。 技术上虽然，有什么能阻止互联网服务供应商或任何其他网络运营商的使用。 （这将是安全的假设国家安全局至少有一个受信任的根CA签名密钥 ）。
如果你服页面， 您可以包括HTTP标头指出哪些公共密钥的页面应该签署。 这可能有助于提醒用户他们的“安全”连接的中间人，但它是一个信任上首先使用的技术。 如果Bob还没有“真正的”公共钥匙销的纪录，马洛里刚刚改写文档中的PKP头。 采用这种技术（HSTS）网站的名单是令人沮丧短。 它包括谷歌和Dropbox，他们的信用。 通常，HTTPS拦截网关将通过从使用HSTS的几大受信任的站点页面波。 如果你看到当你没有预料到的HSTS错误，就要小心了。
关于密码，HTTPS连接上的所有内容通过HTTPS固定，除了域名，这需要在透明所以可以对请求进行路由。 在一般情况下，我们建议不要把密码在查询字符串，在那里他们可以在日志中流连，除非HTTPS被攻破书签等，但查询字符串是不可见的。
你所说的一切都只是关于会话密钥部分正确。 CA的关键是要打败一个中间人攻击 - 其他一切都是由SSL本身完成。 客户端的认证是一个用户名和密码方案的替代方案。
