一篇发表于USENIX Security '22的，关于OpenVPN做主动探测攻击的文章。密西根大学 | OpenVPN下的指纹识别原文标题：OpenVPN is Open to VPN Fingerprinting 原文作者：Diwen Xue, Reethika Ramesh, Arham Jain, Michalis Kallitsis, J. Alex Halderman, Jedidiah R. Crandall and Roya Ensafi 原文链接：https://www.usenix.org/conference/usenixsecurity22/presentation/xue-diwen 视频链接：https://youtu.be/ZNVff1rH-vA 发表会议：USENIX Security '221、引言本文分析了流行的VPN工具OpenVPN，并受GFW(Great Firewall)的启发，提出一种由被动分析和主动探测相结合的两阶段识别框架，通过分析字节模式、数据包大小和服务器行为3种特征，在低误报率的情况下，识别了85%以上的OpenVPN流量。2、威胁模型与GFW的威胁模型类似，具体分为如下6个阶段：客户端通过ISP网络连接到VPN服务器；过滤器备份ISP网络中的流量；过滤器将可疑目标转发至探测系统；探测系统将目标分发至不同探测器；探测器发送探针获取探测结果；探测结果为VPN服务器的目标被存入数据库。3、特征选取在本文中，作者选取了3种特征来识别OpenVPN流量，即字节模式、数据包大小和服务器行为，其中前两个属于被动分析，最后一个属于主动探测。下图是OpenVPN的握手和数据交换过程，3种特征都基于此过程。3.1 字节模式基于字节模式的指纹识别方法通过分析 OpenVPN 流量中的操作码（Opcode）字段来识别流量类型。OpenVPN 数据包包含一个操作码字段，用于指示消息类型，如客户端和服务器重置、TLS 加密数据等，完整字节模式如下图所示：本文通过捕获前 N 个数据包的操作码序列，若序列中的不同操作码数量≥4（至少需要4种不同的操作码来完成握手，协议一共定义了10种操作码。），并且Client和Server的Reset操作码分别只出现过1次，则将该流量标记为OpenVPN流。此外，OpenVPN 使用 XOR 混淆技术保护数据负载，但操作码数量不受影响，因此即使流量经过混淆，操作码仍能提供有效的识别特征。这种指纹识别方法无需精确匹配操作码值或数据包大小，鲁棒性高，并能有效应对多种 XOR 混淆技术，确保高效准确地识别 OpenVPN 流量。3.2 数据包大小在OpenVPN的控制通道中，P_ACK包用于确认P_Control包，这些ACK包具有固定大小，并且只在会话的初期握手阶段出现，在数据传输阶段则不再使用。因此，P_ACK包在OpenVPN流量中呈现出独特的时序模式，成为一个可被识别的特征。具体来说，本文通过分析OpenVPN会话的初期包交换序列（C->S (Client-Reset), S->C (Server-Reset), C->S (ACK), C->S(Control)），定位出初始的P_ACK包(第3个)，并计算在每10个数据包中的ACK包数量，看是否满足OpenVPN的ACK数据包指纹（初期多，后期少）。该指纹识别技术对于识别未经随机填充（不改变ACK数据包大小）的OpenVPN混淆流量非常有效，且容易在实际的流量监控中部署。3.3 服务器行为本文讨论了通过主动探测识别OpenVPN服务器的可行性。许多OpenVPN服务器使用tls-auth或tls-crypt选项，增加了HMAC签名以提供完整性和认证机制，使得未经认证的客户端探测请求被服务器丢弃，从而提高了抗探测能力。尽管如此，作者设计了针对OpenVPN的探测方法，通过利用TCP层的行为特征，如超时或重置行为，仍能有效识别OpenVPN服务器。OpenVPN处理TCP包的流程如上图。3.3.1 基础探针OpenVPN在处理TCP流时，会在内存中分配缓冲区，组装接收到的数据包片段，直到满足长度条件才开始解析和检查语法及加密错误。基于这一行为，作者设计了两种探针，以期望触发OpenVPN服务器的两种不同反应。作者根据OpenVPN服务器与非OpenVPN服务器对两种探针的不同反应识别OpenVPN服务器。第一个探针（BaseProbe 1）包含一个经典的16字节OpenVPN客户端重置包，第二个探针（BaseProbe 2）在前者基础上去掉末尾一个字节。大多数非OpenVPN服务器会以相似的方式响应这两种探针，而对于启用HMAC的OpenVPN服务器来说，因为验证HMAC失败，第一个探针会被立即丢掉；第二个探针因没有凑够有效的解析长度而等待至超时。3.3.2 附加探针为了进一步提高对OpenVPN服务器的探测精度，作者设计了基于Linux服务器关闭TCP连接方式的探针。当TCP连接在有未读字节时被终止，Linux服务器会发送RST包。大多数OpenVPN服务器的RST阈值（RST阈值定义为触发RST包所需的最小字节数）在1550-1660字节之间，而大部分非OpenVPN服务器的阈值低于500字节或高于4000字节。因此，作者构造了一个包含2000字节随机数据的探针，预计98%以上的OpenVPN服务器会回应RST包，而非OpenVPN服务器的回应率不到3%。此外，由于OpenVPN支持端口共享功能，探针可能被转发给共享端口的其他服务（HTTP、TLS和SSH）解析，因此在发送基础探针后（此时已经过滤了大部分非共享端口的HTTP、TLS、SSH等服务），会首先探测这些服务，若收到正常响应，则停止探测，并将该服务器标记为非OpenVPN服务器。4、实验结果为了验证方案的有效性，作者将该方案部署到真实的ISP网络中，并得到如下实验结果：总的来说，在控制流中，识别原版OpenVPN的召回率达到85.90%，识别具有混淆技术的OpenVPN的召回率达到72.67%。在所有流中，共识别出3245个能够被证实是OpenVPN流量的流，393个不能够被证实的流。
使用完全加密协议隐藏协议元数据
这篇发表于CCS '24的文章，从理论层面证明什么是完全加密协议，并对完全加密协议做了定义。美国海军学院 | 使用FEP（完全加密协议）隐藏协议元数据原文标题：Bytes to Schlep? Use a FEP: Hiding Protocol Metadata with Fully Encrypted Protocols 原文作者： Ellis Fenske and Aaron Johnson 发表会议：ACM CCS '24 原文链接：https://dl.acm.org/doi/10.1145/3658644.36901981、引言完全加密协议（FEP）通过隐藏通信元数据（如版本号和长度字段）使数据呈现为随机字节，从而规避网络审查。尽管存在检测和阻断方法，但其仍具有很高的实用性。完全加密趋势也反映在 TLS 和 QUIC 等协议中。此外，FEP还通过填充技术隐藏协议字段和消息的长度，进一步增强了规避审查的能力。常见的FEP有Tor中的obfs4、V2ray中的Vmess、Shadowsocks等等。这篇论文的主要贡献如下：提出了针对数据流类型（TCP）的完全加密协议（FEP）的安全性定义，与现有的安全性定义[1]进行了比较，并构建了一个可证明安全的数据流FEP。同样提出并分析了数据报类型（UDP）FEP的安全性定义，并构建了一个可证明安全的数据报FEP。对现有的多种FEP进行了评估，发现了新的识别特征，包括由错误引发的通道关闭行为和最小消息长度。这些发现为现有协议的改进和未来设计提供了参考。作者为FEP的安全性提供了理论基础，提出了具体的安全目标，并分析了现有协议的优缺点，揭示了它们可能被识别的方式。2、数据流安全概念本节将作者提出的新的数据流安全概念与Fischlin等人提出的数据流安全概念[1]进行了对比。因前者是后者的基础，所以介绍前者所用篇幅较大。图中方框与实线部分是Fischlin等人[1]提出的安全性概念：IND-CPFA (Indistinguishability under Chosen Plaintext Fragment Attack): 在选择明文片段攻击下的不可区分性，攻击者可以选择一系列明文片段，并观察其对应的密文。确保加密方案对于任何选择的明文片段，攻击者无法通过观察密文来区分两组不同的明文片段。IND-CCFA (Indistinguishability under Chosen Ciphertext Fragment Attack): 在选择密文片段攻击下的不可区分性，攻击者不仅可以选择明文片段并观察其对应的密文，还可以对已加密的密文片段进行修改，并观察报错协议信息。保障加密方案在面对主动攻击（包括密文的修改和插入）时，攻击者无法区分两组明文片段的加密结果。INT-PST (Integrity of Plaintext): 明文的完整性，保证明文流的完整性，确保接收端输出的明文流与发送端输入的明文流一致。若攻击者修改了信道中的数据或插入了新数据，接收端应能检测到，并将其视为攻击。攻击者无法通过操控密文来实现明文的插入、修改或伪造。INT-CST (Integrity of Ciphertext): 密文的完整性，只要密文片段经过篡改、伪造或以其他方式被攻击者操控，接收端必须能检测到这些问题，并拒绝篡改后的密文流，而不是尝试解密并输出潜在的明文内容。ERR-PRED (Predictability of Error Symbols): 错误符号的可预测性，目标是限制攻击者通过发送恶意密文片段来“探测”协议的行为。它要求接收算法（Recv）在处理错误密文时，输出的错误符号必须是攻击者可以预测的，而不是暴露额外信息或让攻击者利用协议的错误处理机制进行推测。其中，INT-CST能推出INT-PST，这显而易见（Trivial）。ERR-PRED、INT-CST和IND-CPFA能推出IND-CCFA。因为ERR-PRED（错误可预测性）确保接收端对异常密文的错误处理是可预测的。这防止攻击者利用错误消息行为获得密文或协议的元数据信息。INT-CST（密文流完整性）防止攻击者通过篡改或伪造密文片段来欺骗接收端输出伪造的明文。这确保接收端只会处理合法密文，防止攻击者对解密结果进行干扰。IND-CPFA（明文片段选择性攻击下的不可区分性）确保被动攻击者无法通过观察密文区分明文内容。这为 IND-CCFA 的被动部分提供了基础。图中椭圆与虚线部分是本文提出的新的安全性概念：FEP-CPFA (FEP security against a chosen plaintext fragment attack):确保在被动攻击下，完全加密协议的密文对明文片段不可区分，同时隐藏明文内容和元数据（如长度）。FEP-CCFA (FEP security against a chosen ciphertext fragment attack):确保在主动攻击下，完全加密协议的密文对明文片段不可区分，并防止通过篡改密文获取任何信息。IND-CPFA-CL:确保带关闭操作的信道在明文片段选择性攻击下，密文对明文不可区分，即关闭行为不会泄露信息。CH-REG (Datastream Channel Length Regularity):保证信道生成的密文长度与明文内容无关，以防止通过密文长度泄露明文信息。ERR-FREE:确保接收端在处理异常密文时不生成带内错误消息，避免通过错误行为泄露信息。相应的推导关系已经在图中详细展示，所以不再赘述。重要的是，作者推出，FEP-CPFA 和传统机密性定义（ IND-CPFA 和 IND-CCFA）之间并非互相包含，特别是元数据泄露可能破坏 FEP-CPFA 的要求。Fischlin等人提出的AEAD (Authenticated Encryption with Associated Data)虽然满足标准机密性定义，但如果使用未加密的长度字段标记密文块边界，仍违反 FEP-CPFA 的要求（因为元数据泄露）。3、数据流完全加密协议作者在Shadowsocks的基础上，设计了一个满足所有安全性需求的完全加密协议。相较于Shadowsocks来说，具体改进点如下：增强元数据保护：引入固定长度的“长度块”和包含填充字段的“负载块”分块机制，支持流量整形（Traffic Shaping），消除明文长度泄露风险，有效防御流量分析攻击。更严格的安全机制：采用失败状态（Fail State）取代带内错误消息，发生错误时不再发送错误信息，防止错误反馈泄露信息。通用性和灵活性提升：设计通用的缓冲和填充机制，适配其他完全加密协议（如 obfs4 和 InterMAC），并支持基于超时的连接关闭策略，增强抗分析能力和协议适应性。该协议满足正确性（Correctness）、流量整形（Traffic Shaping）、信道长度规则性（CH-REG）、被动和主动机密性（FEP-CPFA/FEP-CCFA）及密文流完整性（INT-CST）等所有安全要求。4、数据报完全加密协议数据报安全概念与数据流安全概念的证明类似，所以对于数据报，我们主要关注与数据流不同的地方。数据流（Datastream）与数据报（Datagram）的主要区别在于传输方式和特性：数据流以连续的字节流传输，消息可能被分片或合并，接收端需解析边界，通常提供顺序性和可靠性保障（如 TCP）；数据报则以独立完整的消息原子传输，无需分片或合并，消息边界明确，但可能乱序或丢失，不保证可靠性（如 UDP）。在 Correctness 中，数据流模型假设消息按顺序传输，关注确保顺序正确并恢复消息，而数据报模型要求每个消息在发送和接收后能够正确恢复，并处理可能的错误（如消息过大、输出长度不适等），而不依赖于消息顺序。在 Traffic Shaping 中，数据流模型比较灵活，不强制要求每次输出的密文长度与请求的长度完全匹配，而数据报模型要求输出的密文长度严格与请求的长度一致，并允许通过设置参数关闭流量整形。针对数据报，作者同样设计了一个满足所有安全性需求的完全加密协议，主要改进点如下：增强随机性和安全性：该构造基于 AEAD 加密方案，通过随机数（nonce）前缀和明确的消息编码方案，实现消息长度控制以支持流量整形（Traffic Shaping），避免泄露消息大小或协议元数据。无状态设计：协议设计为无状态，每次调用返回新的对称密钥，简化了状态管理并提升了适配性。该协议同样满足正确性（Correctness）、流量整形（Traffic Shaping）、FEP-CCA、INT-CTXT和IND-CCA.等所有安全要求。5、现有完全加密协议分析作者分析了一些试图在传输层之上实现完全加密的开源协议，以评估其是否符合本文的安全定义，以及它们在多大程度上具有本文的安全定义所要解决的识别特性（即泄露的某些元数据）。安全性分析结果如下：几乎所有现有的FEP协议都满足被动FEP安全性，即确保协议在被动攻击下能够防止元数据通过密文泄露；但没有数据流协议完全满足主动FEP安全性，即确保协议在面对篡改或恶意插入等主动攻击时依然能够防止元数据通过密文泄露，通常涉及如何处理连接关闭和错误处理。现有的协议，无论是数据流还是数据报，都不满足流量整形（Traffic Shaping），所有协议都可以通过其最小消息长度来识别。6、总结本文给出了FEP的安全定义和证明，提出了新的安全定义，涵盖了FEP的元数据保护目标，适用于数据流和数据报模型（TCP和UDP），并且证明了这些新概念与现有安全定义之间的关系，并展示了新的FEP构造及其安全性。此外，作者还调查了现有的FEP候选协议，分析了它们在满足FEP安全性方面的程度，并识别了这些协议在响应数据错误和最小消息大小方面的可识别性。一个安全的FEP，要能够防止主动攻击下的元数据泄露。References[1] Fischlin, Marc, et al. "Data is a stream: Security of stream-based channels." Advances in Cryptology--CRYPTO 2015: 35th Annual Cryptology Conference, Santa Barbara, CA, USA, August 16-20, 2015, Proceedings, Part II 35. Springer Berlin Heidelberg, 2015.