【问题标题】:Security & Authentication: SSL vs SASL安全与认证:SSL 与 SASL
【发布时间】:2012-07-06 00:47:38
【问题描述】:

我的理解是 SSL 将加密算法(如 AES、DES 等)与密钥交换方法(如 Diffie-Hellman)相结合,在不安全的网络(如互联网)。

我的理解是,SASL 是一个 MD5/Kerberos 协议,几乎做同样的事情。

所以我的问题是:选择这两种方法的优缺点是什么,哪些情况更可取?基本上,我正在寻找一些在选择 SSL 或改用 SASL 时要遵循的准则。提前致谢!

【问题讨论】:

  • 身份验证层和安全传输层是完全不同的东西,尽管两者都可以用于执行身份验证。但是,如果您问这个问题,我想知道您是否正在寻找要解决的问题,或者您是否正在尝试解决问题。
  • 我试图弄清楚我的 Java 客户端和服务器在相互通信时是否需要使用 SSL 或 SASL 来保护用户数据/请求/响应,所以应该是后者(尝试解决问题)。

标签: encryption ssl md5 kerberos sasl


【解决方案1】:

SASL 不是协议,而是某种身份验证机制的抽象层。如果您使用 Digest-MD5 或 GS​​S-API 作为您的 SASL 机制,您可以请求 SASL 来完全加密您的数据流量。例如,这就是我与您的 Active Directory 服务器对话的方式。您将不需要 SSL。你的用例是什么?请详细说明!

