traffic-audit

name	traffic-audit
description	修改多路复用、填充机制、传输层、隧道转发代码后触发。

Skill: 流量统计分析防御审计

在修改涉及多路复用、填充、传输层、隧道转发代码后，必须对变更部分执行以下审计清单。审查系统通过宏观统计特征（熵值、包长、时间间隔、流量进出比、连接模式）训练机器学习模型来识别代理流量。

审查系统的检测原理

审查系统在宏观层面运行多维度统计分类器，核心逻辑不是"找代理特征"而是"判定流量是否像正常 Web 浏览"：

1. 熵值分类：计算 TLS 记录的字节 popcount（每字节中 1 的位数）。若平均值落在 3.4-4.6 之间（近似纯随机），且不匹配已知 TLS/HTTP 握手特征、不以明文协议豁免，则判定为未知加密协议并阻断。关键洞察：纯随机本身就是异常信号 — 正常 HTTPS 流量由于 TLS 记录头、HTTP 帧结构等明文字段的存在，熵值并不完美均匀。
2. ML 包长/间隔分类：提取连接前 N 个包的长度序列和间隔时间向量，用机器学习（随机森林、SVM）分类。关键特征包括：上行包均值、下行包方差、心跳包占比、IAT 平均值。
3. 首包指纹：握手后第一个应用层包的长度和格式是高信息量特征。固定长度的认证字段 + 地址字段构成可训练的特征向量。
4. 宏观行为画像：IP 级别的流量进出比、并发连接数、连接建立频率。代理节点与普通网站的流量模式截然不同。
5. 多会话关联分析：审查系统不只看单个连接，而是关联同一客户端 IP 到同一服务器 IP 的所有连接模式。正常浏览行为是间歇性的（浏览 → 阅读 → 浏览），代理行为是持续性的（长时间稳定数据流）。多个短连接按时间排列构成的"连接节奏"也是分类特征。
6. 时间维度特征：审查系统会提取流量在一天中的时间分布模式。正常用户有明显的昼夜规律，而代理流量通常全天均匀分布。
7. DNS 关联：审查系统不仅分析 TLS 流量，还会关联同一客户端 IP 的 DNS 查询模式。大量查询未知/新注册域名后立即连接特定 IP，这个 DNS→TLS 关联模式本身就是代理特征。
8. 历史行为基线：审查系统为每个 IP 建立历史行为基线。如果某个 IP 的流量模式突然从"正常浏览"转变为"长连接代理模式"，基线偏移会触发告警。
9. 流水印关联：审查系统可在 ISP 层面主动向客户端出口流量注入可识别模式（时序间隔、包长调制），然后在服务器入口流量中检测同一模式，从而在不解密的情况下建立客户端-服务器关联。
10. 网站指纹（WF）攻击：审查系统仅通过观察客户端出口流量的包长/方向序列，即可高精度推断用户正在访问的网站。2024-2025 年的最新攻击（DF、Tik-Tok、Triplet）在封闭世界条件下准确率达 97-99%，开放世界条件下达 92-95%。迁移学习使得在 Tor 上训练的模型可直接迁移到其他协议，准确率仅下降 5-10%。

触发条件

• 修改了多路复用协议代码
• 修改了填充机制代码
• 修改了传输层读写行为
• 修改了隧道双向转发逻辑
• 修改了加密封装逻辑
• 修改了帧大小、缓冲区大小相关配置
• 修改了连接管理、并发控制相关配置
• 修改了 keepalive / 心跳机制
• 修改了写入合并 / 缓冲策略

审计清单

1. 熵值分布审计

审查系统的熵值分类器不是在寻找"高熵"，而是在寻找"纯随机"模式。防御目标是让流量不呈现纯随机特征，而非让熵更高。

