先来说一下我们前天在公众号文章 G.O.S.S.I.P 阅读推荐 2023-08-02 zpoline 里面提出的问题（为什么eBPF不适合system call hooking），我们的读者热心留言，今天先展示一下大家的评论。
来自Jin的留言：
eBPF不合适是因为它计算能力有限，且只拥有写共享map的权限，改不了执行流（无法从eBPF hook直接redirect 到一个userspace handler）
来自小小怪下士的留言：
您好，针对今天推文中“目前在不修改内核代码的情况，ebpf还没法做到完善的system call hook”一问题，个人见解如下：我们知道ebpf是事件驱动的，当应用通过某个hook点时运行。而现有的预定义的钩子主要涉及kprobe、tracepoint、uprobe以及usdt，当前kernel中预定义的这些hook点并没有完全覆盖所有系统调用，因此作者给出了ebpf无法做到完善的system call hook一结论。因为没来得及细看原论文，可能理解并不一定正确。
来自kamile的留言：
ebpf感觉主要是参数获取太麻烦了吧
非常感谢大家的热心评论，我们的公众号需要更多这样的支持哦~
下周就是USENIX Security 2023会议了，今天开始我们来读一下今年的会议论文，首先给大家介绍的是一篇讨论TLS中的session ticket机制实现安全的论文——We Really Need to Talk About Session Tickets: A Large-Scale Analysis of Cryptographic Dangers with TLS Session Tickets*
先说说背景知识，在TLS连接建立的过程中，使用公钥密码算法来进行密钥协商（以及在此过程中涉及到的PKI证书的使用）对服务器的运算资源会产生比较大的开销。为了减少同一个客户端重复访问特定服务器的开销，TLS引入了所谓的 TLS session ticket 机制，允许通信的双方只在第一次会话时执行复杂的密钥协商运算，而此后就保留一个特定的 TLS session ticket 并使用 Session Ticket Encryption Key （STEK）来对其加密保护。后续TLS通信重复利用 TLS session ticket 从而避免密钥协商，直接进入到加密通信的部分。大家可以参考下面两幅图对比一下：
尽管从性能优化上 TLS session ticket 带来了一定好处，安全专家却对这个机制存在诸多批评，大部分集中于对 session ticket 保护不力这个方面。之前 Fiona Klute（参见文章 https://gitlab.com/gnutls/gnutls/-/issues/1011 Cve-2020-13777: TLS 1.3 session resumption works without master key, allowing mitm）和 David Ziemann （参见文章 https://www.hackmanit.de/de/blog/118-analysis-of-the-gnutls-session-ticket-bug-cve-2020-13777 Analysis of the gnutls session ticket bug (cve-2020-13777)）分别介绍了GnuTLS中使用全零的STEK的安全问题。作者进一步深入分析后发现，针对 session ticket 实现的RFC标准——RFC 5077（Proposed Standard）在很多细节上定义很不清晰，让具体的实现代码很容易产生问题。本文因此开展了（可能是首个）针对 session ticket 实现机制的大规模系统调查。具体从如下两个方面进行了分析：
针对12个开源的 session ticket 实现进行了审计，确定了它们使用的数据格式和密码算法的规范，并设计了相关的安全漏洞测试方法；
对网络上使用 session ticket 实现的服务器端进行了大规模安全扫描，还把用到的 session ticket 都收集起来方便后续的离线分析（破解？）
这篇论文的写作比较狡猾讨巧。在论文的第三章，作者先把session ticket可能面临的各种安全威胁（crypto pitfall）都全部说了一遍，包括：
没有对session ticket进行加密；
使用弱密钥对session ticket加密；
密钥流重用：假定服务器使用了流密码，或分组密码的特定模式例如GCM、CCM或者CTR模式导致加密也变成了xor模式，而不同session使用了重复的key，攻击者可以用两组密文（其中一组密文对应的明文已知）进行xor来解密内容；
Nonce碰撞：如果用AES-GCM模式加密不同的session ticket，如果处理了2的48次方个不同的session ticket，就会产生Nonce碰撞（因为AES-GCM模式的Nonce只有12字节，按照生日悖论，当使用的Nonce数目达到2的48次方时就会产生碰撞）；
未使用可认证加密来保护session ticket（RFC 5077里面还推荐使用AES-CBC），可能会导致Padding Oracle攻击；
弱密码算法：可能有些服务器会（莫名其妙）使用DES之类的算法；
其他side-channel攻击
上面这些问题，其实除了前三条，其余的都不太会在现实中产生威胁，论文到了第四章开始对现有的开源代码库进行分析，也并不是针对刚刚提到的所有安全威胁，而主要是针对这些代码库中规定的session ticket格式进行分析。下表展示了不同的库里面定义的各种各样的session ticket格式（以及相关的密码算法）：
通过对开源代码进行分析，作者得到了很多宝贵的基础知识，然后他们就开始对网络上的TLS服务进行大规模扫描了。分析里面最大的困难，是服务器端怎么处理 session ticket 这一黑盒过程。毕竟客户端这边只是保存了一个私有格式的 session ticket 数据，每次重新启动TLS连接的时候发给服务器验证。作者基于前面对开源代码的分析，总结出了 session ticket 遵循的格式（见下图，根据不同的组合，可以列出434种常见的可能格式），然后尝试着对实际的 session ticket 进行分析。
作者利用了著名的ZMap全网扫描工具和ZGrab2这样一个TLS分析工具（主要用于收集 session ticket 和相关的密钥材料）来执行大规模扫描，从2021年到2022年一共做了三组实验。第一组实验针对的是Tranco排名前100万的网站；第二组针对Tranco排名前10万和随机选择的10万个IPv4地址；第三组实验则是在2022年对全网进行了扫描并且对收集的 session ticket 进行了离线分析。
实验过后，就可以看看有趣的结果了。首先，作者报告了扫描到的weak STEK的案例，这里面主要包含了全零的STEK，但是还有3组弱密钥是（0x10 0x11 … 0x1f）这样的格式，同时还发现了75组密钥的格式为（0x31 … 0x31 0x00 … 0x00）。那为什么会出现这些情况呢？
作者首先发现，在使用全零STEK的服务中，有很大一部分使用了 AWS Application Load Balancer 弹性负载均衡（ALB），作者联系了AWS，确认了这种全零的STEK是在 host redirection（例如从 example.com 定向到 www.example.com 域名）的过程中发生的。虽然全零STEK只会影响到最初的域名访问，但是作者表示，由于初始的域名访问中往往会携带和最后重定向域名共用的cookie，在中间人攻击场景下，还是会有很大的安全威胁。
另一些使用全零STEK的案例出现在一些使用了Stackpath这家CDN的网络服务，但是这些案例全部指向了同一个IP（有171个域名指向这个IP），因此很难说这个是CDN服务商的问题还是服务器管理员的问题。
作者还深入挖掘了一个由于Nginx代码实现变化产生的问题。如下图所示，Nginx在2016年12月之前和之后，定义了两种不同的 session ticket 对应的 session key material 存储格式。可是如果使用者没有搞清楚对应的格式，错误地用高版本格式来解析低版本数据（或者反之），则会产生constant key和null key的错误使用。
在论文里面，作者还列举和分析了很多其他的一些小错误，这里我们就不一一介绍了，大家有兴趣可以去自己看论文。
论文：https://www.usenix.org/system/files/sec23fall-prepub-333-hebrok.pdf