安全与认证: SSL 与 SASL

SASL 不是一种协议，而是某种认证机制的抽象层。如果您使用 Digest-MD5或 GSS-API 作为您的 SASL 机制，您可以请求 SASL 完全加密您的数据通信。这就是我如何与 ActiveDirectory 服务器交谈的例子。你不需要 SSL。您的用例是什么？请详细说明！

SSL 与 SASL

的确，美国手语不是一种协议，而是一种抽象层。SSL 和 SASL 也确实提供了类似的特性。它们都提供身份验证、数据签名和加密。

SSL 是在传输层完成的，它对底层协议是 正常情况下透明的。例如，可以在 LDAP 或 HTTP 上使用 SSL。但是，在某些情况下，为了切换到安全模式，需要对现有协议进行修改。例如，POP3和 IMAP 被扩展为拥有一个命令 吓一跳来启动 SSL 的使用。从这个角度来看，这有点类似于 SASL 所做的。

另一方面，许多协议也被扩展以提供 SASL 功能。给你是协议列表。同样，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 有什么关系

根据这个 维基页面，在 SASL 中支持 GSSAPI 和 Kerberos。GSSAPI 是一个泛型接口。这个想法是让应用程序编写器使用一个单一的通用 API 来进行身份验证、加密等，而不管底层使用的是什么协议。GSSAPI 实现 Kerberos。因此，可以使用 GSSAPI 进行 Kerberos 身份验证。

JAAS 与 SASL 有什么关系

说实话，我不是 Java 专家。据我所知，JAAS 似乎只是一个可插入的身份验证框架。我相信这个想法类似于 GSSAPI。它是为了提供一个单一的编程接口，而不管使用什么身份验证方法。GSSAPI 主要关注身份验证和安全消息交换，而 JAAS 主要关注身份验证和授权。我没有发现任何证据表明 JAAS 也是 SASL 机制之一。我相信 Java 库中应该有一些帮助类可以帮助您实现定制的 SASL 机制。在实现自定义 SASL 机制时，只使用 JAAS 可能是有意义的。

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

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

SASL 本质上是一个间接层，允许在现有的应用程序协议(例如 LDAP、 SMTP、 Subversion 等)中插入认证系统和数据安全，尽管这些协议需要意识到这种扩展(例如 SMTP 认证)。它是否以及如何提供安全的身份验证和数据加密在很大程度上取决于在这个框架中使用什么 潜在的机制。下面是来自 svnserve文档的一个例子: “ 内置的 CRAM-MD5机制不支持加密，但是 DIGEST-MD5支持”。 如果希望在 SASL 中使用 Kerberos，则需要另一个间接级别: GSS-API(最常用于 Kerberos，但也允许使用其他机制)。(注意，与 GS2接班人不同，GSSAPI在 SASL 的上下文中似乎暗示 Kerberos。)

SSL/TLS 的总体目标是保护客户机和服务器之间的通信(完整性和机密性)。客户端应该始终检查 SSL/TLS 服务器的标识，它还提供了服务器检查客户端标识的机制。它能做什么也取决于它是如何配置的。SSL/TLS 最常用于 X. 509证书: 这是浏览器检查 HTTPS 服务器标识的方式。还可以将服务器配置为请求客户端使用证书来标识它们自己(客户端-证书身份验证)。 但是，如果希望使用 Kerberos，则可以使用 TLS Kerberos 密码套件。这是很少见的，但他们是 在 JSSE 中实现。

它的实现通常提供与普通 TCP 连接类似的 API: 在 Java 中，一旦配置好，就可以或多或少地使用 SSLSocket，就像使用普通的 Socket一样。这并不要求套接字上的协议具有特定的感知能力，尽管有些协议具有从普通连接(隐式与显式 SSL/TLS)切换到 SSL/TLS 的明确命令。它还可以提供身份验证。在 Java 中，JSSE是默认的 SSL/TLS 实现，它允许您访问 SSLSocket(或者 SSLEngine，如果您足够勇敢的话)。

您可能想阅读“ 何时使用 Java GSS-API 与 JSSE ”，它类似于“ SASL vs. SSL/TLS”(尽管它似乎有一段时间没有更新了，因为 JSSE 是的现在支持 Kerberos 密码套件，至少从 Oracle Java 6开始)。

我承认我对 SASL 的了解比对 SSL/TLS 的了解要少，但是通过 SASL 进行数据加密听起来似乎要花费更多的工作。它似乎没有某些 SSL/TLS 特性，比如 由 EDH 密码组件提供的完备的前向安全性。有一个 在 JGSS 教程中使用 SASL 和 GSSAPI (Kerberos 在这里)的示例: 您需要显式地包装/展开数据，这在使用 SSLSocket时是不必做的。

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

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

JAAS 之所以出现在其中，是因为它是用于处理身份验证和授权的通用 Java 框架。它与安全经理的概念紧密相连。它给出了 ABC0和 Principal的概念。这并不直接与协议或通信相关，而是与您在应用程序中建模身份验证和授权的方式相关。(它提供了一组标准的类来完成这项工作。)

(我一般建议通过 Java 参考文档来了解您所需要的单词: JGSS，SASL，... ，尽管它们不一定容易阅读。)