SSL和中间人的误解

91

我已经阅读了与该问题有关的大量文档，但仍然无法将所有内容整理在一起，因此我想提出几个问题。

  1. 首先，我将以我理解的方式简要描述身份验证过程，因为在这方面我可能会误会：客户端启动连接，服务器使用公钥，一些元数据和数字签名的组合来响应服务器的连接。受信任的权威。然后，客户端将决定是否信任服务器，并使用公共密钥对某些随机会话密钥进行加密并将其发送回去。只能使用存储在服务器上的私钥来解密此会话密钥。服务器执行此操作，然后HTTPS会话开始。

  2. 因此，如果我在上面是正确的，问题是在这种情况下中间人攻击如何发生？我的意思是，即使有人用公共密钥拦截了服务器（例如www.server.com）的响应，并且有某种手段使我认为他是www.server.com，他仍然无法解密我的会话密钥没有私钥。

  3. 说到相互认证，这是否完全关系到服务器对客户端身份的信心？我的意思是，客户端已经可以确定自己正在与正确的服务器通信，但是现在服务器希望找出谁是客户端，对吗？

  4. 最后一个问题是关于相互身份验证的替代方法。如果我在上述情况下充当客户端，如果在建立SSL会话后在HTTP标头中发送登录名/密码怎么办？如我所见，该信息无法被截取，因为连接已被保护，服务器可以依靠它来识别我。我错了吗？与相互身份验证相比，这种方法的缺点是什么（仅安全问题很重要，而实现的复杂性却不重要）？

security  ssl  man-in-the-middle 
— 瓦迪姆·奇克里（Vadim Chekry）
source

Answers:

103

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

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

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

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

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

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

— 约阿希姆·伊萨克森（Joachim Isaksson）
source
4
还有sslstrip之类的工具，它们会尝试将https链接透明地重写为http链接。
— mpontillo
3
关于证书验证的另一点是客户端需要验证主机名。检查证书的真实性还不够好，它必须颁发给您要与之交谈的实体（请参见此处和此处）。至于sslstrip，最终要由用户检查是否不幸要使用SSL / TLS（尽管HSTS可以提供​​帮助）。
— 布鲁诺
我可以编写一个Chrome（或其他任何浏览器）插件在浏览器加密之前拦截数据吗？
— Rosdi Kasim 2014年
另一个原因是“滥用信任”，例如TürkTrust问题。
— ceremcem 2014年
1
@Remover不是真的...＃1是服务器上的私钥，与真正的公钥配对。在这种情况下，您将与真实服务器对话，但是其他人可以通过居中来解密流量。他们无法修改证书。＃2涉及发送一个完全不同的证书，该证书由“受信任的” CA颁发，该证书对客户端似乎是合法的。然后，攻击者可以代表您代理请求并以这种方式查看消息。两者都会导致折衷，但是＃1在您的控制之下。＃2，不幸的是，不是。
— 基本的
17

首先，我将简要介绍我所了解的身份验证过程，也许我在这一步骤上弄错了。因此，客户端启动连接，而服务器使用公钥，一些元数据和可信机构的数字签名的组合来响应它。

服务器以X.509证书链和使用自己的私钥签名的数字签名作为响应。

然后，客户端可以决定是否信任服务器

正确。

用公共密钥加密一些随机会话密钥，然后将其发送回去。

否。客户端和服务器参与相互会话密钥生成过程，因此会话密钥本身根本不会传输。

只能使用存储在服务器上的私钥来解密此会话密钥。

没有。

服务器这样做

没有。

然后HTTPS会话开始。

该TLS / SSL会话开始，但也有更多的步骤第一。

因此，如果我在上面是正确的，那么问题是在这种情况下中间人攻击如何发生？

伪装成服务器并充当SSL端点。客户将不得不省略任何授权步骤。遗憾的是，大多数HTTPS会话中唯一的授权步骤是主机名检查。

我的意思是，即使有人用公钥拦截了服务器（例如www.server.com）的响应，然后以某种方式让我认为他是www.server.com，他仍然无法解密我的会话密钥没有私钥。

往上看。没有要解密的会话密钥。SSL连接本身是安全的，与您交谈的人可能并不安全。