检查项	说明
防御目标明确	理解检测目标：审查系统检测的是"纯随机"模式，防御不是让熵更高，而是让流量不呈现纯随机特征。正常 HTTPS 流量由于 TLS 记录头、HTTP 帧结构等明文字段的存在，熵值并不完美均匀
滑动窗口标准差检测	审查系统使用滑动窗口计算逐字节 popcount 的标准差。窗口内每字节的 popcount（0-8 中 1 的位数）的标准差 < 0.8 则判定为"过于均匀"（纯随机特征）。必须确保加密后的流量中保留足够的结构性字节使得 popcount 标准差 > 0.8
检测窗口范围	审查系统主要检测 TLS 记录的前 8-16 字节（5 字节 TLS 记录头 + 前几个密文字节）。TLS 记录头的 content_type（0x17）、legacy_version（0x03 0x03）等固定字节本身就是结构性来源，加密后这部分结构被覆盖
已知协议豁免	审查系统对匹配已知协议头模板的流量会豁免放行。TLS 握手记录（content_type=0x16）、HTTP/2 帧头（"PRI * HTTP/2.0"）等已知模式不受纯随机检测约束。理解这个机制，但不要依赖它做防御
ASCII 内容豁免	审查系统对含有高比例可打印 ASCII 字符的流量会豁免放行（前 6 字节全为打印字符、前 50% 以上为 ASCII、或连续 20+ 可打印字符）。了解这个机制，但不要依赖它做防御
填充数据随机性	填充帧的填充数据必须使用密码学安全伪随机数生成器（CSPRNG）。全零填充使局部熵值骤降，与正常加密流量不一致
明文结构保留	加密后的记录是否保留了足够的明文结构（如 TLS 记录头、HTTP 帧边界）？过多的明文结构暴露协议特征，过少则触发纯随机检测。需要精确控制结构性与随机性的平衡
帧头规律性	多路复用帧头是否暴露了固定字节模式？固定字节模式会改变局部熵值分布，同时暴露多路复用协议特征

2. 包长分布（PLD）审计

包长是机器学习分类器信息量最高的特征维度。审查系统通过包长直方图、块对齐模式、首包长度来训练分类器。

检查项	说明
首包大小	连接建立后的第一个数据包大小是否与正常 TLS 流量一致？过小的首包（如仅含 UUID）或固定长度的首包是已知代理特征。首包大小必须在合理范围内随机波动
固定长度特征向量	首包中的固定长度认证字段 + 地址字段构成可训练的特征向量。ML 模型可以学习到"认证 hash 恒为 N 字节，其后紧跟 1 字节地址类型 + 可变长度地址"的模式。必须通过随机填充破坏这种固定长度模式
请求/响应非对称性	正常 Web 流量呈强非对称性（小请求大响应），代理隧道是双向对称转发。代理流量必须保持与正常 Web 一致的非对称分布，包括请求包的小尺寸和响应包的大尺寸特征
TLS-in-TLS 消除	是否避免了 TLS 嵌套导致的叠加握手包特征？TLS-in-TLS 的包长序列是独特的：客户端先发多个小包（ClientHello 等），服务端响应大包（Certificate 等），然后第二轮重复。这种双层握手序列可被统计分析检测
帧分片边界	多路复用的帧边界是否导致密文在特定块对齐上呈现可预测的长度模式？如果帧边界总是对齐到 16 字节块，密文长度总是 16 的倍数，这个规律性是统计可检测的
包长直方图	代理流量的包长直方图是否与正常 Web 浏览流量相似？正常 HTTPS 流量的包长集中在几个典型值（MTU 附近 ~1400 字节的大包、小请求包、ACK 级别的极小包）。高度碎片化的分布（大量 200-400 字节的中等包）是异常特征
块对齐特征	加密后的数据是否呈现明显的块对齐模式（如总是 16 字节的倍数）？真实 HTTPS 流量的 TLS 记录长度不受块对齐约束（TLS 1.3 内部填充是字节级而非块级的），16 字节对齐的密文长度本身就是异常
请求包大小分布	上行请求包的大小分布是否合理？正常浏览器请求（HTTP/2 HEADERS + DATA）集中在几百字节到 1-2 KB。如果代理上行包全是等长的固定大小包（转发 SOCKS5 请求），分布异常可被检测
WebSocket 帧大小模式	如果使用 WebSocket 传输，帧大小分布是否与正常 WebSocket 流量一致？代理隧道的 WebSocket 帧通常是固定大小或接近 MTU 的等长帧，正常 WebSocket 应用的帧大小分布更多样。应通过帧大小随机化打破固定模式

