Loading... # LiteSSL ACME DNS-01 鉴权漏洞技术分析 # 一、事件概述 ## 1. 事件背景 2026 年 1 月，用户 00oo00 在 V2EX 社区披露了 LiteSSL ACME 服务存在严重的鉴权漏洞，该漏洞允许攻击者盗签他人已通过 DNS-01 验证的泛域名证书。LiteSSL 是 TrustAsia（亚洲诚信）推出的免费 ACME 证书服务。 ## 2. 影响范围 ### A. 影响用户数 初步排查涉及 100 多张证书 ### B. 影响时长 从服务上线至漏洞披露，持续数月 ### C. 影响功能 所有通过 DNS-01 方式验证的域名证书（包括泛域名证书和普通域名证书） ## 3. 严重程度 P1 级安全漏洞（CA 信任体系核心问题） # 二、漏洞原理 ## 1. 直接原因 LiteSSL 的 DNS-01 challenges 验证缓存机制存在两个关键缺陷： - 验证缓存有效期过长（30 天） - 未验证签发请求是否来自同一 ACME 账户 ## 2. 根本原因分析 ```mermaid graph TD A[攻击者发现目标域名] --> B[查询证书透明度日志] B --> C[找到目标域名的过往证书记录] C --> D[使用自己的 ACME 账户申请相同域名] D --> E{服务器检查缓存} E -->|缓存有效 30天| F[跳过 DNS 验证] E -->|缓存失效| G[要求 DNS 验证] F --> H[成功签发证书] G --> I[验证失败] ```  ## 3. 技术细节 ### A. 正常 ACME DNS-01 验证流程 ```mermaid sequenceDiagram participant C as ACME 客户端 participant S as ACME 服务器 participant D as DNS 服务器 C->>S: 请求域名授权 S->>C: 返回 DNS-01 挑战 C->>D: 更新 TXT 记录 C->>S: 通知验证就绪 S->>D: 查询 TXT 记录 D-->>S: 返回验证记录 S->>C: 验证通过，授权状态 VALID ```  ### B. 漏洞利用流程 ```mermaid sequenceDiagram participant A1 as 攻击者 A (原账户) participant S as ACME 服务器 participant D as DNS 服务器 participant A2 as 攻击者 B (新账户) A1->>S: 申请 example.com 证书 S->>D: DNS-01 验证 D-->>S: 验证成功 S-->>A1: 签发证书 Note over S: 缓存验证结果 30 天 A2->>S: 使用新账户申请 example.com S->>S: 检查缓存 Note over S: 找到有效缓存<br/>未检查账户一致性 S-->>A2: 直接签发证书 ```  ### C. IP 获取问题 除核心鉴权漏洞外，还存在辅助问题： - 速率限制基于错误获取的内网 IP（10.254.14.70） - 将反向代理服务器的内网 IP 当做客户端 IP # 三、厂商响应 ## 1. 应急响应时间线 | 时间 | 事件 | |------|------| | T+0 | V2EX 帖子发布，漏洞披露 | | T+2h | TrustAsia 官方回应，关闭证书签发接口 | | T+4h | 定位问题，开始吊销错误签发的证书 | | T+12h | 完成受影响证书吊销（100+ 张） | | T+24h | Mozilla Bugzilla 报告发布 | | T+36h | 问题修复，根因分析同步 | ## 2. 处理措施 ### A. 立即措施 1. 关闭 LiteSSL 证书签发接口 2. 将所有 ACME 授权域名状态从 VALID 重置为 REVOKED 3. 吊销所有受影响的证书（遵循 CAB/F 24 小时要求） ### B. 根本修复 - 修复 DNS-01 验证缓存的账户隔离问题 - 缩短验证缓存有效期 - 修复 IP 获取逻辑 ### C. 透明披露 - 在 Mozilla Bugzilla 发布初步报告 - 在 V2EX 原帖持续更新处理进展 - 计划后续发布根因分析 # 四、技术深度分析 ## 1. 漏洞本质 ### A. EAB 绑定问题 - LiteSSL 使用 EAB（External Account Binding）标识账户 - 验证缓存与 EAB 绑定，但未校验请求账户与缓存账户的一致性 - 导致任何账户都可以利用其他账户的验证缓存 ### B. 缓存策略缺陷 - 30 天的缓存有效期远超行业标准 - Let's Encrypt 通常为 30 天，但配合账户隔离机制 - 长有效期扩大了攻击窗口 ## 2. 实际攻击场景 ### A. 攻击前提 - 目标域名必须曾在 LiteSSL 签发过证书 - 目标域名使用 DNS-01 方式验证 - 验证缓存仍在有效期内 ### B. 攻击限制 - 无法用于任意域名（必须有过往签发记录） - 无法获取原证书的私钥 - 需要配合其他攻击手段（如 DNS 劫持）才能实现中间人攻击 ## 3. 与历史事件对比 | 事件 | CA | 问题 | 后果 | |------|-------|------|------| | DigiNotar (2011) | DigiNotar | 恶意签发伪造证书 | CA 破产，根证书被吊销 | | StartCom (2016) | StartCom | 签发流程不规范 | 被 Chrome/Firefox 移除信任 | | TrustAsia (2026) | TrustAsia | ACME 验证缓存隔离失效 | 主动披露，快速修复 | # 五、安全影响评估 ## 1. 直接影响 ### A. 受影响证书类型 - 仅影响通过 ACME 协议签发的免费证书 - 商业证书和 API 签发的证书不受影响 - 主要影响使用 DNS-01 验证的域名 ### B. 攻击者能做什么 - 为他人域名申请新证书 - 证书私钥由攻击者控制 - 可用于搭建钓鱼网站 - 配合 DNS 劫持可实现中间人攻击 ### C. 攻击者不能做什么 - 无法获取原证书的私钥 - 无法吊销他人的合法证书 - 无法影响未在 LiteSSL 签发过的域名 ## 2. 间接影响 ### A. 信任体系冲击 - CA 的核心职责是确保签发证书的鉴权准确性 - 此漏洞违反了 CA/Browser Forum 基线要求 - 可能影响 TrustAsia 的品牌信誉 ### B. 生态影响 - 用户对免费 ACME 服务的信任度下降 - 引发对其他 CA 类似问题的担忧 - 强调了证书透明度（CT）日志的重要性 # 六、经验总结 ## 1. 厂商做得好的地方 ### A. 响应及时 - 收到通知后 2 小时内关闭服务 - 24 小时内完成证书吊销 - 积极与社区沟通 ### B. 处理透明 - 在原贴持续更新进展 - 主动披露 Mozilla Bugzilla 报告 - 承认问题，不推诿责任 ### C. 修复彻底 - 从审慎角度，重置所有授权状态 - 计划发布详细根因分析 - 考虑建立 SRC 安全响应中心 ## 2. 需要改进的地方 ### A. 设计缺陷 - 缓存机制未考虑账户隔离 - 缓存有效期设置过长 - IP 获取逻辑存在基础错误 ### B. 测试不足 - 此类基础鉴权问题应在测试阶段发现 - 缺少安全审计和渗透测试 - 未充分考虑 ACME 协议的安全边界 ### C. 监控缺失 - 缺少异常签发行为监控 - 没有证书透明度日志的自动监控告警 ## 3. 行业启示 ### A. CA 运营教训 - 免费服务和付费服务需同等安全标准 - ACME 协议实现需严格遵循 RFC 规范 - 信任是 CA 的核心资产，一旦破坏难以恢复 ### B. 安全开发建议 - 鉴权系统需进行威胁建模 - 缓存机制必须考虑权限边界 - 多层防御：缓存隔离 + 速率限制 + 异常检测 ### C. 社区监督价值 - 白帽子披露对生态安全至关重要 - 透明的漏洞披露流程有助于建立信任 - 社区反馈渠道的有效性（邮件、在线客服） # 七、技术建议 ## 1. 对用户 ### A. 立即行动 - 检查是否使用 LiteSSL 签发的证书 - 如受影响，按 TrustAsia 指引重新申请证书 - 监控证书透明度日志，检测异常签发 ### B. 长期措施 - 启用证书透明度监控（如 Cloudflare CT Monitor） - 使用信誉良好的 CA（Let's Encrypt、DigiCert 等） - 定期审查证书来源和有效期 ## 2. 对 CA 运营者 ### A. ACME 实现建议 - 严格按照 RFC 8555 实现鉴权逻辑 - 验证缓存必须与账户强绑定 - 缩短缓存有效期或实现即时失效机制 ### B. 安全加固 ```mermaid graph LR A[ACME 请求] --> B{账户验证} B -->|失败| C[拒绝请求] B -->|成功| D{缓存检查} D -->|命中且账户匹配| E{缓存时效} D -->|未命中或账户不匹配| F[强制 DNS 验证] E -->|有效| G[使用缓存] E -->|失效| F F --> H[更新缓存] H --> I[签发证书] G --> I ```  ### C. 监控告警 - 监控同一域名的多账户签发行为 - 异常证书签发行为告警 - 定期审计证书透明度日志 ## 3. 对 ACME 客户端开发者 ### A. 安全最佳实践 - 为每个用户使用独立的 EAB - 避免共享 EAB 给多用户使用 - 实现 ARI（ACME Renewal Information）特性 ### B. 集成建议 - 优先支持直连 ACME 模式 - 如需代理模式，确保严格的账户隔离 - 支持证书自动更新和吊销 # 八、相关技术标准 ## 1. ACME 协议规范 - RFC 8555：ACME 协议定义 - RFC 8737：ACME 账户绑定外部账户 - RFC 8738：批量证书申请 ## 2. CA/Browser Forum 基线要求 - 版本 1.8.0：域名验证要求 - 证书透明度要求 - 密钥泄露响应要求 ## 3. 证书透明度（CT） - RFC 6962：证书透明度协议 - 所有公开信任的证书必须录入 CT 日志 - 用户可通过 crt.sh 等服务查询证书记录 *** ## 参考资料 1. [V2EX 原帖：LiteSSL 鉴权漏洞 可随意盗签他人泛域名证书](https://www.v2ex.com/t/1187331) 2. [Mozilla Bugzilla 报告：TrustAsia LiteSSL Security Incident](https://bugzilla.mozilla.org/show_bug.cgi?id=2011713) 3. [RFC 8555: ACME Protocol](https://datatracker.ietf.org/doc/html/rfc8555) 4. [证书透明度日志查询](https://crt.sh/?CN=%25&iCAID=438132) 最后修改：2026 年 01 月 22 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