说到相互认证，这是否完全关系到服务器对客户端身份的信心？我的意思是，客户端已经可以确定自己正在与正确的服务器通信，但是现在服务器想要找出谁是客户端，对吗？

正确。

最后一个问题是关于相互身份验证的替代方法。如果我在上述情况下充当客户端，如果在建立SSL会话后在HTTP标头中发送登录名/密码怎么办？如我所见，该信息无法被截取，因为连接已被保护，服务器可以依靠它来识别我。我错了吗？

没有。

与双向身份验证相比，这种方法的缺点是什么（仅安全问题很重要，而实现的复杂性却不重要）？

它仅与用户名/密码安全，后者比私钥更容易泄露。

— 洛恩侯爵
source
谢谢你的解释。我唯一不了解的是为什么您说客户端不向服务器发送会话密钥？好吧，也许我使用了错误的术语，这里的这些数据被称为“主密码”，但是无论如何，它不是由客户端发送的，而是由服务器私钥解密的吗？
— Vadim Chekry
1
@VadimChekry主密码不是会话密钥。它是两端独立使用的用于生成会话密钥的几段数据之一。该方法是在RFC 2246中描述
— 洛恩侯爵
1
@Chris您的脆弱性要小得多，但是可以进行IP地址欺骗。不能自己检查证书中的对等身份。
— 罗恩侯爵
1
+1在大多数情况下，这是一个很好的答案。但是，有些要点缺乏一词回答的解释。如果您要扩展和/或阐述上述要点（即代替“不。”您可以简要提及实际发生的情况），则可以作为一个明确的答案。那确实会澄清一些事情。谢谢。
— 声音
1
@ tjt263第一个“否”提供了对实际情况的解释。接下来的两个“否”指的是产生第一个“否”的相同误解，并具有相同的解释。下一个也是最后一个“否”是指“我错了”，它指的是OP中引用的信息。因此，很难理解您认为这里实际缺少的内容。
— 罗恩侯爵，
17

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

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

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

— bbsimonbb
source
但这意味着该MITM设备（对流量进行解密/扫描和重新加密的设备）需要访问其中一个受信任的CA，对吗？（以“伪造”服务器证书）。可以说发生这种情况。然后有人破坏了这一点，该信息公开了，并且会出现丑闻，并且CA证书将从所有浏览器中删除，对吗？我的意思是，理想情况下……
— jazzcat
2
不，不。网关上的“ SSL检查”需要即时创建和签名证书，但是不需要根证书即可。它具有一些中间证书，该证书具有链。浏览器是否信任链的根，确定您是否会看到证书错误。在工作中，我们被要求安装fortinet根证书，以便我们的浏览器不会出现证书错误。但是，如果该链以已经受信任的证书终止，则它是透明的。
— bbsimonbb
一位在工作的同事对为什么这些公司网络MITM技术对于Google强制使用SSL是个坏主意的理解有限-他是否真的有一点正确性？
— EmSixTeen
1
对不起，我不明白这个问题！
— bbsimonbb
2
  1. 正确
  2. 不太正确。在这种攻击中，中间服务器会获取您的请求，并代表您将其发送到目的地。然后以结果回应您。实际上，这是中间人服务器，它与您建立安全连接，而不是您要通信的实际服务器。这就是为什么您必须始终检查证书是否有效且受信任的原因。
  3. 可能是正确的
  4. 如果您确定安全连接是可信任的，那么可以安全发送用户名/密码。
— 博努克斯
source
大约2-我假设客户端在连接建立过程中正在彻底检查服务器发送的元数据，并且客户端不信任所有证书。因此，如果-a）客户没有按照我上面所说的做，或b）中间人在某处有由受信任的CA签名的证书，这种情况是否可行？
— Vadim Chekry
1
中间服务器发送有效证书的情况很少发生，去年，如果我记得很好的话，它是与Comodo CA一起发生的。但是通常，如果它是受信任的连接，那么它是完全安全的。
— Boynux
1

您刚才说的所有内容都是正确的，但有关会话密钥的部分除外。CA的目的是打败中间人攻击-其他一切都由SSL本身完成。客户端身份验证是用户名和密码方案的替代方法。

— 大卫·施瓦兹
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.