3. 包间隔时间（IAT）审计

IAT 序列是仅次于包长序列的第二高信息量特征。审查系统通过 IAT 分布训练分类器，检测隧道流量的机械性节律。

检查项	说明
keepalive 间隔规律性	keepalive 是否以固定间隔发送？固定间隔是机器学习模型的强特征。应添加随机抖动（jitter），抖动范围应覆盖基础间隔的 ±30-50%，使间隔分布接近正态
填充帧发送时机	填充帧是否与正常数据帧在时序上交错发送以混淆 IAT 分布？仅依赖周期性发送填充帧不够，填充帧的发送时机需与数据帧融合
突发模式模拟	正常浏览是"读 → 点击 → 突发加载 → 读"的节奏：长时间静默（阅读）后紧接着密集的包突发（页面加载），然后再次静默。代理流量的 IAT 序列应模拟这种突发模式，而非均匀分布。具体表现为：IAT 呈现双峰分布（长间隔 + 极短间隔），而非单峰分布
心跳包占比	心跳包在总包数中的占比是否异常高？高心跳占比（>20%）是隧道流量的典型特征。审查系统的 ML 模型会将心跳包占比作为分类特征。应通过减少心跳频率或用填充帧替代心跳来降低占比
IAT 平均值	ML 分类器会将 IAT 平均值作为特征。正常浏览流量的 IAT 平均值受页面加载模式影响（大量短间隔的突发 + 少量长间隔的阅读），代理流量如果 IAT 平均值过低（持续密集传输）或过高（长连接低活跃），都是异常特征
响应延迟分布	代理请求的响应延迟是否与直连 Web 服务器有明显差异？直连响应延迟通常在 10-100ms 范围，经过代理的响应会叠加额外延迟。如果所有响应都有固定的额外延迟（如 +50ms），这个时间偏移本身就是特征
空闲超时与连接断开	连接空闲后的超时断开时机是否一致？如果所有空闲连接都在精确的同一超时值后断开（如精确 300 秒），这个固定超时值是连接持续时间分布中的异常尖峰

4. 首包特征审计

握手后第一个应用层数据包是信息量最高的单一包。审查系统的 ML 模型特别关注首包的长度和结构。

检查项	说明
固定长度模式破坏	首包是否为固定长度（如总是 56 字节）？固定长度本身就是高信息量特征。应通过随机填充使首包长度在合理范围内（如 64-512 字节）波动。填充长度从足够大的范围随机选择，使得 ML 模型无法从长度推断认证字段边界
字段边界混淆	首包内部是否有明显的字段分界（如密码 hash + 目标地址）？即使加密后，固定偏移处的字节分布也可能被统计提取。应在字段之间插入随机长度的填充来模糊边界，或将认证信息分散到多个包中
填充长度范围	填充长度是否从足够大的范围内随机选择？过小的范围（如 0-16 字节）不足以掩盖原始包长分布。推荐范围至少覆盖认证字段大小的 50-200%，使得填充后的总长度分布充分分散
多路复用掩护	是否可以通过多路复用将认证信息分散到多个帧中，而非集中在单个首包？将认证拆分为多个帧并在帧之间插入填充帧，可以彻底消除首包特征
首包与后续包的一致性	首包的填充策略是否与后续包一致？如果只有首包做了填充而后续包裸露，这种"有填充→无填充"的切换本身就是时序特征

5. 多路复用流量整形

多路复用将多个子流聚合到单一连接中，本身提供了连接级整形的天然优势，但实现不当会引入新的统计特征。

