通常，当人们说他们不想要 TLS 而是所谓的“应用程序级”时，那么原始的、赤裸裸的事实是他们不知道他们在喋喋不休。

不过，请注意“通常”：在某些情况下 TLS 是不够的，并且需要其他一些东西并且要在可以称为“应用程序”的某个级别上应用。主要情况是当某些客户端必须发送具有某种强制责任的请求时；简而言之，当请求必须签署时，如果出现问题，请求可以作为审判期间的证据。TLS 不做签名；它在内部使用签名，但仅用于身份验证。客户端可以确定它与正确的服务器通信（反之亦然，如果使用客户端证书），但它没有在法官眼中令人信服的证据。

当然，需要“ALS”但不能给出适当规格的人不太可能意识到这些微妙之处。他们可能只是在应用一些他们不理解的教条。为了解决这个问题，按照他们的要求做：实现一些应用程序级安全性，其中包括将“消息”交换为“字节序列”，这恰好与RFC 5246中描述的相同。

这一点以前曾以易于理解的图形格式出色地提出：

（我希望斯科特亚当斯的律师能原谅我引用了这个非凡的智慧。）

TLS 对于点对点安全很有用，在这种安全性中没有中间方，并且仅限于一跳。

应用程序级安全性 (ALS) 可能意味着消息级安全性，例如WS-Security规范，它允许：

• 端到端安全性（相对于 TLS 中的点对点）
• 提高灵活性（可以对部分消息而不是整个消息进行签名/加密）
• 支持多种传输（TCP、UDP、我什至见过 SMTP 等等）
• 支持广泛的凭据和声明。

缺点是

• 没有媒体流。消息安全是无序的，并且比特流是不可能的，除非支持协议保证按顺序接收和重新传输。
• 比 TCP 慢。多跳意味着更高的延迟
• 没有可用的硬件加速器（或很难找到）
• 消息安全性很难与其他供应商进行互操作。XML 安全支持因供应商而异。

Microsoft 的 WCF 站点上有更多关于此主题的信息。

理想情况下，您可能需要考虑传输安全和消息凭据：

使用传输和消息凭据保护服务使用 Windows Communication Foundation (WCF) 中的传输和消息安全模式中最好的。总而言之，传输层安全提供完整性和机密性，而消息层安全提供各种凭证，而这些凭证是严格的传输安全机制无法实现的