TLS指纹分析研究（下）

在TLS指纹分析研究（上）一文中提到，TLS协议已经成为互联网上最流行的协议，恶意工具可以使用TLS协议将其流量隐藏在大量web浏览器和其他TLS的合法覆盖流量中以逃避检测。

然而，恶意工具在模仿流行的TLS实现如浏览器时，面临着几个挑战。首先，要跟上快速变化的浏览器的TLS实现是不容易的，而且要知道哪些指纹适合模仿；其次，TLS实现可能很难准确模仿，因为许多特性可能不被典型恶意工具中使用的轻量级库所支持；最后，底层库的依赖项改变和更新可能会悄无声息地影响应用程序的TLS指纹，使恶意工具维护人员很难跟上。

本文分析了现有使用或模仿TLS的恶意工具[1]，并将其TLS产生的握手指纹与数据集中真实的TLS握手进行比较，从恶意工具产生的流量指纹角度发现了些许问题，或许有利于我们进行检测和识别。

许多恶意工具使用TLS作为外层协议，比如使用域前置技术来隐藏真正的连接，然而在实践中，以这种方式模拟连接是困难的，任何偏离通常访问这些CDN的行为都可能被检测和阻塞。

本节分析了几种流行的恶意工具生成的指纹，并比较了数据集中这些指纹的相对流行程度，理论上，更频繁被看到的指纹更难在不造成任何附带损害的情况下被检测到，而那些很少看到的指纹可能更容易被检测出来。

S工具是域前置最大的部署者之一，先后使用谷歌和亚马逊进行域前置。

在2018年4月之前使用谷歌应用引擎时，在IOS系统上会生成原生的IOS指纹，出现在2.14%的连接中，在数据集中排名第11，所以不太可能仅仅通过Client Hello指纹进行阻塞，然而在Android系统上，它会生成4个独特的指纹，最多出现在0.06%的连接中，在数据集中排名130。究其原因，S工具在Android上使用okhttp库创建带有三个不同“连接规范”的TLS连接，这些规范定义了Client Hello使用的加密套件和TLS版本，它尝试使用三个前置模拟谷歌地图、邮件和播放这三个不同的客户端，然而，okhttp库默认禁用并从Client Hello中删除了某些在S工具的连接规范中指定的密码套件，导致它偏离预期的连接规范，即使密码套件列表没有更改，这些密码套件仍然对应于不受欢迎的客户端。

到2018年4月，S工具切换到使用亚马逊旗下的souq.com，并更改TLS配置，但仍然有一些密码套件被okhttp库忽略和不发送，生成的两个不同的TLS指纹，每个指纹的出现次数少于100次(<0.000001%的连接)。

截至2018年5月，S工具不再使用域前置，使这些问题变得没有意义。尽管如此，这些示例说明了在模拟流行的TLS实现时面临的几个挑战。首先，库目前并不是专门为模拟任务而构建的，它强调的是安全性，而不是应用程序选择的密码套件。其次，除了密码套件之外，应用程序还必须指定扩展名及其值，以便正确地模拟其他实现。

M工具是洋葱网络的基于域前置的可插拔传输，通过与洋葱浏览器捆绑的Firefox ESR进行隧道，然而ESR版本的指纹相对不常见。截止2018年8月，M工具使用Firefox 52 ESR，其对应的Client Hello是数据集中第42个最受欢迎的指纹，在大约0.50%的连接中出现，此时大多数普通用户已经迁移到Firefox的更高版本，而M工具使用一个接近淘汰的Firefox版本，所以可以以较小的附带伤害阻塞M工具。同时，M工具必须等待底层洋葱浏览器的更新才能接收更新的TLS特征，这使得它在当前设计中相对不灵活。

M工具是洋葱网络的基于域前置的可插拔传输，客户端通过域前置进行连接。某版本生成了和默认Golang TLS非常接近的指纹，但不完全相同的是包含了NPN和ALPN扩展，并提供了一组不同的签名算法，因此，数据集中只有不到0.0008%的连接中出现了这种指纹，这使得它很容易被识别。

TD工具使用折射网络避免被识别，它连接到无伤大雅的网站。截至2018年5月，它使用随机的Client Hello，这可以防止它被直接列入黑名单。然而，TD攻击生成的随机指纹在真实指纹数据集中找不到，可以通过从典型的Client Hello中区分出随机Client Hello来识别并阻塞它，或简单地使用允许TLS Client Hello消息的白名单。

L工具主要依靠随机Lampshade可插拔传输避免被识别，截止2018年2月，部分L工具仍然使用TLS作为传输方式，使用Golang TLS变体发送Session Ticket扩展向服务器传递信息，但不发送服务器名称扩展，这种使用使得它们的指纹不同于默认的Golang TLS，说明应用程序级的需求可能导致明显不同的握手。这种变体在数据集中确实出现了，但发生率非常低，大约0.0003%的连接，在受欢迎程度方面排名1867，所以使其很容易检测并阻塞。

P工具循环使用不同的Chrome和Android指纹，直到找到一个未被屏蔽的指纹，允许它们连接到自己的服务器。即使大多数指纹被屏蔽，如此多样化的指纹组合可能有助于避免被检测到。然而，具有有状态DPI功能的检测器也可以使用此功能来检测，研究人员发现，P工具成功地模仿了Chrome 58-64，生成了两个在数据集中排名前20的指纹，但在模仿传统Android方面不太成功，在110亿连接中，针对Android的指纹只出现在不到50个的连接中，它有时会模仿不需要SNI的Chrome来避免基于SNI的阻塞，生成在小于0.0002%的连接中可见的可阻塞指纹。