检查项	说明
并发连接聚合	多路复用是否将多个并发请求聚合到单一底层连接中？"单 IP 爆发式多连接"行为（同时建立 6-8 个 TCP 连接到同一服务器）本身就是翻墙特征。应通过多路复用减少并发连接数
流 ID 分配模式	stream_id 分配是否递增或有规律？可预测的 ID 分配（如总是从 1 递增）可能被统计分析。应在协议允许范围内随机分配流 ID，或使用难以预测的分配策略
帧交错模式	多个流的数据帧是否交错发送？顺序发送某一流的所有帧再发送下一流的帧，会在包长序列中暴露"块状"模式。应随机交错不同流的帧，使包长序列不呈现块状结构
连接复用模式	底层连接的生命周期和复用模式是否与正常浏览器行为一致？正常浏览器在访问同一网站时复用连接（HTTP/2 多路复用或 HTTP/1.1 keep-alive），且连接生命周期在几分钟到几十分钟。连接创建后立即满载或生命周期无限长都是异常
流权重/优先级	如果使用 HTTP/2 多路复用，流的权重和依赖关系是否与正常浏览器的分配一致？所有流权重相同是简化实现的标志。Chrome 对 CSS/JS 赋予比图片更高的优先级，这种优先级差异会影响帧的交错模式

6. 填充方案有效性

填充是流量整形的核心工具，但实现不当的填充本身会成为新的统计特征。

检查项	说明
首 N 包强制填充	填充方案是否对前 N 个包（高信息量握手包）进行强制填充？前 N 个包的信息量最高，应优先保护。推荐 N >= 3
填充长度随机化范围	填充长度是否从足够大的范围内随机选择？过小的范围（如 0-32 字节）不足以掩盖原始包长分布。推荐范围使填充后包长在 MTU 内均匀分布，或至少使填充长度标准差 > 原始包长标准差
零长度帧语义	当填充方案返回零长度时，是否跳过发送而非发送空帧？发送空帧（零载荷 TLS 记录）会在包长序列中产生 0 字节包，这本身就是异常特征。TLS 1.3 允许空 application_data 记录，但真实浏览器几乎从不发送
填充与数据帧时序融合	填充帧是否在时序上与正常数据帧融合？如果填充帧总是在数据帧之后立即发送（固定 data→padding 模式），填充本身就变成了新的可检测特征。应在随机时机发送填充帧，与数据帧无固定的先后关系
填充开销合理性	填充带来的额外流量开销是否合理？过高的填充比例（如流量翻倍以上）会在 IP 级别造成新的异常特征：流量进出比严重失衡、带宽消耗与连接数不匹配。推荐填充开销控制在总流量的 15-60%
填充停止条件	填充方案是否有合理的停止阈值？某些方案在发送 N 个包后停止填充。过小的停止值意味着后续包无填充保护，审查系统可以只分析 N+1 之后的包来绕过填充防御
填充分布不可区分	填充后的包长分布是否与无填充的正常流量不可区分？如果填充总是将包补齐到固定值（如总是 1400 字节），那么 1400 字节包的异常集中本身就是新特征。应使填充后的包长分布接近正常流量的自然分布
填充数据随机源	填充帧的填充数据必须使用 CSPRNG 生成。全零填充、固定模式填充、或使用非密码学 PRNG 生成的填充数据使局部熵值骤降，与正常加密流量不一致，反而成为新的检测特征

7. 宏观流量行为审计

宏观行为是 IP 级别的统计特征，即使单连接层面的协议伪装完美，宏观行为仍然会暴露代理服务器。

