SSL和中间人的误解

Question

我已经阅读了有关此问题的大量文档，但仍然无法将所有内容整理在一起，因此我想提出几个问题。首先，我将以我理解的方式简要描述身份验证过程，因为在这方面我可能会误会：客户端启动连接，服务器使用公钥，一些元数据和数字签名的组合来响应服务器的连接。受信任的权威。然后，客户端将决定是否信任服务器，并使用公共密钥对某些随机会话密钥进行加密并将其发回。只能使用存储在服务器上的私钥来解密此会话密钥。服务器执行此操作，然后HTTPS会话开始。因此，如果我在上面是正确的，那么问题是在这种情况下中间人攻击如何发生？我的意思是，即使有人用公共密钥拦截了服务器（例如www.server.com）的响应，并且有某种手段使我认为他是www.server.com，他仍然无法解密我的会话密钥没有私钥。说到相互认证，这是否完全关系到服务器对客户端身份的信心？我的意思是，客户端已经可以确定自己正在与正确的服务器通信，但是现在服务器希望找出谁是客户端，对吗？最后一个问题是关于相互身份验证的替代方法。如果我在上述情况下充当客户端，如果在建立SSL会话后在HTTP标头中发送登录名/密码怎么办？如我所见，该信息无法被截取，因为连接已被保护，服务器可以依靠它来识别我。我错了吗？与相互身份验证相比，这种方法的缺点是什么（仅安全问题很重要，而实现的复杂性却不重要）？

Answer 1

客户端和服务器之间的任何人都可以在https的中间攻击中派人。如果您认为这种情况不太可能发生或罕见，请考虑使用一些商业产品来系统地解密，扫描和重新加密跨Internet网关的所有 SSL流量。他们通过向客户端发送即时创建的ssl证书进行工作，该证书包含从“真实” ssl证书复制而来的详细信息，但使用其他证书链进行了签名。如果此链以浏览器的任何受信任CA终止，则该MITM对用户不可见。这些产品主要出售给公司以“保护”（警察）公司网络，并且应在用户的知识和同意下使用。从技术上讲，没有什么可以阻止ISP或任何其他网络运营商对其的使用。（可以安全地假设NSA 至少具有一个受信任的根CA签名密钥）。

如果要提供页面，则可以包含HTTP标头，以指示应使用该页面签名的公共密钥。这可能有助于向MITM用户提醒其“安全”连接，但这是一种首次使用信任技术。如果Bob尚未记录“真实的”公共密钥图钉，那么Mallory只会重写文档中的pkp标头。使用此技术（HPKP）的网站列表非常简短。它包括谷歌和投递箱，以他们的功劳。通常，https拦截网关会在使用HPKP的少数几个大型受信任站点中浏览页面。如果您不希望看到HPKP错误，请当心。

关于密码，https连接上的所有内容均由https保护，但域名（明文除外）必须是明文，以便可以路由请求。通常，建议不要将密码放在查询字符串中，因为它们可能会在日志，书签等中徘徊。但是，除非https被破坏，否则查询字符串是不可见的。

Answer 2

实际上，只有打破了SSL的前提之一，才可能对SSL进行中间人攻击。

• 服务器密钥被窃取-意味着攻击者可以出现在服务器，有没有办法为客户就知道了。

• 客户端信任一个不可信的CA（或已经被盗用其根密钥的CA）-持有可信CA密钥的任何人都可以生成一个伪装成服务器的证书，并且客户端将信任它。随着当今浏览器中已经存在大量的CA，这可能是一个真正的问题。这意味着服务器证书似乎将更改为另一有效证书，这是大多数客户端都对您隐藏的东西。

• 客户端不必费心根据其受信任的CA列表正确地验证证书-任何人都可以创建CA。未经验证，“ Ben的汽车和证书”将与Verisign一样有效。

• 客户端已受到攻击，伪造的CA已注入其受信任的根权威中-允许攻击者生成他喜欢的任何证书，客户端将信任它。恶意软件通常会这样做，例如将您重定向到伪造的银行站点。

特别是＃2相当令人讨厌，即使您为高度信任的证书付费，您的网站也不会以任何方式锁定该证书，您必须信任客户端浏览器中的所有 CA，因为它们中的任何一个都可能会为您生成伪造的证书您的网站同样有效。它还不需要访问服务器或客户端。