【问题标题】:An SSL/TLS MisunderstandingSSL/TLS 误解
【发布时间】:2011-07-31 02:25:50
【问题描述】:

我对 SSL/TLS 有一个根本性的误解,希望能得到澄清。

按照我的理解,当我为我的网站获得证书时,它包含我的所有信息,并由我的证书颁发机构(VeriSign 或其他任何人)签署。当有人从我的站点请求使用 SSL/TLS 的页面时,证书会发送给用户,并使用证书颁发机构的众所周知的公钥对其进行验证。然后用户可以查看证书并查看我的信息。他们确信我就是我所说的那个人,并且自从验证正常工作以来,消息没有被篡改。

是什么阻止我在浏览器和真实站点中间放置代理并仅发送真实站点的证书(我不知道这是否正确,我想我现在有我的浏览器将其拉下以验证它)到客户端并让客户端认为它真的是站点whateverdomain.com,而实际上是我在中间?

谢谢。

【问题讨论】:

    标签: security ssl-certificate


    【解决方案1】:

    就 SSL/TLS 的工作方式和证书交换而言,其他答案基本上是正确的。但是,让我们具体看看它与您最初的问题有关。

    为了使其正常工作,代理服务器必须能够:

    1. 提供公用名属性与您要连接的站点域匹配的证书。换句话说,如果您想访问https://www.example.com,代理服务器必须能够提供以 www.example.com 或 *.example.com 作为通用名称的证书。
    2. 代理提供的证书必须由您的浏览器信任的 CA 签名。尽管您的浏览器信任数十个 CA,但理论上它们都不会颁发通用名称为 www.example.com 的证书,除非您能证明您拥有该域。

    因此,在实践中,让代理服务器在企业环境之外模拟 SSL/TLS 会话非常困难。在企业环境内部,这是一个不同的故事。公司通常会在您桌面上的浏览器中注册自己的内部 CA 证书。当您使用 TLS 登录您的银行时,企业网络代理会即时生成具有正确域名的证书以呈现给您的浏览器是很常见的。您的浏览器看到 https://www.mybank.com 和来自受信任 CA 的匹配证书并且很高兴。同时,公司 Web 代理与您的银行保持单独的 TLS 会话。在这两者之间,代理能够记录您所有的 HTTPS 帖子和接听电话,包括任何形式的内容,例如 ID 和密码。

    在企业环境之外,大多数攻击者不需要那么麻烦,因为他们可以坐在 Wi-Fi 热点中运行SSLStrip。大多数人不会注意到会话实际上不是 SSL,尤其是当攻击者将网站图标更改为锁定符号时。

    【讨论】:

      【解决方案2】:

      首先,所有证书都是公开的且未加密。但是,它是使用 CA 的私钥签名的。

      当客户端连接到服务器时,它们根据某些秘密信息,即服务器的私钥进行密钥交换(服务器只向客户端发送没有私钥的公共证书)。这是第 1 步。

      第 2 步是让客户端验证给定的证书并确保它(客户端)已连接到预期的站点,即该站点已提供合法证书。这种验证是一个复杂的过程(检查许多参数并进行许多步骤)。验证涉及检查服务器证书的签名。

      现在关于 MITM 攻击。一般来说,第 2 步可以防止 MITM 攻击。如果验证薄弱,攻击者可以尝试伪造证书并歪曲网站。另一个可能的弱点是 CA 颁发的证书没有经过适当的验证或由于安全漏洞(最近发生在某些 Comodo 的子 CA 中)。

      我们在corresponding article 中对 SSL 的工作原理有一个很好的(我希望 :) 描述,尽管它没有解释 MITM 攻击。

      【讨论】:

        【解决方案3】:

        首先,关于术语:当有人用他们的私钥加密(散列)文档时,我们不再将其称为加密 - 它称为签名。因此,证书颁发机构 (CA) 使用其私钥签署文档(散列),因此每个人都可以使用 CA's public key 验证文档的有效性。

        其次,SSL 现在称为TLS

        现在,回答您的问题:一旦您拥有服务器的公钥,您就可以发送只有服务器可以读取的消息,因为没有其他人拥有他们的私钥。因此,如果您加密了一个 AES 密钥,并且服务器会向您发送回消息“Hello world!”。使用该密钥加密,您可以确定消息确实来自服务器,因为没有其他人可以读取密钥。

        实际的handshake in TLS 比这更复杂,但这是基本思想。

        【讨论】:

        • 或者,更准确地说,TLS 已经淘汰了 SSL。
        【解决方案4】:

        证书仅包含 SSL 连接的公钥。客户端将使用证书中的公钥与服务器通信,因此代理需要相关的 private 密钥,该密钥是保密的。

        请注意,公钥/私钥对通常用于交换用于大量通信的对称加密密钥。

        【讨论】:

        • Bunger - 你是说它包含我的证书的公钥还是签名机构的公钥?如果是为了我的证书并且我持有私钥,那么用户怎么知道这真的来自 CA?
        • 它包含您证书的公钥。浏览器有根 CA 的“硬编码”公钥,证书由 CA 用他们的私钥签名。因此,除非您知道 CA 的私钥或破坏浏览器,否则您无法伪造证书。另见askubuntu.com/questions/30039/…
        • -1 这是误导。服务器不需要私钥来向客户端发送消息 - 他们需要私钥来读取客户端发送的消息。
        • @BlueRaja 你在谈论 SSL 吗?在 SSL/TLS 中,证书的私钥仅用于密钥交换。此外,存在根本不使用证书的密码套件(SRP 和匿名 DH 方法)
        【解决方案5】:

        我认为不使用证书然后添加证书更容易解释。

        鉴于证书担保公钥,如果我们删除证书,您就只有公钥。如果您的网站有一个公钥,并且您将其呈现给某个客户,那么只有您拥有相应的私钥,它才会有意义和目的。否则你的虚张声势会被客户马上叫——客户会选择一个随机数,比如 1729,用你的公钥加密它,然后问你选择的数字是什么。如果没有相应的私钥,您将无法回答此问题,客户将拒绝您。

        来自公认机构的证书所做的只是保证 skaz.com 网站的公钥是 xyz。如果我们没有证书,那么冒名顶替者可以创建(公钥、私钥)密钥对(abc、mno)并告诉全世界 skaz.com 的公钥是 abc。

        回答你的问题是什么阻止我在浏览器和真实站点中间放置一个代理,只发送真实站点的证书,这是经典的man-in-the - 中间攻击,如果随机数 --- 在这种情况下为 1729 --- 客户端加密被用作所有未来流量的加密密钥(也称为会话密钥),那么代理不能做任何事情。例如如果客户端发送使用会话密钥加密的密码,则冒名顶替者代理无法读取它。

        总而言之,您可以将任何实体的证书发送给任何人,但在不知道相应私钥的情况下,它实际上是无用的。

        【讨论】:

          猜你喜欢
          • 2018-12-31
          • 1970-01-01
          • 2019-03-18
          • 2012-09-22
          • 1970-01-01
          • 1970-01-01
          • 2014-05-02
          • 2019-03-26
          • 1970-01-01
          相关资源
          最近更新 更多