虽然TLS协议为恶意工具提供了大量的覆盖流量，但为了成功地避免被检测到，工具必须正确处理许多具有挑战性的细节。在选择协议时，恶意工具一般使用两种高级的策略。首先，它们可能试图模仿一个或多个现有实现，使其难以区分，并增加了阻塞的间接损害；其次，工具可能会尝试生成随机的协议特征，以防止检测人员能够通过黑名单方法识别和阻塞该工具。在本节中，我们将阐述如何将这两种策略应用于恶意工具的TLS实现。

1、模仿

模仿其他客户端的TLS实现面临几个挑战。首先，工具必须选择一个流行的实现来模拟，这通常需要选择一个流行的web浏览器来完成。其次，该工具必须支持加密套件、扩展和流行实现中存在的特性，例如，如果一个工具模仿Chrome发送但实际上不支持CHACHA20密码套件，服务器可能会为连接选择该密码套件，导致该工具终止连接，这不仅会导致兼容性问题，还会给检测者提供一种识别工具流量的方法。

其次，如果服务器由工具维护者控制，这个问题可以得到部分缓解，因为服务端可以只选择工具所支持的密码套件和扩展，但是无法控制两个端点的工具中并非如此，例如域前置、折射网络和生成到其他服务器流量的工具。此外，错综复杂的抗检测协议可能会限制工具可以使用的特性，例如一些域前置工具不能将SNI扩展发送给某些CDN。

最后，由于工具模拟的流行实现会随着时间的推移而变化，支持的特性也会随着自动补丁和更新而变化，所以该工具必须保持对不断变化的特性的支持。例如，虽然有的工具成功地模仿了多个版本的Firefox，但它已经落后于Firefox TLS实现更新的步伐。

2、随机

随机生成TLS Client Hello消息的工具，其优点是不需要识别或跟踪对流行实现的支持，但这种策略只有在有足够数量的相似连接从而避免检测人员区分它的情况下才能发挥作用，例如，图6展示了新连接妨碍检测人员使用白名单的速度。检测器可以通过捕获分布或随机指纹无法正确模仿的其他启发式来区分随机化的Client Hello消息，例如对于没有其他实现同时支持的一对特定的扩展，当恶意工具随机选择这对扩展时，检测者可以识别并阻止此流量。因此，随机指纹策略必须仔细地模拟全局TLS实现的总体分布。

模仿被允许的内容类型或生成随机的流量形状以防止黑名单，这两种方法都可以是恶意工具避免被识别。在前一种情况下，开发人员将必须消除恶意工具和模仿协议之间的所有差异，并防止白名单，以避免被阻塞。但其实成功模拟应用层应用程序是非常困难的，相比之下，随机协议如obfs4，虽然不能避免白名单方法，但可以对抗更常用的黑名单，所以常常更难检测。

在本节中，我们将介绍来自TLS数据集的与恶意工具相关的其他发现。

截至2018年8月，共收集了大约5400个唯一的Server Hello指纹，大大少于唯一的Client Hello指纹的数量。一方面，由于Server Hello消息的内容较少，它只指定了一个密码套件和压缩方法，而不是服务器支持的完整列表。另一方面，虽然客户端实现可能会生成单个或少量的Client Hello指纹集合，但服务器可能会针对不同的Client Hello消息生成不同的指纹。例如，最受欢迎的单外部IP地址(对应Google)，从发送给它的1494个客户端指纹中发送了199个唯一的服务器指纹，仅查看对最流行的Client Hello消息的响应，就会发现有750个不同的Server Hello指纹，这表明与客户端通信的不同TLS服务器的实现和配置的实际数量可能接近这个值。

比较客户端提供的密码套件集，并发现服务端实际选择和使用了哪些密码套件。除去只看到一次的指纹长尾，在数据集的Client Hello指纹中，有超过7900组唯一的密码套件，这些集合列举了522个密码套件值，比标准密码套件的数量还要多。然而，分析服务端选择的唯一密码套件，发现只选择了70个密码套件，前10个占所有连接的93%以上，有趣的是，在所有Client Hello中最流行的密码套件(TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA)仅在大约1%的连接中被选择，这表明有许多密码套件，服务端将很少或永远不会选择。

收集工具忽略无法解析的Client Hello，但即使是格式良好的Client Hello消息也可能包含无效参数。例如，在2字节密码套件的65536个可能值中，只有338个值被IANA识别和标准化，其余未分配或保留为私有，类似地，2字节的扩展字段仅定义了28个值。这允许我们定位指定非标准扩展名或密码套件的Client Hello指纹。总的来说，占连接13.14%的13.8万个指纹中至少包含一个非标准化密码套件或扩展值。

支持非标准特性的共性表明，检测人员可能很难完全了解或使用白名单覆盖所有常用的指纹。非标参数细分如表1所示，展示了唯一的Client Hello指纹的分类和它们出现在发送非标准密码套件或扩展连接中的占比。

本文分析了恶意工具的真实TLS通信，重点是客户端和服务端之间发送的第一个协议消息，这可能使得检测人员识别工具和实现，也简要分析了恶意工具的两种隐藏策略，希望带给检测人员一些思路。除此之外，TLS连接中还有其他信息可用于检测和阻塞恶意流量，比如建立连接后的加密数据长度等特征，又或者研究用户的行为，看是否可以通过连接模式或时间特征来检测恶意流量。

本公众号原创文章仅代表作者观点，不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权，严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用，转载须注明来自绿盟科技研究通讯并附上本文链接。

关于我们