1.3 之前的 SSL/TLS 有一些“with-NULL”密码套件，它们不提供机密性，只提供身份验证和完整性；参见例如rfc5246 app C和rfc4492 sec 6或只是注册表。它们进行通常的握手，使用证书和可选的客户端身份验证服务器身份，并派生会话/工作密钥，用于 HMAC 后续数据（双向，不仅来自服务器）但不加密它. 这可以防止修改或重播，但允许频道/网络上的任何人阅读它。

这些密码套件非常很少使用，并始终（据我所知）默认情况下禁用。（在OpenSSL的，他们不仅不包括在DEFAULT，但即使是在另有一套完整的ALL-让他们必须指定（一）明确套件（S），设定eNULL又名NULL或集COMPLEMENTOFALL可怕，这炉排最后到任何数学家！）我非常怀疑你会得到任何浏览器来使用它们，可能不是大多数应用程序甚至许多打包的服务器。但是，如果你在一个HTTPS连接的两端控制应用程序-或者代理的的应用程序-这确实满足您的需求明显。

TLS 1.3 更改了密码套件的使用方式，不再具有此功能。随着时间的推移，1.3 将变得更加普遍，并且在可预见的将来很可能会放弃 1.2 和 1.1。（1.0 已经在很多地方被丢弃了，虽然不是全部。SSL3 被 POODLE 严重破坏，并且基本上到处都被丢弃了。）

从 1.3 开始，迟来的发现骗局：TLS 能否在不保密的情况下提供完整性/身份验证

是的，签名交易所 (SXG)

这样的机制确实存在，尽管它非常新并且有些争议。

• Chromium 浏览器（Chrome 73、Edge 79、Opera 64）支持 SXG。
• Mozilla认为 SXG有害；Firefox 不支持它们。
• Safari 不支持它们。苹果显然对该提议表示“怀疑”，尽管我找不到任何权威性的东西。

SXG 是有争议的，因为一些人认为该提案是谷歌试图将标准强加给社区以支持谷歌也有争议的AMP项目。简而言之，SXG 旨在允许浏览器在 URL 栏中显示发布者的 URL，即使内容实际上是由 Google 托管的。

社论：这是一个相当不幸的情况，因为该提案确实具有技术优势。虽然我确实觉得 AMP 完全令人反感，但在 LAN 级别启用 HTTP 资源安全缓存的规范非常有趣。SXG 规范本身也足够通用，可以用于其他用例。

SXG 是一种二进制格式，它封装了 HTTP 请求和响应（标头和有效负载），并使用颁发给源域的证书对其进行签名。SXG 文件未加密，可以以任何方式分发，包括通过普通 HTTP 甚至在闪存驱动器上。

用于签署 SXG 的证书大多类似于用于 HTTPS 的标准 X.509 证书，但CanSignHttpExchanges如果要被浏览器信任，该证书必须由具有扩展名的受信任 CA 颁发。（这些尚未广泛使用。）

可能有，但没有

这样的协议是合理的。但是，它与 HTTPS 相比并没有实质性的优势，并且没有强烈的业务需求来促进采用这种协议，因此它还没有被主流浏览器和服务器的制造商实施或采用。

在我看来，这种协议的唯一用例是在不寻常的利基条件下——因此应该在场景中开发和使用自定义利基协议（可能通过创建开源服务器和浏览器的修改版本）似乎是合适的网络中的每个人都希望看到每个用户在做什么，但仍然强制执行 HTTP 传输的真实性；因为这是主流消费者用例的反特性。

我希望主流浏览器故意拒绝包括对此类协议的支持，因为将用户连接降级到不太安全的选项的能力被认为是一种安全风险，并且认为安全性（包括隐私）不作为默认设置是更可取的选项，但作为强制性 - 用户不应该有一个简单的选项来降低安全性，因为它会被滥用。在 SSL/TLS/HTTPS 标准的开发过程中提出并讨论了类似的某些方面，并故意将其排除在最终标准之外。

除了 Albert Goma 提到的 pgp 签名网页的做法之外，还有一个来自 httpbis 工作组的 HTTP 草案用于 HTTP 签名：

签署 HTTP 消息

?

注意：该草案在几天前（10 月 12^日）到期，但作为一个工作组的结果，源自 7 年的 cavage-http-signatures 之一，我希望它很快就会更新。