检查项	说明
流量进出比	代理节点的上下行流量比例是否与正常 Web 服务器一致？普通网站下行大上行少（用户下载网页，仅上传小请求）；代理节点可能呈现相反模式（用户上传请求，服务器下载响应后转发）。这是 IP 级别的宏观统计，即使协议伪装完美也会暴露
连接频率	单个 IP 到目标 IP 的连接建立频率是否异常？每秒上百次新建连接远超正常浏览器行为。正常浏览器对同一网站最多并发 6-8 个连接，每分钟新建连接数在个位数到几十
并发连接数	单个 IP 到同一目标的并发连接数是否过高？数百个长连接本身就是翻墙特征。正常浏览行为中，用户到单个网站的并发连接通常不超过 10-20 个
连接持续时间分布	代理连接的生命周期分布是否与正常浏览行为一致？正常浏览连接的生命周期呈对数正态分布（多数连接短，少数长），代理连接如果都持续很长时间（小时级），分布异常可被检测
24 小时流量分布	服务器 IP 的全天流量是否有明显的昼夜差异？正常网站有高峰低谷（如工作日白天高、凌晨低），全天均匀分布的流量模式是代理特征。流量应与部署地区的正常用户作息一致
流量峰值模式	正常网站的流量峰值与热门事件/时段相关（如新闻事件导致突发流量）。代理流量的峰值是否也呈现类似的"事件驱动"模式？无外部事件驱动的流量峰值是可疑的。理想情况下代理流量应被动跟随部署地区的整体网络流量趋势
上下行字节比	除了进出方向的连接/包数比，字节级进出比也是特征。正常 Web 服务器接收小请求发送大响应（下行:上行比约 5:1 到 20:1），代理服务器可能接近 1:1。字节级进出比偏离正常范围是强特征

8. 多会话关联分析防御

审查系统不只看单个连接，而是关联同一客户端 IP 到同一服务器 IP 的所有连接，提取跨连接的统计模式。

检查项	说明
连接节奏	同一客户端 IP 到服务器 IP 的多个连接在时间上是否构成间歇性的"浏览节奏"？连续不断的稳定连接流是代理特征。正常行为是"爆发多个连接 → 长时间静默（阅读）→ 再次爆发"，而非持续的均匀连接流
会话间间隔	正常用户浏览网页时，两次页面加载之间有阅读间隔（通常 10 秒到数分钟）。代理流量的会话间间隔是否模拟了这种自然间隔？如果所有连接等间隔排列（如每隔精确 30 秒一个新连接），间隔的规律性本身是特征
方向比一致性	多个连接的上行/下行比是否一致？如果每个连接都是 1:1 的对称流量，这本身就是异常特征（正常浏览是非对称的：大页面加载是下行主导，表单提交是上行主导）。不同连接的方向比应有自然差异
DNS→TLS 关联	审查系统会关联同一客户端 IP 的 DNS 查询和后续 TLS 连接。大量查询未知域名后立即连接特定 IP，这个 DNS→TLS 关联模式是代理特征。如果客户端直接使用 IP 连接而无对应 DNS 查询，"无 DNS 的 TLS 连接"也是异常。客户端应通过域名解析获得代理服务器 IP
SNI 多样性	正常用户访问多种不同网站（SNI 多样性高）。如果代理的所有连接都使用同一个 SNI（或极少数 SNI），SNI 单一性是异常特征。应通过合理的 SNI 轮换增加多样性
连接数量模式	正常浏览器的连接模式是"短时间内爆发多个连接 → 长时间静默 → 再次爆发"。代理的"稳定流"模式（均匀间隔的连接序列）与之不同。应在连接建立时模拟爆发模式

9. 流水印防御

审查系统可在 ISP 层面（无需解密）主动向流量注入可识别模式，然后在不同网络位置检测同一模式来建立客户端-服务器关联。

检查项	说明
间隔水印识别	审查系统可在 ISP 路由器层面人为延迟特定包，在流量中注入可识别的时序间隔模式。例如：在包序列中按预设的二进制编码模式（0=正常延迟、1=额外 50ms 延迟）插入延迟。检测方法：监控出口流量中是否存在异常的间隔模式（如周期性的 50ms 额外延迟），如果检测到则主动扰乱这些间隔
包长水印识别	审查系统可通过 ICMP 不可达或 TCP 窗口控制来人为截断特定包，改变包长序列。例如：将第 3、7、12 个包分别截断为特定长度，在包长序列中嵌入识别码。检测方法：监控出口流量中是否存在异常的截断模式（如不该被分片的大包被截断为非标准长度）
熵水印识别	审查系统可在客户端出口流量中注入可识别的数据模式（如特定长度的 HTTP 请求）。虽然加密后内容不可见，但包长变化仍可被检测。此类水印隐藏在加密之后，直接检测困难，但可通过填充和流量整形间接缓解
出口流量中和	是否在出口流量（客户端→服务器方向）检测并中和可疑的水印模式？如果检测到异常间隔/长度模式，应通过插入额外填充帧或延迟来扰乱水印模式，使其在到达服务器入口时不可识别
入口流量检测	是否在入口流量（服务器→客户端方向）也检测水印？攻击者可能在双向流量中都注入水印。双向检测可提高防御完整性
水印与填充协同	流水印防御应与填充方案协同工作：填充帧的随机插入本身就能扰乱间隔水印，填充长度的随机化本身就能扰乱包长水印。不应将两者视为独立机制

