所以，当我上周没有注意到的时候，CVE2020-13777就出来了。GnuTLS咨询(GNUTLS-SA-2020-06-03)相当不透明，所以我转而参考@FiloSottile(Go Team Security Lead)的这条推文：
13777天哪，在过去的10个版本中，大多数TLS1.0-1.2连接可以被被动解密，而大多数TLS1.3连接可以被截获。小事一桩。
你没看错：用受影响的GNUTLS版本建立的假定加密的TLS连接容易受到被动的文本恢复攻击(在1.3版本中是有效的，但不管怎样，谁都会使用它)。那是非常糟糕的。或多或少，它几乎可以让每个人都改用HTTP而不是HTTPS。关于GNUTLS的安全性--以及一般的安全性--我还有很多话要说，但我现在最关心的是修补GNUTLS的漏洞，所以这篇文章不是关于这个的。
这篇文章是关于弄清楚我们的基础设施到底因此暴露了什么。
这假设您只在运行Buster或更高版本的主机上运行此命令。否则，您将需要找出选择运行GNUTLS 3.6.4或更高版本的计算机的方法。
请注意，此列表仅列出第一级依赖项！完全有可能另一个包使用了GNUTLS，而没有在这里列出。例如，在上面的列表中，我有libcurl3-GNUTLS，所以如果要彻底的话，我实际上需要向下递归依赖树。
可以说，像apt、curl、fwupd和wget这样的抓取器更多地依赖HTTPS进行身份验证，而不是保密，尽管APT有自己的基于OpenPGP的身份验证，所以无论如何都无关紧要。尽管如此，这确实令人苦恼。我在这里没有提到像gobby，network-manager，systemd和其他的东西--范围很广。见鬼，即使是古老的山猫对抗火神。
Umin-o txt-p0'；F：lsbdiscodename=buster'；"；apt-cache--已安装的资源依赖于libgnutls30|grep&39；^'；|ort-u&34；|tee GNUTLS-rdesds-per-host|awk'；{print$NF}'；|排序|uniq-c|排序-n
在那里，结果更加令人担忧，因为这些重要的包裹似乎依赖于GNUTLS来确保运输安全：
Mandos尤其令人苦恼，尽管它可能不容易受到攻击，因为它似乎没有存储明文--它是用客户端的OpenPGP公钥加密的--因此TLS隧道也永远看不到明文。
当然，这个列表并不是详尽的，但它可以作为您不需要担心的常见软件的一个例子。
该漏洞仅存在于GNUTLS中，据我们所知，链接到其他库的程序不会受到攻击。
由于该漏洞影响会话票证--这些票证设置在TLS连接的服务器端--只有作为服务器的GNUTLS用户容易受到攻击。这意味着，例如，虽然我们使用GNUTLS，但只有在充当服务器(在中继模式下确实如此)时，或者如果远程IRCserver也使用GNUTLS时，它才会遇到这个问题。Apt、curl、wget或git也是如此：这不太可能成为问题，因为它只用作客户端；当使用TLS时，远程服务器通常是Web服务器，而不是git本身。
请记住，它并不是因为一个包链接到GNUTLS，它才使用它。例如，有人告诉我，在Arch Linux上，如果GNUTLS和OpenSSL都可用，MUTT软件包将使用后者，所以它不会受到影响。我自己还没有确认这一点，也没有检查过Debian。
此外，因为它依赖于会话票证，所以有一个时间窗口，在此之后票证将循环并正确初始化。但这显然是默认的6小时，所以它只能保护真正持续时间很长的TLS会话，我认为这是不常见的。
我的审计是有限的。例如，与依赖DebianPackage依赖项相比，直接遍历共享库依赖项可能会更好。
似乎该漏洞可能是在此合并请求中引入的，它本身遵循一个(完全合理的)功能请求，以使轮换会话票证变得更容易。合并请求开放了几个月，并在合并前经过同行的彻底审查。有趣的是，VULNERABLE函数(_gnutls_initialize_session_ticket_key_rotation)，明确表示：
*此函数不会在服务器端启用会话工单密钥。这是*使用GNUTLS_SESSION_TICKET_ENABLE_SERVER()函数完成的。此函数只是初始化*内部状态，以支持会话票证加密密钥的定期轮换。
换句话说，它认为它不负责会话票证初始化，但它确实负责。实际上，修复问题的合并请求无条件地执行以下操作：
我还没有详细检查过代码和漏洞，所以对上面的内容持保留态度。
此漏洞的影响取决于受影响的软件包及其使用方式。它的范围可能从"；meh，有人知道我昨天下载了Debian软件包"；到"；天哪我的整个磁盘加密密码已被泄露，我需要重新加密我的所有驱动器"；，包括"；我需要更改所有LDAP和MySQL密码。
然而，展望未来，人们不得不怀疑我们是否应该听从@FiloSottile的建议，完全停止使用GNUTLS。由于OpenSSL许可的奇怪之处，至少有几个程序与GNUTLS相关联，但这是在2015年首次宣布的，然后在2017年明确而明确地解决了--或者可能是在2018年？无论如何，它是固定的，我发誓，除非你是那些仍在使用GPL-2的怪胎之一，当然，除非你是那些仍在使用GPL-2的怪胎之一。尽管OpenSSL不是最简单、最安全的TLS实现，但它可能比GNUTLS更可取，也许我们应该考虑更改Debian包以在未来使用它。
但话又说回来，上一次发生这样的事情时，是心脏出血，枪炮没有受到影响，所以谁知道呢。很可能人们在建议远离GNUTLS时并没有考虑到OpenSSL，而是想到了其他TLS库，如mbedtls(以前称为PolarSSL)、NSS、BoringSSL、LibreSSL等等。也不是说这些都是完全无罪的。
Mandos的合著者在这里。您关于Mandos的看法是正确的；只有OpenPGP加密的数据才会通过TLS连接发送。此外，Mandos确实使用TLS1.3，因此只有活动连接才可能被拦截和解密。
如果有人怀疑这实际上已经完成，那么在每个Mandos客户端上应该做的就是更改OpenPGP密钥，为Mandos服务器配置生成新的加密BLOB，使用与加密磁盘相同的密码；除非来自客户端的OpenPGP密钥也被泄露，否则密码不会被泄露。(当然，更改加密磁盘密码也是一个选项，但这也意味着要为Mandos服务器配置生成一个新的加密BLOB，这意味着比其他选项需要更多的工作。)。
关于您关于心脏出血的评论，我同意；在使用GNUTLS时，我们在最近几年已经能够避免受到大多数TLS漏洞的影响。此外，我们不知道是否有其他TLS库提供OpenPGP密钥作为会话密钥(RFC 6091)或原始公钥(RFC 7250)。我们倾向于避免使用X.509证书，因此我们需要任一证书；GNUTLS最近从前者切换到了后者。