几个小时前我就有了这个想法，但它当然已经存在，甚至还有一个 RFC ……
我们为什么不通过 DNS 发布 SSL/TLS 证书的指纹？我们需要 DNSSEC 来确保答案是合法的，并且我们需要确保名称服务器处于安全环境中，但除此之外，我没有发现 SSL/TLS 不存在的问题。
此更改会将保护我们所有加密流量的权限从证书颁发机构 (CA) 转移到 DNS 名称服务器。这可能是一个问题，因为在这种情况下，所有 DNS 提供商（拥有 DNSSEC）都应该像现在的 CA 一样成为非常高安全性的环境。但是不应该所有的名称服务器都已经是这样了吗？大多数网站使用纯 http 来处理敏感流量，大多数人在登录 Google 时不会注意到如果没有挂锁。我会说他们已经承担了巨大的责任。
如果我们不信任域的名称服务器，我们可以在根服务器中包含指纹，但我不确定这会增加多少额外负载。
另一个问题是 DNSSEC 尚未得到广泛实施。但我问的原因是因为 IETF 正在考虑支持 http/2.0 中的加密，而不需要证书验证“以使其更易于部署”。
在我看来，安全性要么正确完成，要么根本不正确完成。不要给人一种虚假的安全感。但是，如果我们无论如何都要更改协议（升级所有网络服务器），我们不妨实施 DNSSEC 并以正确的（经过身份验证的）方式执行此操作。
简而言之的问题/变化：
- 我们需要信任（根？）名称服务器而不是大量的 CA；
- 我们需要添加一个dns记录类型或者扩展sshfp记录的使用；和
- 我们需要更广泛地支持 dnssec。
我错过了什么吗？当我们需要做的就是通过一些经过身份验证的通道发布证书的指纹时，为什么我们要为 SSL/TLS 证书支付高昂的费用？
http 2.0 中未经身份验证的加密的目的是鼓励启用它，而无需修改任何其他配置。我反对这一点，因为它不必要地慢（密钥交换的另一个往返，这在海外尤其糟糕或有任何数据包丢失）并且几乎没有增加任何安全性。它甚至可能提供一种虚假的安全感。从好的方面来说，它混淆了流量。
这个使用 DNS 的提议使得在网络服务器上实现加密的工作量更大，但使其（至少几乎）与普通 SSL/TLS 一样安全，同时仍然保持加密的广泛可用性非常高（我不希望他们会保持像使用证书一样，启用 sshfp/httpfp/tlsfp 的名称服务器的价格高得离谱）。当所有其他选项（签名证书；存储的证书；安全发布的指纹）都不可用时，未经身份验证的加密可能仍然是最后的手段（尽管它不应该向用户显示，因为它提供了一种完全错误的安全感），但我不确定是否值得放慢速度。
如果无法为此使用根服务器，我们还可以将域的名称服务器用作“相当安全的环境”（普通挂锁）并为 EV 使用 CA 签名证书（绿色条）。然后告诉人们在进行网上银行业务时寻找绿条。名称服务器已经承担了相当大的责任，因此即使我们不能期望它们像 CA 一样安全，它也可能足够安全。至少它会是一个更加灵活的系统；对于任何价格合理的证书，我仅限于我的域和一个子域（并且该子域已被“www.”占用）。
再次简短地提出我的问题：如果DNSSEC 广泛可用，我们是否有任何理由不为 https 使用类似 SSHFP 的系统？