【问题标题】:Two-way SSL clarification双向 SSL 说明
【发布时间】:2012-05-30 08:00:25
【问题描述】:

我对双向 SSL 的工作原理有些困惑。客户端如何创建其证书以发送到服务器?是从服务端生成并分发给客户端的吗?

另外,双向 SSL 相对于单向 SSL 有什么优势?

【问题讨论】:

    标签: ssl two-way


    【解决方案1】:

    这两个证书在连接之前都应该存在。它们通常由证书颁发机构创建(不一定相同)。 (在其他情况下可以以不同的方式进行验证,但需要进行一些验证。)

    服务器证书应由客户端信任的 CA 创建(并遵循RFC 6125 中定义的命名约定)。

    客户端证书应由服务器信任的 CA 创建。

    由每一方选择其信任的内容。

    有一些在线 CA 工具可让您在浏览器中申请证书,并在 CA 颁发证书后将其安装在那里。它们不必位于请求客户端证书身份验证的服务器上。

    证书分发和信任管理是公钥基础设施 (PKI) 的角色,通过 CA 实施。 SSL/TLS 客户端和服务器,然后只是该 PKI 的用户。

    当客户端连接到请求客户端证书身份验证的服务器时,服务器会发送一个它愿意接受的 CA 列表作为客户端证书请求的一部分。然后客户端可以发送它的客户端证书,如果它愿意并且有合适的可用的话。

    客户端证书身份验证的主要优点是:

    • 私人信息(私钥)永远不会发送到服务器。客户端在身份验证期间根本不会泄露其秘密。
    • 不知道拥有该证书的用户的服务器仍然可以验证该用户,前提是它信任颁发该证书的 CA(并且该证书有效)。这与护照的使用方式非常相似:您可能从未见过向您出示护照的人,但由于您信任颁发机构,您可以将身份与此人联系起来。

    您可能对Advantages of client certificates for client authentication? (on Security.SE)感兴趣。

    【讨论】:

    • 您应该将 'created' 替换为 'signed by' 以保持相关性
    • @CharlieS "保持相关性"...您的意思是在使用“创建”时它不相关(与问题一致的措辞);-)? “已发行”确实可能是一个更好的词。
    • CA 是证书签署机构。证书是如何颁发或创建的并不重要,重要的是它由认证机构签署。我了解大多数 CA 创建/颁发自己签名的公钥证书,并且可以使用,但如果需要已经存在的公钥,则只需由 CA 签名即可。
    • @CharlieS 不,签名实际上只是认证过程中的最后一个技术步骤(包括颁发证书)。 CA 签署另一个 CA 颁发的证书是没有意义的,因为您必须在验证时将颁发者 DN 与主题 DN 匹配以构建链。证书仅在签名时“创建”,因为在此之前它是 CSR 或稍后是 TBSCertificate 结构(但仍然不是证书)。您在“创建”上挑剔,但 X.509 证书必须签名才能存在,而签名正是将数据结构变成证书的原因。
    • 您不允许签署由其他机构颁发的证书。 x509 已签名,但不一定由受信任的机构签名。
    【解决方案2】:

    您所说的“双向 SSL”通常称为带有客户端证书身份验证的 TLS/SSL。

    在到 example.com 的“正常”TLS 连接中,只有客户端验证它确实在与 example.com 的服务器进行通信。服务器不知道客户端是谁。如果服务器想要对客户端进行身份验证,通常的做法是使用密码,因此客户端需要向服务器发送用户名和密码,但这发生在 TLS 连接内部,作为内部协议(例如 HTTP)的一部分,它不是TLS 协议本身的一部分。缺点是每个站点都需要一个单独的密码,因为您将密码发送到服务器。因此,如果您在例如 PayPal 和 MyPonyForum 上使用相同的密码,那么每次您登录 MyPonyForum 时,您都会将此密码发送到 MyPonyForum 的服务器,以便该服务器的操作员可以拦截它并在 PayPal 上尝试并可以以您的名义付款.

    客户端证书身份验证提供了另一种在 TLS 连接中对客户端进行身份验证的方法。与密码登录相比,客户端证书身份验证被指定为 TLS 协议的一部分。它的工作方式类似于客户端验证服务器的方式:客户端生成公钥私钥对并将公钥提交给受信任的 CA 进行签名。 CA 返回一个可用于对客户端进行身份验证的客户端证书。客户端现在可以使用相同的证书对不同的服务器进行身份验证(即,您可以为 PayPal 和 MyPonyForum 使用相同的证书,而不会有被滥用的风险)。它的工作方式是,在服务器发送其证书后,它要求客户端也提供证书。然后发生了一些公钥魔术(如果您想知道详细信息请阅读RFC 5246),现在客户端知道它与正确的服务器通信,服务器知道它与正确的客户端通信并且两者都有一些共同的密钥材料要加密和验证连接。

    【讨论】:

    • 我创建了一个调用 server-rest-api 的 client-rest-api(单向 post call)。我的 client-rest-api 使用 server-rest-api 颁发的证书。但是,我的 client-rest-api 从未向 server-rest-api 颁发任何证书。它属于单向ssl还是双向ssl?事件虽然只是从客户端到服务器的单向调用,但我认为它是双向 ssl,因为这里 server-rest-api 验证客户端是否拥有服务器颁发的正确证书?
    • @HimalayMajumdar:如果您的服务器具有由 CA 签名的证书,或者您已将该证书硬编码到您的客户端(固定)中,那么是的,它仍然是带有客户端证书身份验证的正确 TLS(您称之为双向ssl)。耶 :-)。但是,如果您的客户端盲目地信任您的服务器证书,从技术上讲,它仍然是带有客户端证书身份验证的 TLS,但是由于客户端无法检查服务器证书,因此它不是双向的,并且在大多数情况下这是一个非常糟糕的主意。不要那样做:-(。
    • 通常当我编写 Java 客户端调用启用 https 的服务(自签名 https)时,客户端通常会失败,因为它默认不信任证书。对于我当前的 java 客户端,我只是将服务器颁发的证书导入到我的类路径中,以便服务器信任我的客户端,我猜通过导入证书,即使我的客户端也会自动信任服务器。感谢您的回复。
    【解决方案3】:

    客户端以两种方式向服务器请求数字证书,服务器向客户端请求相同的数字证书。它更安全,因为它是双向的,虽然它有点慢。一般我们不遵循它,因为服务器不关心客户端的身份,但客户端需要确保它所连接的服务器的完整性。

    【讨论】:

      猜你喜欢
      • 2012-12-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2022-01-09
      相关资源
      最近更新 更多