【问题标题】:Authentication: Kerberos or SSL?身份验证:Kerberos 还是 SSL?
【发布时间】:2011-06-20 03:58:20
【问题描述】:

我正处于 Java EE 应用程序的“预设计”阶段(如果有这样的事情!),该应用程序将在客户端使用 Swing 框并为 Web 和服务器层实现组件。

我立即看到了一些技术选择,并且一直在阅读 Kerberos 和 SSL 工作方式之间的差异。我无法找到任何答案的一个领域是如何在 Kerberos 或 SSL 之间进行选择。换句话说,您如何判断何时适合使用任一协议?

让我们假设 Swing 客户端不受特定传输(UDP、TCP 或其他)的约束,并且可以使用其中一个/任何一个。如何在这两者中选择哪一个更适合他们的应用?

谢谢!

【问题讨论】:

  • 不询问它们之间的区别(即它们如何工作);对决定何时使用这两种方法的最佳实践规定的内容感兴趣。
  • “最佳实践”是主观的。了解差异并自行决定。

标签: java authentication ssl kerberos


【解决方案1】:

突然(几个月后)出现了一个狂野的系统管理员......

我将不得不对此表示异议。 没有 CA 就可以建立 PKI 的想法非常荒谬。您必须通过简化创建过程来维护 PKI 的完整性和性能。您必须在某处创建和存储证书,那将在哪里?繁荣,你有一个CA。任何体面的 PKI 也需要维护 CRL,管理员应该只是手写吗?您也可以忘记拥有 509 的不同类型,因为手动维护它的开销会让你大开眼界,然后把它变成灰色泥浆。 p>

我想您可以使用 openssl 的 CLI 手动创建票证,然后将它们通过 ftp 传输到远程客户端,但这对于相当大的部署来说是一个巨大的麻烦。本质上,如果您的部署是如此之小以至于手动生成证书(重复输入信息和所有)然后不担心 CRL 是一个合理的计划,那么您根本不需要高级身份验证系统。类似于 TLS+LDAP(一个服务器证书用于机密性而非身份验证)更合适。

好的,既然我已经消除了一些误解,让我们真正回答您的问题:您何时希望使用 SSL 而不是 Kerberos 进行身份验证?基于 x509 的身份验证是一个令人难以置信的模糊野兽,主要是因为大多数人(如上面的 Michael-O)没有意识到 SSL 是专门工作的,因为它正在对用户进行身份验证。我知道有一些 FTP 程序可以通过这种方式进行身份验证,中间件使用它……有时(这听起来与 Java 谈话中的用例很接近),并且 vpn 客户端/网关通常使用 SSL 证书进行身份验证。

使用 SSL 意味着我在上面提到的 PKI,如果您的用例涉及机密性,这将非常有用。 DoD 是企业广泛使用 PKI 来实现身份验证之外的功能的一个很好的例子。在这种情况下,假设所有相关的客户端程序都支持 x509 身份验证是很有意义的。它仍然是一个奇特的设置,您仍然需要弄清楚最终用户如何将他们的 SSL 凭据“呈现”给系统(客户端配置、智能卡等),但它会很好地结合在一起。除了奇怪的配合之外,kerberos 还通过临时票证进行身份验证,而 SSL 证书通常会持续很长时间(这就是需要 CRL 的原因),这意味着如果在一个证书上考虑到永不更改的密钥,攻击者将有几个月的时间在他们必须找到新证书之前免费乘车,而在 kerberos 中,他们只有一天的时间,而且只有在门票没有被销毁的情况下。

所有其他情况应尽可能使用 Kerberos 身份验证。它提供了正确的安全层,实际上被设计为一个大型网络身份验证系统,这就是为什么你有一些难以用 SSL 复制的东西(比如作为服务而不是普通用户进行身份验证)并且只是为他们的预期工作目的。您的用例总是需要考虑现有的基础架构,这些基础架构可能会面向 kerberos,有时面向 LDAPS,但几乎从不面向 x509 身份验证。换句话说:无论您正在编写什么,都更有可能已经在 kerberos 基础架构中运行,因此您不妨以某种方式插入它。与 509 作为身份验证相比,管理员熟悉 Kerberos 作为身份验证也会使您受益更多。这样做的缺点是门票之外的机密性是个笑话。 NFSv4 有一些弱 DES(不,我什至不是指 3DES)加密,它(不知何故)与 kerberos 票证相关,但它进行身份验证,基本上就是这样。

我希望看到 x509 的一些灵活性与 kerberos 风格的基础架构(服务识别和拥有即将到期的票证的“一次性”方面)结合到更广泛实施的解决方案中比现在的 x509,但在这个阶段,它主要是做白日梦。

总结:

x509 很好,如果基础设施要求不会成为问题,并且无论如何您都会将 PKI 用于其他东西,但可能会不必要地重复工作,或者如果部署可能无论如何都会有一个 kerberos 基础设施。