10. 网站指纹（WF）防御

网站指纹攻击仅通过观察客户端出口流量的包长/方向序列（不需要服务器端流量），即可推断用户正在访问的网站。

检查项	说明
攻击能力基线	了解最新攻击水平：2024-2025 年封闭世界条件下的攻击准确率已达 DF ~98%、Tik-Tok ~97.5%、Triplet ~99%。开放世界攻击也已成熟，准确率约 92-95%。任何防御方案都必须以此为基线评估有效性
迁移学习威胁	迁移学习攻击使得审查系统可以在 Tor 上训练 WF 模型然后直接应用于其他协议，准确率仅下降 5-10%。这意味着：即使代理协议与 Tor 完全不同，WF 攻击仍然有效。防御方案不能依赖"协议差异"作为保护。必须在包长序列和 IAT 序列两个维度上同时实施防御，因为迁移学习模型对这两个特征的迁移能力最强
特征重要性排序	包长序列 > IAT 序列 > 包方向序列。防御方案应优先针对包长序列（信息量最高的特征），其次是 IAT 序列。仅混淆方向序列的方案效果有限
Tamaraw 方案评估	Tamaraw 将所有包填充到固定大小并在包之间插入固定延迟，可将 DF 准确率从 98% 降至 ~40%。但开销极高（100%+ 带宽开销、200%+ 时间开销），实用性差。适用于对延迟不敏感的场景
FRONT 方案评估	FRONT 使用前端填充（在页面加载初始阶段注入大量填充包）策略，开销 40-60%，可将准确率降至 ~25%。在开销和防御效果之间取得较好平衡。适用于通用场景
自适应填充方案评估	自适应填充（Adaptive Padding）根据流量特征动态调整填充策略，开销 15-25%，可将准确率降至 ~35%。开销最低但防御效果也最弱。适用于带宽敏感的场景
对抗样本策略	研究表明仅 3-5 个精心放置的填充包就能将 DF 准确率从 98% 降至 30%。关键是在包长序列的"信息量最高"位置插入填充包（通常在页面加载的前 20 个包中）。对抗样本策略是开销最低的防御方式
填充位置优化	填充包应优先放置在页面加载的初始突发阶段（前 10-30 个包）。这些包的信息量最高（包含 HTML/CSS/JS 的初始加载），后续的图片等资源加载包信息量较低。在信息量最高的位置插入 3-5 个填充包比在随机位置插入 20 个更有效
防御组合策略	单一防御方案效果有限。推荐组合策略：自适应填充（包长层面）+ 随机延迟（IAT 层面）+ 突发模式模拟（宏观层面）。组合方案可以用较低的总开销实现较好的综合防御效果

11. 传输层行为合规性

传输层的底层行为（TCP 参数、缓冲策略）本身也会产生可检测的指纹。

