01 · 研究定位:为什么"测量"是检测科学的地基
1.1 检测的本质是"偏离检测",而偏离需要基线
加密流量探测的每一个检测结论——"这条流的包长序列偏离正常模型""这个JA4指纹属于已知C2框架""这张证书的签发行为异常"——其逻辑内核都是同一句话:与"正常"相比,它偏离了多少。因此,"正常"的定义必须先于检测器存在。在互联网尺度上,"正常"不是RFC文档中的静态描述,而是数十亿主机、数亿站点持续演化形成的动态分布,只能用持续测量来刻画。
互联网规模TLS生态测量(Internet-Scale TLS Ecosystem Measurement)正是绘制这张"底图"的学科:它以互联网级扫描与全球被动观测为手段,定量回答四个根本问题——谁在用哪个协议版本、配置质量处于什么水位、有多少连接被中间人改写、威胁基础设施如何隐藏其中。没有这张底图,检测规则没有校准的标尺,威胁情报没有可信的参照系,演练沙盘没有真实的数据水位。
1.2 对迪妙业务的三重直接价值
- 反钓鱼与反诈骗:仿冒域名注册、证书申请、C2托管构成钓鱼攻击的"基础设施指纹"。CT日志使恶意证书在签发瞬间即被公开记录,互联网级测量让钓鱼站点在"挂锁"的同时进入监测视野。
- 攻防演练:演练沙盘的指纹库、证书样本、目标环境越接近真实互联网的分布形态,演练结果越能外推到生产防御。测量数据是演练仿真度的上限。
- 安全培训:课程中的每一个数字都应有出处、有统计周期、有口径说明。测量科学为教学提供可信的数据底座——这也是迪妙"来源分级、证据三分、时效标注"方法论原则的落地。
1.3 与专题内其他子课题的接口
本课题是"加密流量探测"专题的"底图与标尺"子课题:tls-analysis提供协议语义与可见性分析;tls-fingerprinting与ct-monitoring消费本课题产出的指纹库与CT情报;mitm-detection消费本课题的拦截测量结论;website-fingerprinting与ebpf-detection依赖本课题设定的基线数据。一句话概括分工:其他子课题研究"怎么测",本课题研究"测得准不准、正常长什么样"。
02 · 测量方法论:主动扫描与被动观测两大范式
2.1 两种范式的互补关系
获取互联网尺度数据的途径可归为两类:主动测量(研究者主动向目标发送探测报文并观察响应)与被动观测(研究者旁观真实流量并统计)。二者不是替代关系,而是互为校验的两个视角——本课题的全部指标均要求至少两个视角交叉验证。
| 维度 | 主动测量 | 被动观测 |
|---|---|---|
| 数据视角 | 第一人称视角:亲手完成TLS/HTTP握手,记录协商结果 | 旁观者视角:统计真实用户与服务器间发生的连接 |
| 覆盖能力 | 可指定任意目标集(全IPv4、Tranco Top百万、自有资产) | 仅限于观测点可见的流量(平台网络、探头网络) |
| 成本结构 | 扫描带宽与时长可控,边际成本低 | 依赖平台数据开放政策,存在断供风险 |
| 典型盲区 | 过滤探测报文的主机、地理与运营商偏差、扫描时间窗偏差 | 观测点视野偏差:平台用户结构不代表全网 |
| 伦理敏感度 | 高:需授权边界、速率节制与黑名单机制 | 低:多为公开聚合统计 |
| 代表平台 | ZMap / ZGrab2 / Censys / SSL Pulse | Cloudflare Radar / Chrome UX Report / CT日志 |
2.2 互联网级主动测量的技术底座
主动测量的工程前提是"扫描整个IPv4空间足够便宜"。ZMap(Durumeric等,USENIX Security 2013)以无状态探测与内核旁路实现了这一前提:不维护每目标状态机,只根据收到的响应报文反推探测目标,从而在1 Gbps链路上以约45分钟完成全部约43亿个IPv4地址的单端口扫描——比当时主流扫描器快两个数量级。后续的Zippier ZMap(WOOT 2014)通过并行化地址生成、改进黑名单算法与零拷贝网卡访问,把单端口全网扫描压缩到10 Gbps链路上不足5分钟。ZGrab2负责应用层:对存活主机完成TLS、HTTP、SSH等协议握手并结构化记录协商参数;Censys(Durumeric等,ACM CCS 2015)进一步将周期性扫描数据纳入搜索引擎架构,使"查询互联网"成为像查询数据库一样的基础设施操作。
测量的第一个方法论陷阱是"目标集定义":Bano等(ACM CCR 2018)系统比较了ICMP Echo、TCP SYN等不同探针的"活性"判定差异——不同探测方法识别出的"在线主机"集合并不相同。这意味着任何"全网有多少主机支持TLS 1.3"式的结论,都必须绑定探测方法与目标集版本才有意义。该发现直接塑造了迪妙测量流水线中的"目标集版本化"设计原则。
2.3 被动观测与公开权威数据源
- Cloudflare Radar:全球连接侧视角,按日更新协议版本、HTTP版本、后量子(PQC)采用率等指标;口径为Cloudflare全球网络所见的流量份额。
- Google Transparency Report / Chrome UX Report:浏览器侧HTTPS采用率与真实用户体验侧(CrUX)的加密化指标。
- Qualys SSL Pulse:面向全球Top 15万站点的周期性主动扫描体检,提供TLS版本支持率、配置评级分布等站点侧指标。
- SSLMate CT Statistics:证书透明度(CT)生态的日志数量、日增条目与累计规模统计。
本课题的方法论铁律:同一指标至少由两个独立视角交叉验证。例如TLS 1.3份额同时引用连接侧(Radar)与站点侧(SSL Pulse)数据,并显式标注两者的口径差异(详见第2页)。
2.4 纵向追踪:测量"变化"而非"快照"
单次扫描只能给出快照,安全演化的判断需要纵向数据。Kotzias等(IMC 2018)在《Coming of Age: A Longitudinal Study of TLS Deployment》中通过对固定目标集的多年追踪,刻画了HTTPS部署从"少数大厂配置"到"普遍默认开启"的成熟曲线,并揭示了证书生态向CA集中签发、自定义证书持续消退的结构性变化。Holz等(ACM CCR 2020)进一步聚焦TLS 1.3:其早期部署高度由大型平台与CDN驱动,呈现明显的集中化(centralization)特征——这一发现提醒所有检测工程师:协议演进的速度从来不由长尾决定,而由头部平台决定;预测"何时可以放弃对旧版本的兼容检测",应盯头部而非盯平均。
2.5 标准演进对测量口径的影响(2026年更新)
2026年7月,IETF发布RFC 9846,作为TLS 1.3的新基准规范取代RFC 8446(2018):协议版本号保持不变、明确禁止协商TLS 1.0/1.1、收紧KeyUpdate机制要求,并为TLS 1.2实现追加新的安全要求;同期,混合后量子密钥交换(X25519MLKEM768)在RFC 9954中标准化,加密客户端问候(ECH)在RFC 9849中标准化。对测量的含义有三:①指纹库与协商特征库的基准文档编号需同步更新;②混合密钥协商将成为ClientHello的新常态维度,JA4类指纹需评估其对key_share列表变化的表达能力;③ECH普及将进一步压缩被动观测可见的明文字段,目标归因更依赖CT与DNS侧信道——这是tls-analysis子课题的重点议题。
03 · 全球公共测量基础设施图谱
本课题的数据并非全部来自自建扫描:国际学术与运营社区已经沉淀出一套可复用的公共测量基础设施。了解它们的覆盖范围、数据开放方式与口径特征,是"站在巨人肩膀上测量"的前提。下表仅收录本课题实际采用、且可持续访问的公共基础设施:
| 基础设施 | 类型 | 覆盖与数据形态 | 典型用途 |
|---|---|---|---|
| Censys | 主动扫描+搜索 | 周期性全网扫描(IPv4/域名/证书),提供查询API与快照下载 | 协议版本与证书字段的大样本基线 |
| OpenINTEL | 主动DNS测量 | 每日对全球主要TLD区域的域名做全量DNS测量(A/AAAA/MX/HTTPS等记录),IMC 2016论文确立其平台设计 | 域名基础设施的日粒度纵向追踪 |
| IPv6 Hitlist Service | IPv6目标集生成服务 | 聚合域名列表、CT日志、RIPE Atlas、BGP路由等多源数据,经熵聚类去偏后生成大规模IPv6活跃地址列表,每日更新公开下载(方法学由Gasser等IMC 2018确立) | IPv6目标集构建与测量偏差校正 |
| RIPE Atlas | 分布式探针 | 由RIPE NCC运营的全球分布式测量网络,全球部署上万台硬件探针与锚点,用户可调度ping/traceroute/DNS测量 | 多 vantage point 的可达性与路径测量 |
| Cloudflare Radar | 平台被动观测 | Cloudflare全球网络流量的聚合统计,按日与按季度发布 | 连接侧协议份额、PQC采用率 |
| M-Lab | 分布式测量 | 开源的全球测量平台,主打网络性能(NDT等)与透明测量 | 链路质量背景变量、教学实验 |
| SSL Pulse / SSL Labs | 周期性主动扫描 | Qualys对全球Top 15万站点的每日扫描与评级 | 站点侧配置质量水位 |
| SSLMate CT | CT统计 | 证书透明度日志的规模、增长与CA签发统计 | 证书生态基线与体量估算 |
| ZMap工具链 / scans.io | 开源工具与数据归档 | ZMap/ZGrab2/ZDNS等开源工具,IMC/USENIX公开测量数据归档 | 授权环境下的复现测量 |
平台口径说明:OpenINTEL(Jonker等,IMC 2016)面向"域名集合"而非"地址集合"测量,天然适合证书透明度研究的域名侧验证;RIPE Atlas的优势在于"从何处看"可控,可规避单一扫描源的地理偏差(详见下节)。
中国本土视角的补充:上述公共基础设施的观测视角以欧美学术与运营商为主。迪妙测量流水线在消费国际公共数据的同时,以自有授权环境与本土榜单(如国内主流站点集合)构建平行目标集,避免"国际主流"被误读为"全网常态"——这一设计将在第3页"目标集治理"中展开。
04 · 测量的时间与空间稳定性
4.1 同一个互联网,不同时间测出不同结果
互联网地址的"活性"具有明显的日周期(diurnal)特征:大量地址随用户作息开机关机,扫描结果因此强烈依赖扫描时刻。Plonka与Berger(IMC 2015)对活跃IPv4地址的时空分类研究,以及Richter等(IMC 2016,《Beyond Counting》)进一步指出:约三分之一的"活动地址"与人口作息的日周期相关,且分类方法本身会改变结论。工程含义极为直接:两次不同时间窗的扫描结果不可直接比较;任何纵向对比必须先对齐扫描时间窗(如统一取UTC 02:00-06:00低谷段),否则"增长"可能只是"测量到了不同的人群"。
4.2 从何处扫描,决定了你能看见什么
Wan等(IMC 2020,《On the Origin of Scanning》)系统量化了扫描源位置的影响:同一个扫描器、同一个目标集,从不同地理位置、不同运营商出口发起,返回的响应集合存在系统性差异——其定量结论是:单一扫描源平均遗漏1.6%–8.4%的HTTP主机、1.5%–4.6%的HTTPS主机与8.3%–18.2%的SSH主机,约半数目的AS中任意两观测点的覆盖率差异超过1%,两个多样性足够的观测点可将覆盖提升至约98%——地理过滤(geoblocking)、运营商级过滤与响应率差异常被误读为"互联网本身的状态"。该研究与2.1节的探测方法偏差、目标集偏差共同构成测量的三重选择偏差:方法、目标集、观测点。
迪妙执行标准:①固定扫描时间窗与时间戳格式,跨期对比前强制校验;②关键指标至少双观测点复测(RIPE Atlas多探针或双地理位置扫描源);③在每次测量发布物中公开扫描源位置、时间窗与目标集版本——三者缺一,数据不发布。
4.3 测量的"观察者效应"
主动扫描本身会成为被测系统的输入:Durumeric等(USENIX Security 2014,《An Internet-Wide View of Internet-Wide Scanning》)发现互联网上的扫描行为本身已成为常态背景流量,安全设备对扫描的告警与处置会反过来影响后续测量(例如被测主机在多次探测后启用限速或封锁)。这要求测量方以低频、节流、可识别的方式设计探测,并在分析中显式排除因前次扫描触发的防御性响应。
05 · 测量伦理与合规框架
5.1 Menlo Report:网络测量的伦理共识
大规模扫描天然触碰"对他人网络施加探测行为"的边界。美国国土安全部2012年发布的The Menlo Report将人体研究伦理框架(贝尔蒙报告)移植到信息与通信技术研究领域,确立四项原则:尊重个人(respect for persons)、行善(beneficence)、公正(justice)、尊重法律与公共利益(respect for law and public interest)。在网络测量社区,这四项原则已沉淀为可操作的工程惯例,ZMap等项目从设计之初即内置了对应机制。
5.2 工程化伦理清单(迪妙执行标准)
- 必要性与相称性:探测范围严格限定于研究问题所需,不做"顺手全端口、全协议扫描";扫描速率控制在不对目标造成可感知负担的区间。
- 目标节制:避开医疗、工控、应急等敏感端口与协议;尊重IANA特殊用途地址段与业界维护的扫描黑名单(ZMap原生支持黑名单文件与速率节制参数)。
- 数据最小化:只记录协议握手元数据(版本、套件、证书、扩展),不请求、不触碰任何应用层私有内容。
- 可退出机制:发布测量主体身份与联系方式,支持目标方通过黑名单退出后续测量。
- 负责任披露:发现高危脆弱配置时遵循"先通知责任方、后公开"的协同披露流程——《The Matter of Heartbleed》(IMC 2014)对OpenSSL漏洞修复行为的大规模测量,即是"测量服务于修复"的学术典范。
5.3 中国法域下的合规边界
在中国法域内,主动扫描必须严格限定于自有授权资产与明确许可的测试范围;对他人网络实施高频探测可能触及《网络安全法》关于不得干扰网络正常功能的禁止性规定;测量数据的发布须符合《数据安全法》与《个人信息保护法》的最小化要求——能不收集的不收集、能聚合的不留存明细、发布形态尽量统计化。
合规声明:迪妙网络空间安全学院的全部测量活动仅针对自有授权环境与公开数据源(CT日志、公开统计平台、学术公开数据集)开展;本页所述扫描方法论仅用于教育与研究目的,不构成对他人网络实施主动测试的任何授权或许可。任何组织与个人在应用相关方法前,应自行确保获得充分法律授权。
06 · 指标体系与迪妙测量流水线
6.1 六维测量坐标系
为避免"看到什么测什么"的碎片化,本课题将全部测量指标归入六个正交维度,每个维度绑定明确的指标定义与数据源:
| 测量维度 | 核心指标 | 典型数据源 |
|---|---|---|
| 活性与可达性 | 在线主机比例、443端口开放率、双栈(IPv4/IPv6)支持率 | ZMap(授权环境)/ 自有资产测绘 |
| 协议版本 | TLS 1.3/1.2/1.0-1.1份额、QUIC占比、HTTP/2与HTTP/3份额 | Cloudflare Radar / SSL Pulse |
| 密码与密钥强度 | 套件分布、弱密钥检出率、前向保密覆盖率 | ZGrab2握手记录 / SSL Labs评级 |
| 证书质量 | 有效期分布、链完整率、自签名比例、CA市场集中度 | CT日志 / SSL Pulse |
| 拦截迹象 | 连接被中间人拦截的比例、拦截产品的安全性评级 | NDSS类联合测量 / 企业侧遥测 |
| 威胁基础设施 | 仿冒证书密度、C2指纹族规模、恶意托管集中度 | CT / 被动DNS / JA4DB |
6.2 迪妙测量流水线(JS绘制)
6.3 可复现性三原则
公开工具(ZMap/ZGrab2等开源工具链,扫描代码可审计)、公开目标集(Tranco等学术维护榜单,版本快照留档)、公开时间戳(所有指标绑定统计周期、采集时刻与观测点)。本课题拒绝引用任何"来源不可查、口径不可复现"的数字——这一原则与专题首页所述"来源分级、证据三分、时效标注"方法论一一对应。
本课题全部图表由原生JavaScript Canvas引擎绘制(donut/bar/line/hbar/timeline/flow/framework七类图元),不依赖任何外部图表服务,可离线审阅与复用;每张图下方注明数据来源与统计周期,并与参考文献编号一一对应。
本节参考文献(第1页 · [1]—[17])
Durumeric Z., Wustrow E., Halderman J.A. "ZMap: Fast Internet-Wide Scanning and Its Security Applications", 22nd USENIX Security Symposium, 2013, pp.605-620. usenix.org/.../durumeric_zakir
Durumeric Z., Adrian D., Mirian A., et al. "A Search Engine Backed by Internet-Wide Scanning", 22nd ACM SIGSAC Conference on Computer and Communications Security (CCS), 2015, pp.542-553.(Censys) dl.acm.org/doi/10.1145/2810103.2813703
Holz R., Braun L., Kammenhuber N., Carle G. "The SSL Landscape: A Thorough Analysis of the X.509 PKI Using Active and Passive Measurements", ACM IMC, 2011. dl.acm.org/doi/10.1145/2068816.2068856
Kotzias P., Razaghpanah A., Amann J., Paterson K.G., Vallina-Rodriguez N., Caballero J. "Coming of Age: A Longitudinal Study of TLS Deployment", ACM IMC, 2018. dl.acm.org/doi/10.1145/3278532.3278568
Holz R., Hiller J., Amann J., Razaghpanah A., Jost T., Vallina-Rodriguez N., Hohlfeld O. "Tracking the Deployment of TLS 1.3 on the Web: A Story of Experimentation and Centralization", ACM SIGCOMM Computer Communication Review (CCR) 50(3), 2020, pp.3-15. dl.acm.org/doi/10.1145/3411740.3411742
U.S. Department of Homeland Security. "The Menlo Report: Ethical Principles Guiding Information and Communication Technology Research", 2012.
Durumeric Z., Kasten J., Adrian D., et al. "The Matter of Heartbleed", ACM IMC, 2014.
Bano S., Richter P., Javed M., Sundaresan S., Durumeric Z., Murdoch S.J., Mortier R., Paxson V. "Scanning the Internet for Liveness", ACM SIGCOMM Computer Communication Review (CCR) 48(2), 2018, pp.2-9. dl.acm.org/doi/10.1145/3213232.3213234
Hastings M., Fried J., Heninger N. "Weak Keys Remain Widespread in Network Devices", ACM IMC, 2016. dl.acm.org/doi/10.1145/2987443.2987486
Langley A., Riddoch A., Wilk A., et al. "The QUIC Transport Protocol: Design and Internet-Scale Deployment", ACM SIGCOMM, 2017. dl.acm.org/doi/10.1145/3098822.3098842
Adrian D., Durumeric Z., Singh G., Halderman J.A. "Zippier ZMap: Internet-Wide Scanning at 10 Gbps", 8th USENIX Workshop on Offensive Technologies (WOOT), 2014. usenix.org/.../woot14/.../adrian
Durumeric Z., Bailey M., Halderman J.A. "An Internet-Wide View of Internet-Wide Scanning", 23rd USENIX Security Symposium, 2014.
Jonker M., Sperotto A., van Rijswijk-Deij R., Pras A. "OpenINTEL: A Collaborative Measurements Platform to Support Internet Research", ACM IMC, 2016.
Plonka P., Berger A. "Temporal and Spatial Classification of Active IPv4 Addresses", ACM IMC, 2015; Richter P., Allman M., Bush R., Paxson V. "Beyond Counting: New Perspectives on the Active IPv4 Address Space", ACM IMC, 2016.
Wan G., Izhikevich L., Adrian D., Yoshioka K., Holz R., Rossow C., Durumeric Z. "On the Origin of Scanning: The Impact of Location on Internet-Wide Scans", ACM IMC 2020, pp.662-679. doi.org/10.1145/3419394.3424214
Gasser O., Scheitle Q., Foremski P., et al. "Clusters in the Expanse: Understanding and Unbiasing IPv6 Hitlists", ACM IMC, 2018;IPv6 Hitlist Service(每日更新的公开IPv6活跃地址列表与别名前缀): ipv6hitlist.github.io
Rescorla E. "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, IETF, July 2026(取代RFC 8446): rfc-editor.org/info/rfc9846;Stebila D., Fluhrer S., Gueron S. "Hybrid Key Exchange in TLS 1.3", RFC 9954, July 2026: rfc-editor.org/info/rfc9954;"TLS Encrypted Client Hello", RFC 9849, 2026: rfc-editor.org/info/rfc9849