摘要
基于应用层探测来识别传输层安全性协议（transport layer security，TLS）的上层服务是了解互联网服务配置和安全性的重要手段。当前的应用层扫描器在工作时依赖于默认的网络协议栈，其传输控制协议（transmission control protocol, TCP)协议专为通用场景设计，只能以受限的速率获取TLS上层服务信息；而TLS协议部分，由于现代化安全配置的软件库，与部分目标服务器不兼容。针对当前应用层扫描器识别TLS上层服务效率不高且不够全面的问题，本文从协议栈优化的角度，首先提出了一种应用于TCP协议栈的混合状态模型，通过引入无状态工作模式和优化有状态工作模式，以减少协议栈中不必要的状态维护和转换，从而提高应用层探测效率；然后，提出了一种面向TLS协议栈的宽松配置策略，通过最大限度的版本和配置兼容来与更加广泛的服务器建立TLS会话；最后，以用户态协议栈的方式将该模型和配置策略实现为异步应用层扫描器TLSnap，并通过可扩展模块的形式提供自定义接口，以支持多种TLS上层服务的识别任务。实验结果表明，在普通硬件配置下，TLSnap扫描器针对大规模端口的TLS上层服务的识别效率比当前先进方法提高3.5倍以上，且平均识别数量增加9%，有效提高了TLS上层服务识别的效率和全面性。
Abstract
Based on the application layer probing to identify the upper-layer services of the transport layer security(TLS), it is an important means to understand the configuration and security of Internet services. Current application layer scanners rely on the default network protocol stack during operation. Their transmission control protocol(TCP), designed for general scenarios, can only obtain TLS upper-layer service information at a limited rate; whereas, in the TLS protocol section, due to modern security configuration libraries, it is incompatible with some target servers. In response to the current problem that application layer scanners are not efficient and comprehensive enough in identifying TLS upper-layer services, this paper first proposed a hybrid state model applied to the TCP protocol stack from the perspective of protocol stack optimization. By introducing a stateless working mode and optimizing the stateful working mode, it reduces unnecessary state maintenance and transitions in the protocol stack, thereby improving the efficiency of application layer probing. Then, a relaxed configuration strategy for the TLS protocol stack was proposed, establishing TLS sessions with a broader range of servers through maximum version and configuration compatibility. Finally, this model and configuration strategy were implemented as an asynchronous application layer scanner, TLSnap, using a user-space protocol stack, and provide customizable interfaces in the form of extensible modules to support various TLS upper-layer service identification tasks. Experimental results show that under common hardware configurations, the TLSnap scanner improves the identification efficiency of TLS upper-layer services for large-scale ports by more than 3.5 times compared to current advanced methods, and the average number of identifications increases by 9%, effectively enhancing the efficiency and comprehensiveness of TLS upper-layer service identification.
0 引言
使用应用层探测识别开放端口的上层服务是深入了解互联网中服务的配置和安全信息的首要工作[1-4]。然而随着安全意识的增强，越来越多的服务被部署到了传输层安全性协议（transport layer security，TLS）上[5]。因此，针对TLS上层服务的高效识别对于互联网服务安全态势感知至关重要[6-10]。
对TLS上层服务的识别需要利用应用层扫描器与目标端口建立加密会话后获取上层服务信息，而当前针对大规模网络的应用层扫描器主要依赖于为通用场景设计的操作系统协议栈。协议栈中的传输层控制协议（transmission control protocol，TCP）完全是以有状态的模式工作，导致其在高速扫描场景下存在复杂的状态转换和冗余的状态维护，限制了应用层扫描器的扫描速率。而广泛使用的无状态扫描技术，虽然可以以极高的效率完成互联网规模的单端口检测，但由于其简单的数据交互流程，无法进一步完成TLS握手及上层协议识别。
操作系统协议栈的会话层往往依赖于TLS软件库，由于密码套件和通信协议的安全性不断更新，客户端TLS软件库的版本和配置较新，而服务端则相对滞后。在实际情况中，从使用TLS1.0版本的老旧设备到仅支持TLS1.3版本的网站，互联网上依旧分布着不同版本和配置的TLS上层服务。因此，大多数应用层扫描器在网络测量中无法与不兼容的服务器建立应用层连接，导致部分确实存在的TLS上层服务无法被发现和识别。
针对上述问题，本文从协议栈的角度对TLS上层服务识别任务进行优化：首先，提出了一种针对TCP协议栈的混合状态模型。通过将无状态工作模式引入到有状态的协议栈中，并对其工作模式进行针对性优化，从而减少不必要的状态转换和维护，有效解决了高速探测场景中应用层扫描器速率受限于协议栈的问题；其次，基于对互联网中TLS上层服务配置和分布的观察，提出了一种面向TLS协议栈的宽松配置策略，通过对加密通信安全性一定程度的妥协，最大限度地兼容服务器上TLS的不同版本和配置，从而提高TLS上层服务识别的全面性；最后，将混合状态模型和宽松配置策略以用户态协议栈的形式实现为异步的应用层扫描器TLSnap，可以部署在常规配置的扫描节点，而不需要特殊的驱动和网卡，以可扩展模块的形式提供自定义接口，实现灵活的服务识别模块定制，使扫描器能够全面高效地完成多种TLS上层服务的识别任务。
1 相关工作和研究
本文重点关注的是面向大规模网络的TLS上层服务高效识别技术，因此本节首先对大规模网络扫描、应用层探测及TLS协议所涉及的相关工作和研究进行讨论。
1.1 无状态扫描技术
无状态扫描技术是当前大规模网络测量的基础，也是发现互联网中服务及其脆弱性的首要步骤。通过避免网络扫描时对本地状态的维护，无状态扫描器能够突破内存和速率的限制，进而提高扫描速率。ZMap[11]作为最流行的无状态端口扫描器，能够在45 min内完成IPv4地址空间的单端口扫描。LI等[12]改进了ZMap，在其基础上增加了对IPv6地址的支持，设计得到了XMap。Yarrp[13-14]、Flashroute[15]和 D-Miner[16]将无状态机制应用于路由节点快速追踪。CHEN等[17]设计的ZBanner将无状态技术进一步改进，支持建立TCP连接后获取响应的横幅。
虽然使用无状态扫描技术的扫描器能够以极快的速率完成互联网规模的扫描，但是只能检查目标端口的开放性，抓取的横幅信息也很有限，无法进行后续的数据交互，因此，当前的无状态扫描技术无法完成TLS握手并建立加密会话，继而对TLS上层服务进行识别。
1.2 应用层扫描器
对于TLS上层服务的识别，由于需要与目标端口建立TCP连接并创建加密会话，因此需要依靠应用层扫描器。主流的应用层扫描器通过利用操作系统协议栈与目标端口建立有状态的TCP连接来完成进一步的数据交互，从而获取关于服务的深度信息。然而，主流的TCP协议栈是为通用场景设计的，难以适应大规模的高速扫描，因此一些应用层扫描器在协议栈的使用方式上做出了改进：经典的Nmap[18]使用自研的Nsock通信库，能够异步使用操作系统协议栈，利用多线程和事件驱动来提高扫描效率；ZGrab[19]将协程机制与操作系统提供的异步API相结合，是当前大规模网络测量的主流工具之一；为了应对互联网规模的广泛目标，应用层扫描器往往与更为快速的无状态扫描器结合使用[20]，这种两阶段扫描的典型代表是ZMap/LZR[21]和ZMap/ZGrab，两者均可实现服务识别，但前者无法识别TLS上层的服务。
由于主流TCP协议栈中的状态维护机制非常复杂，在执行大规模目标的高速扫描时，协议栈必须对每个连接状态进行耗时的管理操作，如图1所示。由图1可以看出，协议栈中使用TCP传输控制块（TCP control block，TCB）用于记录每个连接的状态信息。在扫描过程中，协议栈需要TCB执行状态创建、查询、更新和删除等操作。这些操作在大规模目标扫描场景下显得尤为繁重，尤其是当扫描节点需要同时管理大量并发连接时，每一时刻都存在大量的状态维护。图1展示了连接状态在创建、查询、更新和删除4个阶段的流转过程，分别对应连接建立、连接查询、状态更新以及连接释放的操作。当前应用层扫描器的扫描速率受限于繁重的状态处理过程，即便通过硬件配置的提升来增强节点性能，依然只能实现有限的效率提升，无法彻底突破高速扫描中的瓶颈。
图1高速扫描时的连接状态维护
Fig.1Connection state maintenance in high-speed scanning
1.3 TLS版本和安全配置
自1999年RFC发布的第1个版本以来，TLS已迅速成为衡量通信机密性和完整性的事实标准。尽管该协议经历了多次修订，但其仍然存在重大缺陷[22]。由于TLS软件库无法立即弃用对不安全密码、哈希算法和过时协议版本的支持，并且TLS配置涉及Web服务器、依赖库和操作系统的协作，导致互联网上广泛分布着使用TLS不安全版本和配置的上层应用服务。KOTZIAS等[23]发现，由于过去10年中TLS生态系统的重大变化，客户端采用新算法的速度很快。与此不相称的是，超过233 000个Web服务器仍然容易遭受因不安全配置引起的攻击，大约203 000个Web服务器仍然使用过时版本的OpenSSL[24]。
由于客户端TLS的现代化与互联网中过时TLS配置的存在，在进行TLS上层服务识别时，当前使用TLS软件库默认配置的应用层扫描器无法与部分服务器完成TLS握手并建立加密通信，从而错过该类服务。
2 混合状态模型
针对TCP协议栈提出的混合状态模型如图2所示。与操作系统协议栈中的TCP实现总是工作在耗费资源的有状态模式不同，混合状态模型在此基础上引入了无状态工作模式，并在工作过程中适时进行模式内和模式间的状态转换，通过减少无效状态的维护来减少扫描耗时。同时，混合状态模型摒弃了主流协议栈TCP实现中不适用于高速网络扫描场景的冗余特性，仅使用2个状态描述TCP连接建立后的通信过程，通过对状态转换的简化来提高扫描速率。本节主要阐述混合状态模型的构建过程。
图2混合状态TCP工作模型
Fig.2Dual-mode state model for TCP
2.1 无状态工作模式引入
在互联网规模的高速网络扫描场景中，由于开放端口的稀疏性和端口配置的实时变化，以有状态模式工作的传统TCP协议栈往往假设端口开放，从而维护无效的连接状态，进而导致扫描时间的增加。虽然可以结合无状态扫描器使用两阶段扫描技术，但是这会触发部分端口的防御机制，从而影响应用层扫描的结果[21]。受到无状态扫描器的启发，本文将无状态工作模式引入到有状态的TCP协议栈中。
以当前流行的无状态扫描器ZMap[11]的无状态工作机制为例，它通过发送携带验证字段（Cookie）的TCP SYN报文段并接收编码正确的SYNACK报文段来完成端口扫描，其工作过程如图3所示。由于没有建立TCP连接以及后续通信过程，ZMap只具有2个状态：即初始的CLOSED状态和能够通过Cookie识别的SYN_SENT状态，其状态转换如图4所示。
图3当前无状态扫描技术通信过程
Fig.3Communication process of current stateless scanning technology
由于无状态扫描器能够高效完成端口扫描，并且其工作过程也是TCP连接建立的必要步骤，因此将这种无状态的工作模式引入到有状态协议栈的握手阶段，如图2中的无状态模式部分所示。本文提出的模型在设计上采用了这种混合状态的形式，因此其运行时会在无状态和有状态工作模式间进行切换。
图4当前无状态扫描技术状态转换
Fig.4State transfer of current stateless scanning technology
2.2 工作模式切换时机
连接状态的维护需要耗费内存和计算资源，这都可能影响到扫描速率的提升。特别是在高速扫描场景中会遭遇一些网络异常，导致扫描器耗费资源去维护无效的连接状态。在不放弃可扫描目标和不丢失响应信息的前提下，混合状态模型需要尽可能地避免进入或停留在无效的有状态模式中。因此，本节重点对有状态模式的进入和退出2个关键时机进行优化，如图5所示。
图5混合状态模型通信过程
Fig.5Communication process of dual-mode model
混合状态模型在发送携带Cookie的SYN报文段后并不为该连接建立状态，而是异步地等待正确编码的SYNACK报文段返回，从而判断端口是否开放。目前互联网中存在相当数量的端口采用零窗口防护配置[21]，这些端口即使在返回SYNCACK报文段并建立TCP连接后也无法正常交互数据。因此，混合状态模型在确认SYNACK报文段中的窗口值大于0后，才会立即返回ACK报文段完成握手，避免建立无法完成数据通信的无效连接。同时，混合状态模型为该连接创建并维护状态，从而进入有状态工作模式。
在实际的应用层扫描中，一些端口虽然没有使用零窗口防护，但与其建立连接后，该端口既不返回横幅信息，也不对包括探针在内的任何后续报文段作出响应。即使应用层扫描器因为连接超时而主动发送FIN报文段来尝试关闭该连接，也无法得到任何响应，从而在相当长的时间内维护处于半关闭状态的无效连接。因此，当通信任意一方决定断开连接或接收到非预期报文段时，混合状态模型会立即发送RST报文段来重置连接，并删除该连接状态，从而退出有状态模式。这避免了混合状态模型为了维护半关闭状态而耗费的带宽和时间成本，同时，也及时通知扫描目标结束该连接，避免对目标服务器造成困扰。
无状态工作模式中对于状态识别和处理的流程如算法1所示。
算法1 无状态工作模式中的状态识别和处理
若接收到的数据包为合法TCP报文段，则根据其携带的标志位进行处理：即当标志位为SYNACK时，如该报文段通过验证且TCP窗口值不为0，则为当前连接发送ACK报文段确认握手，并创建连接状态，否则回复RST报文段以中断连接；当标志位为RST时，如该报文段通过验证，则表示该目标端口处于关闭状态，回复RST报文段以关闭连接。对于其他类型的TCP报文段，交由有状态工作模式进行处理。
2.3 有状态工作模式优化
主流的TCP协议栈实现具有丰富的特性，从而应对各种极端的网络环境并维护长时间的稳定连接。然而，在面向互联网规模的高速扫描场景下，默认为扫描节点提供良好的网络环境和足够的带宽资源。同时，应用层扫描器仅利用目标端口返回的横幅信息即可完成服务识别，不需要和扫描目标进行长时间的数据交互。因此，针对高速扫描场景中的服务识别需求，本节对混合状态模型中的TCP工作方式进行优化，摒弃影响扫描速率的冗余特性，简化数据包的处理流程。
2.3.1 使用半双工通信
TCP协议通过独立的序列号和确认号可以实现全双工通信，即通信双方可以同时发送和接收数据。虽然在2个方向上同时传输数据可以使通信效率更高，但在高速扫描时的服务识别场景下，扫描器和目标端口之间的探针数据和响应数据通常是交替发送，全双工通信在效率上并没有贡献。为了实现全双工通信，协议栈还必须对接收到的数据进行缓存，从而占用更多的计算和内存资源。
在兼容目标端口的TCP实现前提下，混合状态模型在内部使用半双工的方式进行通信。当连接建立后，混合状态模型在同一时刻只处于SENDING和RECVING状态中的一个，如图2中的有状态工作模式部分所示。当接收到数据后，混合状态模型会立即将其返回至上层识别模块的回调函数进行处理，避免不必要的数据缓存。同时，还迫使识别模块在报文段粒度处理该连接事务，及时销毁不必要的连接。
有状态工作模式中的状态处理流程如算法2所示。对于有状态工作模式中的每一个TCP连接，需要周期性地对其所属状态进行判断并作出相应处理：当该连接为接收状态时，如接收到来自目标端口的数据，则对数据进行确认并交由上层模块处理；如存在需要发送的数据，则将数据组装为报文段后发送，并将当前连接转换为发送状态；当该连接为发送状态时，持续等待或进行重传，直到已发送的数据被目标服务器确认，然后将当前连接转换为接收状态；在循环处理状态时，任意时刻如果通信一方断开连接，则发送RST报文段将连接重置，并销毁该连接所属状态。
算法2 有状态工作模式中的状态转换和处理
由于对接收数据的实时处理，混合状态模型并不需要在运行过程中对自身的滑动窗口进行计算和调整，始终能使用一个较大的窗口值。这允许目标端口以较高的效率返回响应数据。
2.3.2 摒弃拥塞控制
为了合理利用有限的链路带宽，TCP协议的很多实现中默认使用了端到端的拥塞控制算法，主要是利用包括慢启动、拥塞避免和快速恢复等机制。端到端拥塞控制算法用于防止网络因为大规模通信负载而瘫痪，并尽可能最大化各个应用程序的带宽利用率。通常在连接起始阶段，客户端会经历发送速率由低到高的一系列尝试，以此来寻找最优速率。
然而，在高速网络扫描场景中，默认扫描器能够独占良好的网络环境，并且为了完成服务识别任务，与每个目标端口的通信过程都只有少量、短时的数据交换。在这样的条件下，拥塞控制算法的使用会对带宽资源造成一定的浪费，同时也会耗费计算资源。混合状态模型摒弃了经典的端到端拥塞控制算法，不对相关变量进行动态调整，始终以高速率发送数据包，尽可能地占用带宽资源以减少扫描耗时。
3 宽松配置策略
针对大规模网络的应用层扫描器在进行TLS上层服务扫描时，所依赖的TLS协议栈是基于相关的软件库及其默认配置，如OpenSSL、GnuTLS和BoringSSL等。由于TLS协议的安全性迭代和客户端相关软件库的快速更新，其默认配置趋于现代化，从而与一些服务器不兼容且无法建立TLS连接，最终导致在完成服务识别时丢失部分结果。为了与尽可能多的服务器建立TLS连接，本文提出并实施了一种宽松配置策略，其核心思想是通过TLS软件库的设置，以提高扫描器在各种不同TLS版本和配置环境下的兼容性。考虑到TLS协议的复杂性和多样性，服务器端的配置可能包括使用较旧的TLS版本、不常用的加密算法组等，甚至还会使用一些存在已知漏洞的设置。这些配置通常会导致常规的TLS客户端无法成功建立连接。为了解决这些兼容性问题，本文所设计的宽松配置策略思路如下：
首先，在配置中扩展对TLS版本的支持范围，不仅支持最新的TLS1.3，还包括较旧的版本如TLS1.0和TLS1.1，甚至某些情况下允许使用已被弃用的SSLv3，以确保扫描器能够与配置不一致的服务器成功协商。此外，启用更广泛的加密算法组（Cipher Suites），包括那些被认为安全性较弱的算法，如RC4和DES，以应对服务器端可能使用的过时配置。然后，降低了对证书验证的严格性，允许忽略证书链中的非关键错误（如自签名证书或过期证书），并且在某些情况下禁用了对主机名匹配的强制要求，从而提高连接的成功率。另外，还在握手过程中启用了多个TLS扩展（extensions），如服务器名称指示（SNI）和会话恢复（session resumption），以增加与不同服务器配置的兼容性。最后，为了进一步确保连接成功，设置在初始握手失败后自动调整配置参数并重试，以最大化连接的机会。
所涉及的相关配置整理如下：
1） TLS版本：设置所支持的TLS最高和最低版本，以支持尽可能多的服务器。
2） 密码套件：允许所有可用的密码套件，甚至是弱密码和不安全的密码套件，以最大化兼容性。
3） 服务器证书验证：禁用服务器证书验证。虽然会降低安全性，但能够避免由于证书问题而导致的连接失败。
4） 证书名称检查：放宽证书名称检查规则，以提高与不同服务器的兼容性。
5） 重新协商机制：允许与使用旧版或不常见配置的服务器重新协商，帮助客户端成功建立连接。
6） 会话恢复：启用客户端会话缓存，允许在多个连接中重用TLS会话，从而提高兼容性。
7） 会话票证：禁用会话票证的使用，这在一些不支持此特性的服务器上可以提高兼容性。
8） 散列算法：允许使用旧的、不安全的协商方法，以便与使用旧版配置的服务器建立连接。
9） TLS压缩：禁用TLS压缩扩展，避免与不支持该特性的服务器发生兼容性问题。
10） SNI扩展：在可能的情况下（如虚拟主机名已知），启用服务器名称指示（SNI）扩展，避免与部分特殊设置的服务器握手失败。
尽管宽松配置策略在一定程度上牺牲了TLS连接中的通信安全性，但对于主动扫描和服务识别任务而言，连接的广泛性和兼容性更重要。
4 扫描器设计
本文以用户态协议栈的形式将混合状态模型和宽松配置策略实现为一个异步的应用层扫描器TLSnap，通过借助Libpcap/Npcap库来绕过系统协议栈，从而在用户层处理数据包。所实现的TLSnap扫描器可以在Windows或Linux系统中编译和执行，而无须安装专用驱动或网卡，因此便于快速地部署扫描节点。本节就TLSnap中的关键设计进行阐述。
TLSnap扫描器的总体架构如图6所示，具体工作流程分为2个部分，分别由数据包发送线程和数据包接收线程执行，通过2个线程的并行交互实现异步机制。对于发送线程，负责根据用户的设置对扫描器属性进行配置，并对录入的目标地址集进行随机化，然后逐一对每个目标地址生成初始的数据包并注入验证字段，最后通过速率控制器以限制每秒发送的数据包数量；对于接收线程，当接收到TCP报文段类型数据包时，通过状态识别算法将其分派到对应的无状态或有状态工作模式处理流程中。其中，混合状态模型和宽松高配置策略被融入到接收线程的用户态协议栈中，并将服务识别抽象为可定制模块，通过提供接口的形式允许自定义服务识别模块来扩展TLSnap扫描器的能力。接收线程中的所有数据包回复需求都经回调发送队列交由发送线程进行处理。
图6TLSnap扫描器总体架构
Fig.6Architechture of TLSnap scanner
4.1 融入异步机制
在扫描算法允许的情况下，异步的数据包收发机制能够充分利用网络带宽和CPU计算资源，从而提高扫描速率。因此，将用户态协议栈与异步收发机制相结合，将数据包的发送和接收操作解耦至不同的线程中。发送线程为数据包注入验证字段并随机化目标地址集，由于不需要等待目标端口响应，所以能高效利用带宽资源，在更短的时间内扫描更多的目标。
根据混合状态模型和宽松配置策略所实现的用户态协议栈位于接收线程中，通过检查接收数据包的验证字段和类型，从而判断数据包所属连接的状态，并交由不同工作模式的TCP协议栈进行处理。将接收线程与CPU核心进行绑定，以充分利用计算资源来处理连接状态。由于协议栈在对已有连接完成状态转换之后可能还需要继续发送数据包，但接收线程不适于承担数据包发送责任，因此在发送线程和接收线程间建立数据包回调发送队列，使得接收线程能够以异步的形式将数据包的发送委托至发送线程，从而避免接收线程因为网络I/O的阻塞而浪费属于协议栈的计算资源。
4.2 可拓展的识别模块
相比于任务单一的端口扫描器，应用层扫描器需要处理种类繁多的服务以及更加多样化和丰富的响应信息。这不仅要求扫描器具备提取各种应用层服务信息的能力，还需要对这些服务进行准确解析与分类。为了有效应对这些复杂的应用层服务识别任务，本文以TLSnap扫描器的用户态协议栈和异步数据包收发机制作为基础设施，将服务识别任务抽象为可定制的识别模块，并通过统一接口的形式提供灵活的扩展性。这种设计允许用户根据特定需求定制识别模块，从而实现对TLS上层服务的精准识别和分类。用户在自定义识别模块时，可以专注于TLS上层具体服务的数据交互和识别逻辑，而无须担心底层通信的实现细节。TLSnap扫描器负责确保高效的扫描速率、可靠的TCP通信以及稳定的TLS会话连接，为识别模块的开发提供技术保障。
该设计使得TLSnap扫描器不仅能够适应广泛的应用场景，还能轻松应对多样化的协议和服务类型。通过这一灵活的识别模块架构，用户可以快速扩展扫描器的功能，以满足不同的服务识别需求，从而在复杂的网络环境中依然能够保持高效的扫描和精准的识别。
4.3 具有宽松配置的TLS功能支持
TLS协议自诞生以来，已经经历了多个版本的演变和更新，每个版本都涉及复杂且关键的安全性主题，如加密算法、身份验证、数据完整性等。这些主题不仅需要深入的理论理解，还需要在实际应用中精确的实现与验证。因此，独立地在TLSnap扫描器中从零开始实现TLS功能，无疑是一项极其艰巨的任务，这不仅在技术上具有高度挑战性，而且在维护和更新方面也会耗费大量资源。此外，由于TLS协议的复杂性和广泛应用，任何从零实现的TLS功能都可能面临兼容性问题，难以确保与各种版本和配置的服务器正确通信。
为了确保TLS功能实现的正确性、稳定性和广泛的兼容性，本文选择使用了被业界广泛认可和应用的开源安全通信库OpenSSL作为TLS协议的实现基础。OpenSSL经过了多年社区和行业的验证，其提供的强大功能和灵活性也使其成为实现TLS通信的首选工具。在TLSnap扫描器中，通过混合状态协议栈来实现TCP异步通信，确保在网络层面的高效数据传输。同时，借助OpenSSL的抽象I/O框架BIO（basic input/output），能够将数据加解密过程无缝集成到整个扫描器的工作流程中。BIO机制作为数据流的中介，使得OpenSSL在TLSnap扫描器中能够稳健地执行TLS协议的各项操作，从而有效支持多种上层服务的识别和通信。
此外，为了实现与尽可能多的不同配置的目标服务器建立TLS会话，在OpenSSL的参数设置中引入了本文提出的宽松配置策略。该策略旨在最大程度地提高TLS连接的兼容性，允许与各种不同版本、不同安全配置的服务器建立连接。
5 实验分析
本节通过系列实验来刻画TLSnap扫描器的特点，并通过与同类先进工作进行对比展现其优势。
5.1 实验设置
5.1.1 硬件
考虑到主动网络扫描时节点部署的实际情况，本文将实验环境限制在常规配置下。所有的实验在配备12核CPU、16GB内存的个人笔记本电脑上进行，并为其分配了上下行对等的1GbE带宽网络。主机上运行Ubuntu22.04-LTS操作系统及6.5.0-41-generic版本Linux内核，无其他特殊网络设置。
5.1.2 地址集
为了避免扫描源地理位置和供应商限制策略对实验结果的干扰，将扫描范围限制在中国大陆运营商所管理的公有IP地址集（以下简称“地址集”）或其子集中。该地址集共涵盖了5 446个IP地址段，约3.42亿个独立公网IP。
5.1.3 对比工作
应用层扫描器ZGrab：基于操作系统协议栈与目标端口建立TCP连接，并完成TLS握手以识别相关服务。使用最新发行版。
两阶段扫描方案ZMap/ZGrab：通过管道的形式将2个工具串行连接，以执行连续的两阶段扫描。前者使用无状态机制确定端口开放性，后者对开放端口重新建立连接获取应用层信息。均使用最新发行版。
5.1.4 扫描任务
实验中涉及的应用层扫描器能对不同目标端口的多种TLS上层服务进行扫描和识别，根据目的不同，针对每一种识别出的服务又会采用不同的处理方式，这些外部因素都会对扫描器的性能测试结果造成影响。为了客观地对扫描器自身的性能进行评估，本文期望结合互联网中的实际情况，决定以识别HTTPS服务作为所有实验的基本扫描任务，且根据实验的不同，涉及HTTPS服务的默认端口443及分布最为广泛的前5个端口（8443，5001，4433，10250，10443）。
设定扫描任务的考虑依据为：HTTPS是最为典型的一种TLS上层服务，在TLS上层服务中具有代表性；HTTPS服务的默认端口TCP 443是互联网中的流行端口之一，其开放比例相对较高，开放程度较为稀疏的非流行端口会将评估的重点由应用层扫描偏移到端口发现上；仅对服务进行识别而不对响应内容进行后续处理，避免了扫描任务的特殊需求影响评估结果；在部分实验中需要评估扫描器服务识别能力的广泛性，因此加入了HTTPS分布最为广泛的前5个端口作为探测目标。
5.1.5 扫描速率衡量标准
虽然扫描速率（每秒发送数据包的数量）是对扫描器执行效率最直接的表现，但是在实际实验中难以计算其平均值，并且各软件的测算方法存在差异。因此，本文使用更为客观的扫描耗时作为扫描器的效率衡量标准。
5.2 可用性分析
混合状态模型作为一种面向特殊场景的TCP工作方式，首先需要评估其在实际扫描中的可用性，特别是模型中的一部分以无状态方式工作，该部分彻底放弃了对TCP数据传输可靠性的保证。
根据已有无状态扫描器的评估结果[25]，当带宽资源足够时，对目标的命中能力会随着数据包发送速率的提高而降低，从而导致对测量目标覆盖率的减少。过低的覆盖率会导致扫描结果无法用于网络测量研究，因此，需要测量TLSnap扫描器的覆盖率随扫描速率的变化情况。
覆盖率的计算公式为：
(1)
式中，NScan表示执行扫描时对目标的命中数量，NTruth表示地址集中实际上能够被命中的目标数量。对于端口扫描而言，“命中”表示获取到目标端口的开放性信息；而对于本文的扫描任务，“命中”表示抓取到目标端口上的HTTPS横幅并识别。
通过从地址集中随机抽取10%的地址作为扫描对象，从较低的扫描速率开始尝试，从而测试TLSnap扫描器的命中数在速率从1 000 pps增长至1 Mpps期间的变化情况，将结果绘制如图7所示。根据实验结果，当扫描速率在50 Kpps以下时，其命中能力稳定在较高水平；当扫描速率高于200 Kpps时，命中能力开始明显下降。
由于ZGrab基于系统协议栈进行应用层扫描，能够保证TCP的可靠传输，因此拟以独立执行ZGrab 时的命中数量作为基准值NTruth。但从命中能力的实验结果来看，TLSnap扫描器在扫描速率较低时的命中数量明显高于ZGrab的结果。这是因为TLSnap扫描器采用了宽松配置策略，对目标端口的TLS版本和设置要求较为宽容，能够与更多的服务器建立TLS会话。为了得到更为合理的结果，对TLSnap扫描器速率最低的3个命中数取均值作为基准值NTruth，绘制最终的覆盖率变化情况，如图8所示。
图7命中数量和扫描速率的关系
Fig.7Relationship between hit count and scan rate
图8覆盖率和扫描速率的关系
Fig.8Relationship between coverage rate and scan rate
从计算结果来看，当扫描速率在200 Kpps以下时，TLSnap扫描器的覆盖率稳定在98%以上；当扫描速率超过400 Kpps时，覆盖率开始低于90%。当扫描结果的覆盖率为98%以上时，可以认为扫描器的探测结果是覆盖全面的，可用于典型的网络测量研究应用。
5.3 效率评估
由于如今的网络测量常常通过多个扫描节点分布式完成，因此在大部分情况下难以保证所有的扫描节点所在主机中都是高性能配置。为了展示TLSnap扫描器在普通终端硬件下的实际效率，基于5.1节中所示的条件，以地址集中所有IP地址为目标进行HTTPS服务识别。对比工作均以可能的最高扫描速率运行，保证无本地丢包且完成扫描任务。记录实验结果见表1所列。
表1扫描效率对比
Tab.1 Comparison of scan rate
在该实验中，根据发包速率不同，使用了2个版本的 TLSnap：TLSnap-1的发包速率为 200 Kpps，是保证扫描结果覆盖率高于98%时的最低速率； TLSnap-2的发包速率为 310 Kpps，是对针对该地址集进行大规模扫描时可用的最高速率，其覆盖率在95%以上。然而，2种情况下所占用的带宽都远达不到实验条件中的1GbE上限，这并不是因为TLSnap扫描器的协议栈无法处理较高的扫描速率，而是当使用TLSnap扫描器进行大规模HTTPS服务识别时，接收线程中密集的TLS加解密运算造成了阻塞，从而将限制扫描速率的瓶颈从协议栈转移到了CPU计算能力，这也从侧面反映了混合状态模型的有效性。
从实验结果来看， TLSnap-1和TLSnap-2的扫描效率分别是ZMap/ZGrab的3.5倍和5.7倍。即使按照 310 Kpps的扫描速率，扫描覆盖率也在95%以上，可以根据实际测量需求进行选择。
相比于使用了混合状态模型的TLSnap扫描器和加入了无状态端口扫描的两阶段扫描方案ZMap/ZGrab，只使用ZGrab扫描广泛的目标端口时，效率会急剧下降，无法在可接受的时间内得到扫描结果。这是由于完全有状态的工作模式会将时间浪费在与未开放的端口尝试建立连接，导致应用层扫描整体时间的增加，因此引用无状态工作模式对TLSnap扫描效率的提升具有突出贡献。
此外，本节对有状态工作模式优化所起到的作用也进行了评估。为了尽可能减少无状态工作模式造成的影响，使用端口扫描工具收集了地址集中TCP 443端口开放的IP列表，形成约2 643 000的子地址集作为扫描目标。使用3个方案分别对子地址集进行扫描，相关结果见表2所列。
表2有状态工作模式优化效果
Tab.2 Effect of stateful mode optimization
由表2可以看出，当几乎不考虑无状态工作模式的引入所带来的优势时，3个解决方案的效率差距有所减少。使用两阶段扫描的ZMap/ZGrab与完全有状态的ZGrab在扫描效率上基本相当，而经过有状态工作模式优化的TLSnap扫描器在扫描效率上约有23%的提升。另外，此时TLSnap的扫描速率远未达到会导致命中能力降低的程度，带宽使用上也远未达到网络环境限制，扫描速率的瓶颈集中在TLS协议相关的加解密运算上。可以推断，如果使用硬件配置更高的主机，效率将进一步提升。
5.4 全面性评估
由于TLSnap扫描器中的TLS协议栈应用了宽松配置策略，理论上应当能够兼容更多不同类型的TLS版本和配置，与更为广泛的服务器完成TLS握手，这在5.2节的实验中已有初步体现。为了验证TLSnap是否能够识别出更多数量的服务，以及宽松配置策略在实际网络测量中是否具有实际意义，本节除默认运行端口TCP 443，还选取了分布最为广泛的前5名端口作为目标端口，并从地址集中选定某市范围内所有公网IP地址段作为目标地址，分别使用TLSnap扫描器和ZMap/ZGrab两阶段扫描方案进行HTTPS服务识别，实验结果及对比见表3所列。
从实验结果中可以看出，相比同类工作，TLSnap扫描器确实能识别出更多数量的TLS上层服务，具体情况依端口的选取和服务的实际分布差异而有所不同。在本节所选择的实验条件下，TLSnap扫描器识别服务的数量相比当前先进工作最高可增加43.07%，并在总量上增加了9.05%。这说明在TLSnap扫描器中实施宽松配置策略，确实提高了扫描器在面对多种类型探测目标时的兼容性及TLS上层服务识别的全面性。同时，实验结果也反映出互联网中依旧存在相当数量的低版本和弱配置TLS上层服务，从人工核查情况来看，此类服务中有很多是老旧设备或Web系统，甚至使用最新版的浏览器已无法访问，必须使用旧版本的浏览器或开启IE兼容模式才能访问页面。
表3各端口HTTPS服务识别数量对比
Tab.3 Comparison of identified HTTPS service quantities on each port
6 结束语
本文针对当前的应用层探测技术在识别TLS上层应用服务中还存在探测速率受限、识别类型不全等问题，提出了一种面向TLS协议栈的宽松配置策略。通过定制TLS软件库配置规则，拓展了应用服务的识别范围，设计了一个异步应用层扫描器TLSnap，以用户态协议栈的方式实现了TCP混合状态模型和配置策略，通过实验验证了本方案的高效性和全面性。然而，当前的主动协议识别技术仍然依靠于静态指纹特征匹配，TLSnap只能完成已知协议的识别，如何脱离指纹库完成未知协议的识别将是未来工作的重点。
