SSL和男人

我已经阅读了大量与这个问题有关的文档，但我仍然无法把所有的东西放在一起，所以我想问几个问题。

首先，我将简要地描述认证过程，因为我理解它，因为我可能会在这方面弄错：客户端启动连接，服务器通过公钥，元数据和数字签名的组合来响应可信的权威。 然后，如果客户信任服务器，则客户端会做出决定，使用公钥对一些随机会话密钥进行加密并将其发回。 该会话密钥只能使用存储在服务器上的私钥解密。 服务器执行此操作，然后HTTPS会话开始。

所以，如果我上面说得对，问题是在这种情况下中间人攻击会如何发生？ 我的意思是，即使有人用公钥截获服务器（例如www.server.com）响应，并且有一些手段让我认为他是www.server.com，但他仍然无法解密我的会话密钥没有私钥。

谈到相互身份验证，是否关于服务器对客户身份的信心？ 我的意思是，客户端可以确定她正在与正确的服务器进行通信，但现在服务器想要知道客户是谁，对吗？

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

---

如果SSL的先决条件之一被破坏，那么对SSL的中间人攻击实际上是可能的，下面是一些例子;

服务器密钥已被窃取 - 意味着攻击者似乎是服务器，并且客户端无法知道。

客户端信任一个不可信的CA（或者有一个被盗的根密钥） - 持有可信的CA密钥的用户可以生成假装成服务器的证书并且客户端会信任它。 由于今天浏览器中已经存在CA的数量，这可能是一个真正的问题。 这意味着服务器证书似乎会更改为另一个有效的证书，这是大多数客户对您隐藏的内容。

客户端并不打算根据可信CA的列表正确验证证书 - 任何人都可以创建一个CA. 没有验证，“本车和证书”看起来与Verisign一样有效。

客户端受到攻击，并且一个伪造的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将对用户不可见。 这些产品主要销售给公司以“保护”（警察）公司网络，并且应该在用户的知识和同意的情况下使用。 但从技术上讲，没有任何东西阻止他们使用ISP或任何其他网络运营商。 （假设NSA至少有一个受信任的根CA签名密钥是安全的）

如果您正在提供一个页面，则可以包含一个HTTP标头，用于指示页面应该签名的公钥。 这可能有助于提醒用户MITM他们的“安全”连接，但它是首先使用的信任技术。 如果鲍勃还没有“真实”公共密钥引脚的记录，Mallory就会重写文档中的pkp头。 使用这种技术的网站列表令人沮丧地很短。 它包括谷歌和Dropbox，以他们的信誉。

关于密码，https连接上的所有内容都通过https进行保护，除了域名之外，该域名必须清晰，以便可以路由请求。 一般来说，建议不要将密码放在查询字符串中，他们可以在日志，书签等中逗留。但除非https被泄露，否则查询字符串不可见。

链接地址: http://www.djcxy.com/p/489.html

上一篇: SSL and man

下一篇: What is the best Distributed Brute Force countermeasure?