检查项	说明
禁用 Nagle	是否启用了 TCP_NODELAY？Nagle 算法会将小包缓冲合并，导致包长分布中出现"应该小但实际大"的异常包。同时，Nagle 引入的 200ms 延迟会在 IAT 序列中产生周期性尖峰
写入合并策略	多次小写入是否合并为单次大写入？多次小写入会产生大量短包（每个 write 可能触发一次 TCP 发送）。应将多个小写入缓冲后一次性发送，使包长分布更接近正常 TLS 流量（大包为主）
读取缓冲区大小	读取缓冲区是否与正常 TLS 实现一致？过小的缓冲区（如 512 字节）会产生过多的短读取，在代理端产生大量小包的响应。正常 TLS 实现的读取缓冲区通常为 4-16 KB
partial write 循环	async_write_some 返回部分写入时，是否循环写入直到完成？静默丢弃未写入数据会导致连接状态不一致，同时也会导致实际发送的数据量与预期不符，影响包长分布
写入批量化	是否在应用层实现写入批量化（将多个逻辑写入合并为一个 TCP 写入）？如果没有批量写入，连续的小帧（如多路复用的多个小帧）会产生大量短 TCP 段，与正常 TLS 流量（少量大段）不一致

12. 辅助信道侧防御

检查项	说明
DNS 查询侧信道	代理客户端的 DNS 查询模式是否暴露代理行为？大量查询未知/新注册域名后立即连接特定 IP，DNS→TLS 关联模式本身是代理特征。如果客户端直接用 IP 连接而无对应 DNS 查询，"无 DNS 的 TLS 连接"也是异常。应确保 DNS 查询通过加密隧道或使用 DoH
OCSP 查询泄漏	代理连接的 OCSP 查询是否暴露目标域名？OCSP 查询以明文发送证书序列号到 CA 的 OCSP 服务器，审查系统可以监听 OCSP 查询来推断访问目标。应使用 OCSP Stapling 避免客户端发起独立 OCSP 查询
NTP 时间同步侧信道	时间戳防重放机制依赖精确时间，但频繁的 NTP 查询本身可被审查系统关联。应使用安全的 NTP 方案或本地时钟同步

交叉引用

• dpi-audit 覆盖了本 skill 未深入探讨的 TLS 指纹一致性、ALPN 协商状态机、TCP/IP 栈指纹维度
• leak-audit 覆盖了本 skill 未深入探讨的错误响应格式指纹、日志泄漏、部署规模追踪维度
• probe-audit 覆盖了本 skill 未深入探讨的回落机制形式化安全、跨协议探测防御、多阶段探针协调维度
• security-audit 提供了安全审计 skills 的编排指南，确定修改特定代码时应按何种顺序执行哪些审计

审计流程

1. 识别变更范围: 确定本次修改影响哪个传输层/多路复用协议/填充机制
2. 绘制数据流图: 从应用层写入到网络层发送，追踪数据经过的每一层，标注每层的长度变化
3. 标注长度特征点: 在每一层标记数据长度的变化（+header、+padding、+tag），计算最终网络包长度
4. 计算熵值: 对变更后的流量计算 TLS 记录前 8-16 字节的逐字节 popcount 滑动窗口标准差，验证 > 0.8
5. 分析包长直方图: 评估最终网络包的长度分布是否与正常 HTTPS 流量相似（集中在 MTU 附近、有自然的小包分布）
6. 检查时间模式: 评估 keepalive、padding 的发送间隔是否添加了足够的随机抖动
7. 评估宏观行为: 估算部署后的流量进出比、并发连接数、全天流量分布是否在合理范围内
8. 多会话关联模拟: 模拟多个连续连接的时间模式，评估是否构成可疑的"连接节奏"或缺乏 SNI 多样性
9. DNS 关联评估: 如果涉及客户端行为，评估 DNS→TLS 关联是否暴露代理模式
10. 流水印防御评估: 检查出口流量是否具备中和间隔/长度水印的能力
11. WF 防御评估: 在前 10-30 个包中插入 3-5 个填充包，评估对抗样本效果
12. 传输层合规检查: 确认 TCP_NODELAY、写入合并、读取缓冲区大小、partial write 处理是否合规

常见反模式（禁止）

// ❌ 固定间隔 keepalive — 机器学习模型可提取周期性特征
while (is_active())
{
    timer.expires_after(std::chrono::milliseconds(fixed_interval));
    co_await timer.async_wait(...);
    co_await push_frame(command::nop, 0, {});
}

