logo标签列表

SSL和中间人攻击误解

securitysslman-in-the-middle
102

我已经阅读了大量与此问题相关的文档，但仍然无法将所有内容联系起来，所以我想问几个问题。

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

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

  3. 说到相互认证，这是关于服务器对客户端身份的信心吗？我的意思是，客户端已经可以确保她正在与正确的服务器通信，但现在服务器想弄清楚客户端是谁，对吧？

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

5个回答
115

只有在 SSL 的前提条件被破坏时，中间人攻击才是真正可能的，以下是一些例子：

  • 服务器密钥已被窃取 - 这意味着攻击者可以伪装成服务器，而客户端无法得知。

  • 客户端信任不可信任的CA（或其根密钥已被窃取） - 持有受信任 CA 密钥的人可以生成假冒服务器的证书，而客户端将信任该证书。由于现今浏览器中预存在的CA数量很多，这可能是一个真正的问题。这意味着服务器证书将显示为更改为另一个有效证书，大多数客户端会将此隐藏。

  • 客户端没有正确根据其可信CA列表验证证书 - 任何人都可以创建 CA。如果没有验证，“Ben's Cars and Certificates” 将看起来与 Verisign 一样有效。

  • 客户端遭到攻击并注入了一个假CA到其受信任的根权限 - 允许攻击者生成任何他想要的证书，而客户端将信任它。恶意软件往往会这样做，例如重定向您到假银行网站。

尤其是＃2非常令人讨厌，即使您为高度受信任的证书付费，您的站点也不会以任何方式锁定该证书，您必须信任客户端浏览器中的 所有 CA，因为其中任何一个都可以为您的网站生成一个假证书，而这个假证书与真正的证书一样有效。它也不需要访问服务器或客户端。

4
还有一些工具，比如sslstrip，它会尝试将https链接透明地改写为http链接。 - mpontillo
3
关于证书验证的另一个要点是客户端需要验证主机名。仅验证证书是否真实并不足够，它必须针对你想要通信的实体发布（参见这里和这里）。至于sslstrip，不幸的是（尽管HSTS可能会有所帮助），最终由用户决定是否使用SSL/TLS。 - Bruno
我能否编写一个可以拦截浏览器加密数据的Chrome插件（或其他任何浏览器的插件）？ - Rosdi Kasim
1
@Remover 不完全是这样... #1 是服务器上的私钥，与真实公钥配对。在这种情况下，您将与真实服务器通信，但其他人可以通过处于中间位置来解密流量。他们无法修改证书。#2 包括发送一个完全不同的证书，由“受信任”的 CA 发布，看起来是客户端的合法证书。攻击者可以代理您的请求并以此方式查看消息。两者都会导致妥协，但 #1 在您的控制之下。不幸的是，#2 不是。 - Basic
1
这个答案虽然在技术上没有错，但是它来自于NSA丑闻和广泛使用SSL检查之前的美好时光。请参见我下面的答案。 - bbsimonbb
显示剩余3条评论
21

更新 2022

由于证书透明度，本回答现已过时。

原始回答

在客户端和服务器之间的任何人都可以对https进行中间人攻击。如果你认为这很不可能或很少见，那么请考虑到有商业产品会系统地解密、扫描并重新加密整个互联网网关上的所有ssl流量。它们通过向客户端发送一个即时创建的ssl证书，其中包含从“真实”的ssl证书复制的详细信息，但是使用不同的证书链签名。如果此链以浏览器信任的任何CA为终止点，则用户将看不到此MITM。这些产品主要销售给公司以“保护”（监控）企业网络，并应在用户知情和同意的情况下使用。但从技术上讲，没有任何阻止ISP或任何其他网络运营商使用它们的东西。（可以安全地假设NSA 拥有至少一个受信任的根CA签名密钥。）

