01 · 协议版本采用率:两张底图的拼合
1.1 连接侧:Modern TLS合计已达93.9%
连接侧数据显示,TLS 1.3以71.71%的份额成为绝对主流,QUIC内TLS约占22%,两者合计93.91%;TLS 1.2降至6.07%。版本迁移的第一阶段——"让Modern TLS成为默认"——已基本完成,检测工程的主战场随之从"版本识别"转向"版本协商行为与实现指纹"。
1.2 站点侧:SSL Pulse交叉验证
Qualys SSL Pulse对全球Top 15万站点的周期性主动扫描显示:截至2025年6月,约75.3%的站点已支持TLS 1.3;ISOC Pulse对全球头部站点(Top 1000)的多源汇总进一步显示,TLS 1.3支持率已达88%。连接侧份额(71.71%)与站点侧支持率(75.3%)高度吻合——两个独立视角互相印证,构成本课题"双视角交叉验证"原则的范例,也显著提升了对该指标置信度的评估。
口径警示:连接份额≠站点支持率。CDN集中化使头部平台在连接侧权重极高——Holz等(ACM CCR 2020)对TLS 1.3部署的追踪表明,早期部署由大型平台与CDN显著驱动。解读任何"份额"类指标前,必须先问三个问题:谁量的、量的是什么集合、统计周期是什么。
1.3 长尾的6%:不可忽视的残余风险
TLS 1.2剩余的6.07%连接、约四分之一的HTTP/1.x流量,集中于长尾——老旧IoT设备、遗留企业系统、区域性服务。这一长尾恰是钓鱼与C2基础设施的"伪装富矿":攻击者的信道越像"老设备的正常流量",越不容易触发版本类告警。因此版本检测规则必须配合行为特征联合判定,而非单独依赖"版本过旧"标签——这正是tls-analysis子课题所述"L2流级统计为主战场"的现实依据。
02 · 证书生态:PKI的互联网级体检
2.1 四个测量问题
证书是TLS信任链的载体,也是反钓鱼情报含金量最高的字段之一。互联网级证书测量系统回答四个问题:
| 测量问题 | 指标举例 | 安全含义 |
|---|---|---|
| 谁在签发? | CA市场份额、新签发证书量排名 | 识别可被滥用的自动化签发通道 |
| 活多久? | 有效期分布、短周期证书占比 | 免费CA短证书是低成本钓鱼工具 |
| 配错没有? | 链完整率、错配率、自签名比例 | 配置质量即被攻击面 |
| 吊销有效吗? | CRL/OCSP覆盖率、软失败比例 | 吊销失效意味着"事后止损"失灵 |
2.2 配置质量的历史水位
Holz等(IMC 2011)对SSL Landscape的首次大规模体检发现:相当比例的HTTPS站点存在弱哈希算法、过期或自签名证书、信任链不完整等配置缺陷。VanderSloot等(IMC 2016)将视角扩展到完整证书链,揭示了大量"叶证书正确、中端/根证书错配"的隐性失败——浏览器的自动补链掩盖了这些错误,但严格校验的自动化客户端会直接握手失败。工程启示:证书质量测量必须看链,不能只看叶证书。密钥生成质量同样是体检不可省略的一环:Heninger等(USENIX Security 2012,《Mining Your Ps and Qs》)发现大量网络设备因随机数生成缺陷共享相同的RSA素因子,可被批量分解;Hastings等(IMC 2016)证实弱密钥问题在网络设备中仍然普遍。配置缺陷并非历史问题,而是持续存在的水位线。
2.3 证书透明度生态:反钓鱼最锋利的公开数据之刃
RFC 6962定义的证书透明度(CT)机制要求CA将签发的每张证书提交至公共日志。Scheitle等(IMC 2018,《The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem》)系统刻画了CT生态的崛起:自2018年4月起,Chrome要求所有公开信任的证书必须携带合规SCT才能被信任,CT从"可选项"变为PKI的强制执行机制。Li等(CCS 2019)对CT监视器可靠性的测量表明,主流监视器已能稳定覆盖合格日志流——这意味着仿冒域名申请证书的分钟级时间内即被公开记录,为证书级威胁情报提供了低成本、全量化的"广播源"。CT子课题(ct-monitoring)正是建立在这一基础设施之上。
2.4 吊销机制的现实约束
证书"过期"与证书"被吊销"是两个不同问题:前者是生命周期终点,后者是信任紧急撤回。传统CRL/OCSP在大规模部署下面临性能与隐私双重瓶颈,浏览器普遍采用软失败(soft-fail)策略,导致吊销的实际效力长期受限。CRLite(Larisch等,IEEE S&P 2017)以布隆过滤器与增量更新实现了全量吊销数据的压缩推送,代表了"让吊销真正生效"的工程方向。DigiNotar事件后,Holz等(IMC 2017,《Mission accomplished? HTTPS Security after DigiNotar》)对HTTPS生态的追踪显示,重大信任危机能够加速生态整改,但长尾站点的修复速度远慢于头部——信任危机的恢复同样服从"头部先行、长尾滞后"的集中化规律。检测工程含义:不要把OCSP响应状态作为IoC可靠性的判断依据;证书是否可信,应结合CT记录、签发CA信誉与域名行为综合判定。
2.5 CA市场结构与免费CA革命
证书生态过去十年最深刻的变化,是免费域验证(DV)证书的规模化:Let's Encrypt自2015年运营以来以ACME协议实现签发全流程自动化,把证书获取成本降至接近于零。2020年2月27日官方宣布累计签发了第10亿张证书。安全收益是真实的——HTTPS加密化进程被极大加速;安全代价同样真实:
- 钓鱼成本同步归零:据The SSL Store基于Censys公开证书语料的分析(Vincent Lynch,2017年3月),2016年3月至2017年2月间Let's Encrypt共签发15,270张含"PayPal"字样的证书,随机抽样1,000张人工核验显示96.7%(14,766张)被用于钓鱼——免费、自动化的签发通道对攻击者与防御者完全等距开放。
- 身份验证等级下沉:免费证书集中于DV层级(仅验证域名控制权,不验证组织身份),钓鱼站点与正规站点在证书"类型"上趋于一致,识别压力全部转移到域名行为与基础设施关联层面。
- 短证书与自动化轮换:90天有效期倒逼自动化运维,也产生了海量CT条目;ISRG于2025年1月宣布推出6天短证书与IP地址证书选项,2025年7月签出首张IP地址证书,2026年1月15日起正式向所有订户开放——证书生命周期将进一步压缩,静态IoC的有效期同步缩短,情报消费端必须按"天"而非"月"设计更新节奏。
2.6 证书有效期政策演进
证书有效期是被政策与标准持续压缩的变量,直接影响CT管道的吞吐设计与IoC生命周期管理:
| 时间节点 | 政策事件 |
|---|---|
| 2015年4月 | CA/Browser Forum投票将OV/EV证书最长有效期由5年逐步压缩(Baseline Requirements演进的一部分) |
| 2018年3月 | CA/B Forum将公开发信信任服务器证书最长有效期统一压缩至825天 |
| 2018年4月 | Chrome强制执行CT:所有公开信任证书必须携带合规SCT,否则不予信任 |
| 2020年9月 | Apple宣布新签发公开信任TLS证书最长有效期不得超过398天(13个月),此后成为行业事实标准 |
| 2025年4月 | CA/B Forum通过SC-081v3投票(苹果提案,29票赞成、0票反对、5票弃权,2025年4月11日截止,2025年5月21日生效):398天→2026年3月15日起200天→2027年3月15日起100天→2029年3月15日起47天;域名控制验证(DCV)证据复用期同步压缩,2029年起仅10天 |
测量含义:证书轮换频率将持续翻倍级提升,CT管道日增条目规模相应扩大;以"证书SHA256"为唯一主键的检测规则需要加入时间衰减因子——同一基础设施的证书更换后,基础设施级关联(IP、ASN、JA4指纹、SAN命名风格)比证书哈希本身更稳定。
03 · HTTPS拦截中间件的互联网规模测量
3.1 什么是HTTPS拦截
企业安全代理、上网行为管理网关、防病毒软件与部分"省流浏览器",通过在客户端植入本地CA根证书,对TLS连接实施"中间人解密—检查—再加密转发"。拦截本身在授权管理场景下合法且必要(如企业合规审计、家长控制、恶意软件检查),但其安全性完全取决于代理方的TLS实现质量——而这一点恰恰是历史上最薄弱的环节。
3.2 互联网规模的拦截测量:NDSS 2017联合研究
Durumeric等(NDSS 2017)与Google、Mozilla、Cloudflare联合开展了迄今最权威的拦截测量。识别原理极为精巧:浏览器宣称的握手参数与服务器实际观察到的握手参数之间的失配,即为拦截存在的证据;进一步比对拦截后握手的特征,可反推出具体拦截产品。研究覆盖Cloudflare CDN全网流量、Firefox更新服务器与多个电商站点的观测点。
| 观测点 | 拦截测量结论 |
|---|---|
| 综合观测点 | 各观测点HTTPS连接被拦截的比例分布在约4%—10%区间(不同观测点差异显著,与访问场景和用户群构成强相关) |
| Firefox更新服务 | 被拦截连接中约97%的安全性被削弱 |
| Cloudflare全网流量 | 被拦截连接中约54%的安全性被削弱 |
| 电商站点(直连为主) | 被拦截连接中约32%的安全性被削弱 |
依据:Durumeric et al., NDSS 2017, DOI: 10.14722/ndss.2017.23456。该研究同时发现:受测拦截产品中仅Blue Coat(现Symantec/Broadcom产品线)一款获得与浏览器直连相当的安全评级;10%—40%的被拦截连接甚至宣称支持已知可破解的密码套件;基于网络侧中间盒的连接情况更糟——62%安全性被削弱,58%存在可被后续中间人攻击的严重缺陷。
更早的客户端侧分析(de Carnavalet与Mannan,NDSS 2016,《Killed by Proxy》)已得出同类结论:广泛部署的拦截软件普遍削弱终端TLS安全性。两项研究共同确立了一个反直觉事实:以"增强安全"名义部署的拦截设施,历史上恰恰是大规模引入TLS弱化的主要来源之一。
3.3 拦截测量对检测工程的三个含义
- 企业代理指纹必须入库标注:JA4指纹库中应设"代理型指纹族"标签,否则正常的企业内网流量会持续触发C2类告警,造成告警疲劳。
- 版本协商异常是拦截迹象:拦截代理往往"卡"在新协议上(如早期代理无法处理TLS 1.3直接断连),客户端反复回退重试的模式本身即构成可检测行为特征。
- 检测产品必须声明拦截环境表现:评估任何流量检测方案时,应追问其在企业代理、防病毒网关改写后的指纹稳定性,避免上线即失效。
运营建议:拦截≠恶意,但削弱安全的拦截是真实风险面。企业应每季度审计自身SSL拦截网关的配置质量,以SSL Labs A/A+评级作为验收线;对无法达标的老旧代理设备,应优先升级而非继续放行——NDSS 2017的数据表明,"不合格的拦截"比"不拦截"更危险。
04 · 威胁基础设施测绘:恶意也上TLS
4.1 钓鱼站点已全面"挂锁"
APWG成员机构PhishLabs的季度威胁趋势报告显示,启用SSL/TLS的钓鱼网站占比经历了陡峭爬升:2016年第三季度仅约2.5%(PhishLabs跟踪起点),2020年第一季度升至约74%,2020年第三季度达约80%(APWG季度趋势报告援引PhishLabs CTO John LaCour:"80%的钓鱼网站启用了SSL加密,比例甚至高于Web整体水平"),2021年第一季度稳定在约83%、首次进入平台期;APWG 2020年第三季度报告所附53,189张钓鱼证书样本中,91.3%为域名验证型(DV)、8.6%为OV、仅0.1%为EV。几乎同一时期,Felt等(USENIX Security 2017)对Web HTTPS采用率的互联网级测量显示,合法Web的加密化在同步高速推进。两个趋势叠加意味着一个对安全教育至关重要的结论:钓鱼与正常站点在"协议外观"上已不可区分——"有小锁=安全"的认知必须被证伪,识别必须下沉到证书行为、域名形态与基础设施关联层面。
4.2 恶意基础设施的证书侧信道特征
- 自签名与短生命周期批量证书:自动化搭建的钓鱼与C2站点倾向使用自签证书或极短有效期证书,降低被吊销后的损失。
- 免费CA签发流水线滥用:免费证书极大降低了钓鱼成本,同一主体短期内批量申请相似域名证书的模式在CT日志中清晰可聚类。
- SAN滥用与同形字符域名:一张证书承载大量相似域名、利用国际化域名同形字符仿冒品牌——与本专题"域名抢注/拼写错误"子课题直接联动。
- 基础设施聚集:恶意站点倾向于聚集于少数廉价托管商与bulletproof ASN,IP/ASN维度聚类可显著提升信噪比。
4.3 钓鱼基础设施测绘流水线(JS绘制)
4.4 与迪妙反钓鱼业务的闭环
测绘流水线产出的结构化情报(仿冒域名、恶意证书SHA256、C2指纹)注入四个消费端:CT监控子课题的持续监测名单、反钓鱼预警与识别指南的内容更新、攻防演练剧本的真实样本库、数据可视化中心的威胁态势看板。测量不是终点,情报的"最后一公里"送达一线才是——这也是迪妙"研究—演练—培训"三位一体业务模型的运转方式。
分工说明:本子课题负责"测绘方法与基础设施层数据";ct-monitoring负责CT日志的实时管道与告警;tls-fingerprinting负责JA4指纹的采集、比对与社区协作;website-fingerprinting负责流量侧的网站身份推断。四者共享实体库,避免重复建设。
05 · 被低估的测量维度:IPv6与邮件侧加密
5.1 IPv6:另一半互联网的加密化
大多数TLS生态统计以IPv4为中心叙述,但IPv6流量份额已在近年跨过关键节点:Google的IPv6采用统计(基于其全球服务访问量)显示,2026年3月28日IPv6流量占比首次突破50%(50.10%);APNIC测得具备IPv6能力的网络占比约43%,Cloudflare统计的请求侧占比约40%,ISOC Pulse多源汇总均值约44%——不同口径下IPv6都已成为"半壁江山"。对测量科学的含义有三:①双栈站点在两个协议栈上的证书与配置可能不一致,单栈测量会系统性漏检;②IPv6地址空间不可穷尽,全量扫描在计算上不可行,必须以域名引导的目标集测量与目标集生成服务(如OpenINTEL、Tranco解析、IPv6 Hitlist Service)替代地址枚举;③第1页所述三重选择偏差在IPv6下被进一步放大——会主动启用IPv6的站点与用户,本就与IPv4长尾不是同一批主体。
5.2 邮件侧加密:STARTTLS的明文回退陷阱
Web并非TLS的唯一战场。Holz等(NDSS 2016,《TLS in the Wild》)对互联网级电子邮件加密部署的测量揭示了一个长期被忽视的弱点:SMTP的STARTTLS采用机会性加密(opportunistic TLS),协商失败即回退明文,且大量MX服务器证书配置无效(自签名、域名不匹配),严格校验反而导致投递失败——邮件生态因此长期停留在"名义加密、实际宽容"的状态。对比之下,Web侧因浏览器强制校验而快速收敛。对迪妙业务的启示:钓鱼邮件的识别不能只看网页落地页,传输层的STARTTLS缺失与证书无效同样是可疑信号,但同样存在大量合法例外(老旧企业邮服),须以行为特征联合判定,与第2页拦截测量"拦截≠恶意"的纪律一致。
口径提醒:本节Google IPv6数据为Google服务体系所见的访问份额,ISOC Pulse为多来源汇总——两者均非"全网IPv6占比",引用时必须连同口径一起转述,避免"以偏概全"式误读(这正是1.2节口径警示的IPv6版)。
本节参考文献(第2页 · [1]—[15])
Durumeric Z., Ma Z., Springall D., Barnes R., Sullivan N., Bursztein E., Bailey M., Halderman J.A., Paxson V. "The Security Impact of HTTPS Interception", NDSS, 2017. doi.org/10.14722/ndss.2017.23456
de Carnavalet X., Mannan M. "Killed by Proxy: Analyzing Client-end TLS Interception Software", NDSS, 2016. doi.org/10.14722/ndss.2016.23374
VanderSloot B., Amann J., Bernhard M., Durumeric Z., Bailey M., Halderman J.A. "Towards a Complete View of the Certificate Ecosystem", ACM IMC, 2016.
Li B., Lin J., Li F., Wang Q., Li Q., Jing J., Wang C. "Certificate Transparency in the Wild: Exploring the Reliability of Monitors", ACM CCS, 2019, pp.2505-2520. dl.acm.org/doi/10.1145/3319535.3345653
Laurie B., Langley A., Kasper E. "Certificate Transparency", RFC 6962, IETF, 2013. rfc-editor.org/rfc/rfc6962
Larisch J., Choffnes D., Levin D., Maggs B.M., Mislove A., Wilson C. "CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers", IEEE Symposium on Security and Privacy, 2017.
Felt A.P., Barnes R., King A., Palmer C., Bentzel C., Tabriz P. "Measuring HTTPS Adoption on the Web", USENIX Security Symposium, 2017. usenix.org/.../felt
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
Cloudflare Radar(2026年Q2协议统计):radar.cloudflare.com;Qualys SSL Labs SSL Pulse:ssllabs.com/ssl-pulse;SSLMate CT Statistics:sslmate.com/labs/ct
APWG / PhishLabs. "Phishing Activity Trends Report Q3 2020"(钓鱼网站SSL启用率与证书类型分布): docs.apwg.org/reports/apwg_trends_report_q3_2020.pdf;APWG 2021年Q1趋势报告新闻稿(83%进入平台期): newswire.com/.../apwg-q1-2021-report...;The SSL Store钓鱼统计综述(2019年Q2约54% → Q3约68% → Q4约74%): thesslstore.com/blog/phishing-statistics...;The SSL Store. "Let's Encrypt Has Issued Certificates to Over 14,000 PayPal Phishing Sites", 2017-03: thesslstore.com/blog/lets-encrypt-phishing
Scheitle Q., Chung T., Häberle M., Gasser O., Bowen D., Burke E., Yates B., Shulman H., Waidner M. "The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem", ACM IMC, 2018.
Holz R., Rieck K., Schwenk J. "TLS in the Wild: An Internet-wide Analysis of TLS-based Protocols for Electronic Communication", NDSS, 2016.
Holz R., Amann J., Mehani O., Wessels D., van Rijswijk-Deij R. "Mission Accomplished? HTTPS Security after DigiNotar", ACM IMC, 2017.
Heninger N., Durumeric Z., Wustrow E., Halderman J.A. "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", 21st USENIX Security Symposium, 2012; Google IPv6 Statistics: google.com/intl/en/ipv6/statistics.html; Internet Society Pulse. "18 Years Later, IPv6 Reaches Majority", 2026-04: pulse.internetsociety.org/en/blog/2026/04/18-years-later-ipv6-reaches-majority; Let's Encrypt "We've Issued Our First IP Address Certificate"(2025-07-01,含6天短证书政策说明): letsencrypt.org/2025/07/01/issuing-our-first-ip-address-certificate;Let's Encrypt "Let's Encrypt Has Issued a Billion Certificates"(2020-02-27): letsencrypt.org/2020/02/27/one-billion-certs
Rescorla E. RFC 9846 "The Transport Layer Security (TLS) Protocol Version 1.3", IETF, July 2026(取代RFC 8446,TLS 1.3新基准规范): rfc-editor.org/info/rfc9846;Stebila D., Fluhrer S., Gueron S. RFC 9954 "Hybrid Key Exchange in TLS 1.3", July 2026: rfc-editor.org/info/rfc9954;RFC 9849 "TLS Encrypted Client Hello", 2026: rfc-editor.org/info/rfc9849