p>

Kerberos 是一种类似但更好的身份验证方案,它被更广泛地使用/理解,但对 PKI 完全没有帮助,你获得了身份验证,仅此而已。

【讨论】:

  • 关于凭证的生命周期,Kerberos 票证更类似于代理证书 (RFC 3820),它们是短暂的(并且可以是特定于目的的,具体取决于属性)。 X.509/PKI 和 Kerberos 之间的一个很大区别是 Kerberos 要求客户端能够联系 KDC,而 PKI 不需要一直在线(只要 CRL 经常重新加载)。 Kerberos 还使用对称加密,具有经过验证的数学特性(但也需要 KDC 知道用户的秘密),而 X.509 使用非对称加密,仍然基于 AFAIK 的猜想。
【解决方案2】:

比较 Kerberos 和 SSL/TLS 没有意义。

  • Kerberos 是一种身份验证协议。
  • TLS 是一种用于保护两方之间通信的协议,它依赖于身份验证和加密机制。它们的工作方式取决于所选的密码套件。尽管 TLS(例如 HTTPS)的大多数用法都使用 X.509 证书,在这种情况下,您可能会使用 PKI 对远程方进行身份验证,但也可以使用 Kerberos cipher suites。据我所知,很少有 TLS 堆栈支持这些 Kerberos 密码套件 (Java does)。

它不必是一个或另一个。例如,即使您使用的是 SPNEGO (Kerberos) HTTP 身份验证,使用 TLS 保护传输通常是有意义的(通常在服务器端使用 X.509 证书,通过 PKI 验证)。如果不是,则在 HTTP 标头中交换的 SPNEGO 令牌可保证身份验证,但其余 HTTP 消息可能已被攻击者修改。

【讨论】:

    【解决方案3】:
    【解决方案4】:

    考虑到任何涉及 Kerberos 的解决方案都将比 SSL 更复杂,因为它需要额外的第三个组件,即身份验证服务器,它必须被管理和管理(例如 MS Active Directory),而 SSL 只是一个客户端/服务器协议。

    【讨论】:

    • 谢谢 - 您知道这两种协议之间是否存在显着的性能差异吗?
    • 实际上 SSL 也需要第三方 - 证书颁发机构。您实际上必须为此付费……除非您在自己的域中设置自己的 CA,或者您手动分发证书(对于超过 10 个客户端的任何情况都很痛苦)。
    • 但正如您所提到的,SSL 并不需要 CA - 您可以使用自签名证书或分发您自己的证书。使用 Kerberos,您必须拥有一个 AS。此外,Kerberos 协议要求每个身份验证请求与 AS 进行通信,而在 SSL 中从不直接联系 CA。
    • 客户端缓存票据,因此减少了他们需要联系 Kerberos 域控制器的数量。如果票证持续 2 小时,则客户端将不必重新获取 2 小时,但会继续使用其缓存的票证。
    【解决方案5】:

    你在混合东西。 Kerberos 是一种身份验证协议,SSL ist 加密。如果您在公司环境中,Kerberos 是您的最佳选择。

    编辑:Kerberos 还可以透明地加密您的数据流量。无需 SSL 证书。

    【讨论】:

    • 当然会。我们的 Tomcat AD 流量是完全加密的。您必须使用加密设置您的上下文并包装/解包您的消息。如果你使用SASL,你可以设置quality of protection,一切都会透明地发生。
    • Kerberos 加密它自己的流量,关于票证的交换(当然,身份验证是加密的),但这并没有说明应用程序流量(例如 HTTP)。这正是比较 Kerberos 和 SSL 没有意义的原因。说“Kerberos 是一种身份验证协议,SSL ist 加密。”也不太合理:两者都可以加密,Kerberos 是一种身份验证协议,而 SSL/TLS 是一种保护传输的协议两方之间的数据。
    • 我不是在谈论身份验证,而是在谈论消息加密。我也没有专门谈论 HTTP。 Keberos 可以加密流量。 HTTP 只是有缺陷,并不是为此而设计的。支持 SASL 的协议将像 LDAP、IMAP、SMTP 等一样工作。仅仅因为你不知道它,并不意味着它不起作用。
    • 这就是我的意思,您需要在这里添加几个额外的层:SASL 和 GSS-API。这不是 Kerberos 与 SSL/TLS,而是 Kerberos + SSL/TLS 或 Kerberos + SASL/GSS-API(或 SASL 与 TLS)。
    • 其实不是,SASL只是一个抽象层。你可以自己做简单的包装。 Kerberos 是免费提供的。作为侧节点,没有 Kerberos + GSS-API,只有 GSS-API。 Kerberos 没有独特的 API。
    猜你喜欢
    • 1970-01-01
    • 2015-06-22
    • 2010-09-11
    • 1970-01-01
    • 1970-01-01
    • 2017-06-28
    • 2017-07-13
    • 1970-01-01
    相关资源
    最近更新 更多