【讨论】:

    【解决方案2】:

    SSL 与 SASL

    确实,SASL 不是协议而是抽象层。 SSL 和 SASL 也确实提供了类似的功能。它们都提供身份验证、数据签名和加密。

    SSL 在传输层完成,它通常对底层协议是透明的。例如,您可以在 LDAP 或 HTTP 上使用 SSL。但是,在某些情况下,需要修改现有协议才能切换到安全模式。例如,POP3 和 IMAP 扩展为具有命令STARTTLS 来启动 SSL 的使用。从这个角度来看,这有点类似于 SASL 的做法。

    另一方面,许多协议也被扩展以提供 SASL 功能。 Here 是协议列表。同样,POP3 和 IMAP 是其中的两个,它们使用不同的命令来启动身份验证。

    那么,我们什么时候应该使用 SSL,什么时候应该使用 SASL?

    SSL 和 SASL 之间的一个明显区别是 SASL 允许您选择不同的机制来验证客户端,而 SSL 是一种绑定以基于证书进行身份验证。在SASL中,可以选择使用GSSAPI、Kerberos、NTLM等。

    由于这种差异,在某些情况下,使用 SASL 而不是 SSL 更直观。例如,您的客户端应用程序正在使用 Kerberos 对最终用户进行身份验证。您的服务器需要对客户端进行身份验证。由于您的客户端应用程序已经具有 Kerberos 凭据(在 Kerberos 术语中,票证),因此使用 Kerberos 凭据向服务器进行身份验证是有意义的。当然,您始终可以设置 SSL 来做同样的事情。但是,这意味着在现有 Kerberos 基础设施之上,您需要设置证书颁发机构基础设施,并以某种方式将客户端证书与 Kerberos 凭据相关联。这是可行的,但工作量很大。

    此外,有时,您需要使用一些仅在 SASL 机制中可用但在 SSL 中不可用的功能。例如,Kerberos 允许您将票据从客户端转发到服务器,以便服务器可以使用票据代表客户端查询一些资源。一个常见的例子是你有一个应用服务器和一个数据库。客户端应用程序向应用程序服务器进行身份验证,并且应用程序服务器需要使用客户端的凭据代表客户端查询数据库。 SSL 无法为您提供此功能,但 Kerberos 支持此功能。因此,在这种情况下,您必须选择使用 SASL。

    在某些情况下,您确实想使用 SSL 而不是 SASL。例如,扩展协议不是一种选择,或者您想加密使用底层协议交换的每个数据包。

    GSSAPI 与 Kerberos 和 SASL 有何关系

    根据wiki page,SASL 中支持 GSSAPI 和 Kerberos 机制。 GSSAPI 是一个通用的编程接口。这个想法是让应用程序编写者使用一个通用 API 来进行身份验证、加密等,而不管下面使用什么协议。 GSSAPI 实现 Kerberos。因此,您可以使用 GSSAPI 进行 Kerberos 身份验证。

    JAAS 与 SASL 有何关系

    说实话,我不是 Java 专家。根据我的阅读,听起来 JAAS 只是一个可插入的身份验证框架。我相信这个想法类似于 GSSAPI。无论使用什么身份验证方法,它都提供一个单一的编程接口。 GSSAPI 专注于身份验证和安全消息交换,而 JAAS 专注于身份验证和授权。我没有找到任何证据表明 JAAS 也是 SASL 机制之一。我相信 Java 库中应该有一些帮助类可以帮助您实现自定义 SASL 机制。在实现自定义 SASL 机制时,只使用 JAAS 可能是有意义的。

    【讨论】:

      【解决方案3】:

      比较 SSL/TLS 和 SASL 是相当困难的,因为 SSL/TLS 是一种通信协议,而 SASL 是一个框架,与其他协议集成。 (事实上​​,在某些情况下,您可以同时使用两者。)

      此外,您还提到了 Kerberos,它确实是一种身份验证协议(可以与 SSL/TLS 或 SASL 一起使用,或者两者都独立使用)。您的问题似乎表明是否使用 Kerberos 是您应该首先选择的主要子问题之一。

      SASL 本质上是一个间接层,允许在现有应用程序协议(例如 LDAP、SMTP、Subversion 等)中实现可插入的身份验证系统和数据安全性,尽管这些协议需要了解此扩展(例如 SMTP auth )。它是否以及如何提供安全身份验证和数据加密很大程度上取决于在此框架内使用的underlying mechanism。以下是来自svnserve documentation 的示例:“内置的 CRAM-MD5 机制不支持加密,但 DIGEST-MD5 支持”。 如果您想将 Kerberos 与 SASL 一起使用,您将需要另一个级别的间接:GSS-API(它最常与 Kerberos 一起使用,但也可以允许其他机制)。 (请注意,SASL 上下文中的 GSSAPI 似乎暗示了 Kerberos,与 GS2 successor 不同。)

      SSL/TLS 的总体目标是保护客户端和服务器之间的通信(完整性和机密性)。客户端应始终检查 SSL/TLS 服务器的身份,它也为服务器提供了检查客户端身份的机制。它可以做什么也取决于它的配置方式。 SSL/TLS 最常与 X.509 证书一起使用:这就是浏览器检查 HTTPS 服务器身份的方式。服务器还可以配置为请求客户端使用证书来标识自己(客户端证书身份验证)。 但是,如果要使用 Kerberos,可以使用 TLS Kerberos cipher suites。这不太常见,但它们是implemented in the JSSE

      它的实现通常提供类似于普通 TCP 连接的 API:在 Java 中,一旦配置好,您就可以或多或少地使用 SSLSocket,就像使用普通的 Socket。尽管某些协议具有从普通连接切换到 SSL/TLS 的显式命令 (Implicit v.s. Explicit SSL/TLS),但这不需要套接字顶部的协议的特定意识。它还可以提供身份验证。在 Java 中,JSSE 是默认的 SSL/TLS 实现,它使您可以访问SSLSocket(如果您足够勇敢,也可以访问SSLEngine)。

      您可能想阅读“When to use Java GSS-API vs. JSSE”,它类似于“SASL 与 SSL/TLS”(尽管它似乎有一段时间没有更新,因为 JSSE 确实 em> 现在支持 Kerberos 密码套件,至少从 Oracle Java 6 开始)。

      我承认我对 SASL 的了解比对 SSL/TLS 的了解要少,但是通过 SASL 进行数据加密听起来会比较麻烦。它似乎没有某些 SSL/TLS 功能,例如 Perfect Forward Secrecy offered by EDH cipher suites。有一个example that uses SASL with GSSAPI (Kerberos here) in the JGSS tutorial:您需要显式地包装/解包数据,而使用SSLSockets 时您不必这样做。

      我认为您主要关心的应该是首先决定要使用哪种身份验证机制:Kerberos、X.509 证书或其他。这将对您的整体架构产生更大的影响,并且两者都可以与 SASL 和 SSL/TLS 一起使用(如果您在 SSL/TLS 连接之上使用带有EXTERNAL 机制的 SASL,则更是如此)。

      • Kerberos 非常集中。除了能够联系您的应用程序服务器之外,客户端还需要能够联系 KDC 以进行身份​​验证。还需要将客户端配置为使用该 KDC。从用户的角度来看,他们可以使用密码。
      • X.509 更加分散。但是,您可能需要为您的用户证书部署证书颁发机构(或使用商业证书颁发机构)。用户需要获得证书和私钥,有些人可能会觉得这太复杂了。

      JAAS 之所以出现,是因为它是处理身份验证和授权的通用 Java 框架。它与安全管理器的概念密切相关。它为您提供了Subject and Principal 的概念。这与协议或通信没有直接关系,而是与您在应用程序中对身份验证和授权建模的方式有关。 (它为您提供了一组标准的类。)

      (我通常建议通过 Java reference documents 提及您所追求的词:JGSS、SASL、...,尽管它们不一定容易阅读。)

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2019-12-20
        • 2015-05-12
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2012-10-16
        • 2020-10-19
        相关资源
        最近更新 更多