// ✅ 带随机抖动的 keepalive（抖动范围覆盖基础间隔 ±30-50%）
while (is_active())
{
    auto jitter = random_in_range(-jitter_range, jitter_range);
    timer.expires_after(std::chrono::milliseconds(base_interval + jitter));
    co_await timer.async_wait(...);
    co_await push_frame(command::nop, 0, {});
}

// ❌ 零填充 — 全零字节使熵值骤降，与正常加密流量不一致
memory::vector<std::uint8_t> waste_data(size, 0);

// ✅ CSPRNG 随机填充 — 熵值与正常加密流量一致
memory::vector<std::uint8_t> waste_data(size);
csprng_fill(waste_data);  // 使用密码学安全随机数

// ❌ 固定长度首包 — ML 可提取的特征向量
co_await send(auth_hash + target_addr);

// ✅ 随机填充破坏固定模式（填充范围覆盖认证字段 50-200%）
auto padding_len = random_in_range(auth_size / 2, auth_size * 2);
co_await send(auth_hash + target_addr + csprng_bytes(padding_len));

// ❌ 填充帧总是在数据帧之后立即发送 — 固定 data→padding 模式变成新特征
co_await send_data(payload);
co_await send_padding(random_len);

// ✅ 填充帧的发送时机随机化
if (random_bool(padding_probability))
{
    co_await send_padding(random_len);
}
co_await send_data(payload);

// ❌ 填充后总是固定长度（如总是 1400 字节）— 固定长度集中是新异常
auto padded = pad_to_fixed_size(payload, 1400);

// ✅ 填充后包长分布在合理范围内随机波动
auto target_len = random_in_range(min_size, max_mtu);
auto padded = pad_to_nearest(payload, target_len);

// ❌ 客户端直接用 IP 连接 — 无 DNS 的 TLS 连接是异常
co_await connect(proxy_ip, 443);

// ✅ 通过域名解析获得 IP，审查系统看到的 DNS→TLS 关联更正常
auto ip = co_await resolve(cover_domain);
co_await connect(ip, 443);

// ❌ 所有连接使用同一 SNI — SNI 单一性是异常
// 连接 1: SNI = "example.com"
// 连接 2: SNI = "example.com"
// 连接 3: SNI = "example.com"

// ✅ SNI 轮换增加多样性
auto sni = select_from_sni_pool();  // 从多个合法域名中轮换
auto ip = co_await resolve(sni);
co_await connect(ip, 443);

// ❌ partial write 静默丢数据 — 包长分布异常 + 连接状态不一致
written = co_await opts.to->async_write_some(data, ec);

// ✅ partial write 循环直到完成
auto remaining = data;
while (!remaining.empty())
{
    written = co_await opts.to->async_write_some(remaining, ec);
    if (ec)
    {
        co_return;
    }
    remaining = remaining.subspan(written);
}

// ❌ 多次小写入产生大量短包 — 包长分布异常
for (auto& frame : frames)
{
    co_await transport.async_write_some(frame, ec);
}

// ✅ 批量合并写入
auto combined = coalesce_frames(frames);
co_await net::async_write(transport, net::buffer(combined), ec);

// ❌ 心跳包占比过高（>20%）— 隧道流量特征
// 每 5 秒发送心跳，即使空闲也发送

// ✅ 降低心跳频率或用填充帧替代心跳
// 心跳间隔与流量活跃度关联：空闲时长越长，心跳间隔越大

// ❌ 帧边界 16 字节对齐 — 块对齐是异常特征
auto frame_len = align_to_block(content_len, 16);

// ✅ 帧长度不做块对齐，使用自然长度
auto frame_len = content_len + header_size + padding_len;

// ❌ 忽视流水印防御 — 出口流量中的间隔/长度模式可被 ISP 层面关联
// 对异常间隔不做任何处理

// ✅ 出口流量中和水印模式
// 检测到异常间隔模式时，通过插入填充帧或随机延迟来扰乱水印
if (detect_suspicious_interval_pattern(outbound_traffic))
{
    co_await send_padding(csprng_random_len());
}