如果您正在提供页面服务，您可以包含一个HTTP标头，指示该页面应该使用哪个公钥进行签名。这可能有助于提示用户其“安全”连接的中间人攻击，但这是一种最初信任技术。如果Bob没有“真实”公钥锁定记录，Mallory会在文档中重写pkp标头。使用此技术（HPKP）的网站列表令人沮丧地短。它包括谷歌和Dropbox，值得他们的信任。通常，https拦截网关将通过使用HPKP的少数受信任的大型网站页。如果您在不期望的情况下看到HPKP错误，请小心。
关于密码，https连接上的所有内容都由https保护，除了需要明文显示以便请求可以路由的域名。一般而言，不建议在查询字符串中放置密码，因为它们可能会在日志、书签等中挂起。但是，除非https被破解，否则查询字符串是不可见的。
1
但这意味着中间人设备（解密/扫描并重新加密流量的设备）需要访问其中一个受信任的CA，对吧？（以“伪造”服务器证书）。假设发生了这种情况。然后有人破解了它，信息变得公开，并且将在新闻界引起丑闻，CA证书将从所有浏览器中删除，对吧？我的意思是，理想情况下... - jazzcat
2
不是的。网关上的“SSL检查”需要动态创建和签署证书，但不需要根证书来完成此操作。它有一些中间证书，具有链式结构。您的浏览器是否信任链的根取决于是否会看到证书错误。在工作中，我们被要求安装Fortinet根证书，以便我们的浏览器不会给出证书错误。但如果链终止于已经受信任的证书，则是透明的。 - bbsimonbb
工作中的一位同事使用了有限的理解，试图解释为什么企业网络中的中间人攻击技术对于谷歌强制使用SSL是一个坏主意 - 他可能真的有一点正确吗？ - EmSixTeen
1
抱歉，我不理解这个问题！ - bbsimonbb
@bbsimonbb，“不，不是这样的。网关上的“SSL检查”需要动态创建和签署证书，但不需要根证书来完成此操作。它有一些中间证书，其中包含一个链。” 但是，网关确实需要有效的CA才能签署这些即时证书，对于恶意的MitM参与者来说，获得由有效根CA颁发的这些中间CA之一是不太可能的吧？ - jmrah
显示剩余2条评论
18
首先，我会简要描述一下认证过程，也许我的理解有误。所以，客户端开始连接，服务器响应了组合了公钥、一些元数据和可信任机构的数字签名。
然后服务器使用自己的私钥签署 X.509 证书链和数字签名来响应。
客户端决定是否信任服务器。
不正确。客户端和服务器进行相互会话密钥生成过程，会话密钥本身根本不会被传输。
无法用存储在服务器上的私钥解密此会话密钥。
不正确。
服务器不会这样做。
不正确。
TLS/SSL 会话开始，但需要执行更多步骤。
因为伪装成服务器并充当 SSL 终点。客户端必须省略任何授权步骤。遗憾的是，大多数 HTTPS 会话中唯一的授权步骤是主机名检查。
请参见上文。没有会话密钥可以解密。SSL 连接本身是安全的，不安全的是「你正在与谁交谈」。
即使有人截获服务器（例如 www.server.com）带有公钥的响应，然后通过某种手段让我认为他是 www.server.com，他仍然无法解密我的会话密钥。

谈到双向认证，它是否完全是关于服务器确定客户端身份的信心? 我的意思是，客户端已经可以确保与正确的服务器通信，但现在服务器想要找出客户端是谁，对吗?

没错。

关于替代双向认证的最后一个问题。如果我在所描述的情况中充当客户端，如果SSL会话建立后我在HTTP标头中发送登录/密码怎么办？我认为，这些信息不能被拦截，因为连接已经安全，服务器可以依靠它来识别我。我错了吗？

不错。

与双向认证相比，这种方法的缺点是仅取决于用户名/密码的安全性，而这些东西比私钥易泄漏得多。

谢谢您的解释。唯一我没明白的是，为什么您说客户端不会向服务器发送会话密钥？也许我使用了错误的术语，在这里，这个数据被称为“预主密钥”，但无论如何，它不是由客户端发送并使用服务器私钥进行解密吗？ - Vadim Chekry
1
@VadimChekry 预主密钥并不是会话密钥。它是用于在两端独立生成会话密钥的多个数据中的一个。这个过程在RFC 2246中有描述。 - user207421
谢谢 @EJP。我对此一窍不通，但从这个答案来看，我可以假设如果你使用IP地址进行连接，那么你就不容易受到中间人攻击的威胁了吗？根据我所找到的所有信息，中间人攻击似乎依赖于将域名映射到非法IP地址上。对于大多数在SO这个领域的人来说，这可能是一个愚蠢的问题，请原谅！ - Chris
1
@Chris，你的安全性要高得多，但是 IP 地址欺骗是可能的。没有什么能代替你自己检查证书中的对等方身份。 - user207421
1
+1 这是一个相当不错的答案，大部分都很好。然而，有些点缺乏解释，只用了一个词回答。如果您能扩展和/或详细说明这些点（例如，不要只回答“不”），那么您可以使其成为一个明确的答案。这将真正澄清一些事情。谢谢。 - voices
1
@tjt263 第一个“no”提供了实际发生的解释。接下来的两个“no”指的是产生第一个“no”的同样错误观念，并且有相同的解释。接下来的最后一个“no”指的是“我错了吗”，它指的是刚才引用自原帖的信息。因此，很难理解您认为实际上缺少什么。 - user207421
2
  1. 正确
  2. 不太准确。在这种攻击中，中间服务器会收到您的请求，并代表您将其发送到目标服务器，然后用结果回应您。实际上，这是一种中间人攻击，中间人服务器与您建立安全连接，而不是您打算通信的实际服务器。这就是为什么您必须始终检查证书是否有效和可信的原因。
  3. 可能正确
  4. 如果您确定安全连接是可信的，则可以安全地发送用户名/密码。
关于2 - 我假设客户端在连接建立过程中彻底检查服务器发送的元数据，并且客户端不信任所有证书。那么，如果：a）客户端没有按照我上面说的做，或者b）中间人已经获得了由受信任CA签名的证书，这种情况是否可能发生？ - Vadim Chekry
1
很少出现中间服务器发送有效证书的情况，去年如果我没记错的话，Comodo CA 就发生了这种情况。但通常情况下，如果是受信任的连接，则完全安全。 - Boynux
1

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

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接