LiteSSL 鉴权漏洞 可随意盗签他人泛域名证书

这个 CA 有哪个浏览器信任么？

@6a82aa9bfe TrustAsia 亚洲诚信的根，绝大多数都信任

@6a82aa9bfe 他的证书的上一级是由 TrustAsia 签发的，所有应该绝大部分都信任

这个 bug 没修就发布的话可能会吃官司啊，至少发布前得先告知吧

都是草台班子

这么离谱的漏洞，这个 ca 估计要凉了

@codehz 这里从业者多，就放这吧

有哪个重要网站用这个 CA 吗？不行浏览器里直接把这个 CA 吊销信任了吧

@sduoduo233
@6a82aa9bfe 看了下 litessl.cn 官网底部挂的备案和公司全是亚洲诚信的，估计是子公司吧

@6a82aa9bfe 倒也没必要，毕竟是新 CA 提供 acme 提供免费的通配符证书，bug 修好就行

互联网基础设施的一部分居然如此草台班子么...

签一份 Google 的证书，这样会推动得比较快

我估计不是不验证账户，而是用相同 ip 做的验证，但因为获取了内部服务器的 ip ，导致直接过了，这个 CA 必被罚。

这太牛逼了 这正规付费的用户不裂开

TrustAsia 还是很多商业付费客户的啊

开个 Cloudflare 证书透明度监控还是很有用的，就算这种 CA 出问题了也能检测到其他人盗签证书

可以去 Hacker News 发个帖子，被这个影响到的证书应该需要吊销的，不知道范围有多大

@dnslint 认证审题，这是一家免费的 SSL 续发平台。
1 正规用户不再这里买
2 他这个漏洞是针对 已经在他们家平台 续签过证书的域名，并且这个最多就是鉴权漏洞
3 这个漏洞实际利用价值非常低，因为 OP 所谓的《偷》 也只是让这个平台重新颁发一张 SSL 罢了，你和正主在用的 key pem 都是不同的 没任何价值

@cccer 你拿了他的证书有什么用？ 难道你还能骗域名管理员把某某某解析 指定到你说的 IP 吗

这要吊销一大批了

性质恶劣，但因为用户不多，所以影响有限


......但性质有些过于恶劣了

@XDiLa 这是信任基础，你说的可太轻巧了，你知道这种事情如果往严重了说是会吊销 CA 的……

试了一下，他这个 ACME 要绑定账号，然后账号注册要短信实名的？小心喝茶。

感谢反馈，TrustAsia 这边收到通知后已立即采取措施：

1.已关闭 LiteSSL 证书签发接口；
2.目前问题已经定位，正在对错误签发的证书执行吊销措施；
3.研发团队正在紧急修复 Bug ，我们将争取尽快恢复服务。

后续有进展我们会在此同步更新。如发现有更多问题，也欢迎及时向 [email protected] 进行反馈。

目前调查反馈仅影响近期刚上线的由 ACME 提供的免费证书，商业证书和 API 提供的证书不受影响。

@00oo00 #7 目测发讨论没啥用。。不如找 Mozilla CA 开个 bugzilla ，他们有 CA 机构的联系方式

@myssl @00oo00 OP 应该也有使用我的免费 SSL 申请网站 cao.la 来测试，我检查了一下最近的提交申请记录确实存在这个域名的签发成功的记录

@XDiLa

这样说就太天真了

https://en.wikipedia.org/wiki/DigiNotar

这样的例子有很多

@caola 明确给出的域名已经完成吊销，其他可能存在跨账号隔离证书正在排查

@pingdog 我们（ TrustAsia ）正准备开 bugzilla 进行披露事件

@qwx #22 你都用免费的 SSL 证书服务器 还指望他们为你的安全负责？

@XDiLa #31 不负责就准备倒闭

@pingdog https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/EiuXvY3m_gU

@XDiLa 免费怎么了，LE 也是免费的啊，为啥不能为我的安全负责？

他这个不仅仅是影响免费用户了，对付费用户一样有影响。

@myssl 你们 SSL 在验证时很慢，同时多个域名申请时非常容易失败，4-5 个域名以上的基本都得重复提交几次申请才能把所有域名验证完成，都没有我网站写的订单确认验证提交前预检一次的快。

还有几时能支持 IP 地址签发。。

@busier https://grok.com/share/c2hhcmQtMw_c30be6e8-d9f1-4311-aab0-425b026cb635

@XDiLa #19 DNS 劫持相对来说很简单，再大一点的组织完全可以 bgp 劫持

开年第一草台班子

@busier 举个简单的例子，这网站就是给你颁发处 3 个月免费的阿里云范域名证书 你也实现不了中间人攻击 。所以你也别太天真了。多沉淀一下

@pingdog 看起来是有用的...... 这是某种舆情监控机制，还是说正好有员工在 v2ex

@XDiLa 我们实现不了中间人攻击不代表没人有实现不了。运营商在没有普及 ssl 的时候给网页加弹窗和广告没见过？有了 ssl 证书他们就可以干这个事。

@XDiLa #18 假如我有这个域名证书，理论上我可以作为中间人（可能是网络运营商、可能是附近 WIFI 网络提供者等等），通过此证书实现中间人数据监视，而用户端浏览器任然认为我使用此证书加密的流量是合法的，是不是有这个理论可能？

@qwx #42 你说的对！

@qwx #42 所以 运营商顶着这么大风险 做的意义是什么？ 大企业他不敢碰，小企业不出名 所以他这么做的意义是什么？

@XDiLa #31

找个 AI 问问把，不然我真当你是卖 SSL 证书的


参考 35#

@busier #46 我已经问过了。并且回复你了 希望你有空看下。 你发的 WIKI 我已经看过了

@myssl #30 不错，比某 sign 主动多了

@caola 是的，免费的 ACME 服务目前刚上线，还在优化中。我们商业版的 API 已经优化到 6 ～ 10秒左右，后续还能进一步提升 1 ～ 2 秒。

@caola 是的 litessl 信息太少了 搜来搜去就你家网站支持


@myssl 所以 litessl 是亚洲诚信完全所有吗？

@Kinnice 我们已经实施 MPIC 多视角验证，有 5 个以上远程视角，每个视角数据中心相隔 500KM 。MPIC 的出现很大程度上防止了 BGP 劫持。

@Kinnice #38 DNS 劫持也不容易，这个 DNS 验证一般 SSL 签发机构是直接查询去域名的 NS 服务器去查询，而不经过第三方的 DNS 递归查询

@caola LiteSSL 正在计划提供短效 IP 证书（需要 ACME 客户端支持 Profile 特性），之前没有提供是由于 IP 证书存在转移过于频繁，对安全生态不利。

@00oo00 是的，LiteSSL 是 TrustAsia 推出的免费公益项目，主要应对接下来证书有效期缩短带来的挑战，主推 ACME ，包括 ARI 、Profile 、长效验证等自动化有效的特性。

@XDiLa

WebPKI 是由信任驱动的。信任是 CA 以及浏览器厂商卖给你的东西。整个环节中对于这种信任的蓄意或者无意地破坏（故意签发没有正确鉴权的证书或因为系统故障/逻辑误签发等）对于利益相关方都是「信任」的重大打击，造成的是商誉的损失。

对于「免费证书」，CA/Browser Forum 和各利益相关方大体和付费 DV 证书采用相同的 baseline 标准。CA 为了被包括在 OS 、浏览器中，必须向社区证明自己满足这些要求（一个近期的例子是 [1]）。这当然是因为各实作对于 DV 证书「是否收费」并不做区分。考虑一个状况：我假扮 Google 骗 Let's Encrypt 和 Digicert 给我签发 google.com 的证书并用来干坏事，两者造成的伤害是相同的。

而此类「向不该签发证书的人签发了证书」的状况，正是这一系列社区标准中，被广泛认为应该负责的事情（作为用户，社区的一员，我个人感谢 @myssl 代表的 TrustAsia 的迅速行动）而不是「因为免费所以就完全不该负责」。

至于现实危害，正如你的 LLM 给你讲的那样，大规模的攻击需要更大层面的问题。但我如果控制了我的咖啡馆、酒店、机场的公共网络（甚至是 ISP ），用一些 DNS 劫持等等的手段，确实是能够影响到可观量的用户的。而「瑞士奶酪模型」教给我们的是要让事情不那么糟糕，我们可能除了多几片奶酪（ DNSSEC, RPKI etc ）之外，还需要让奶酪的洞稍微小一点。

此外关于现实危害，大家可能还记得就在不久的十多年前，HTTPS 还没有那么广泛部署的年代，ISP 们通过各种手段劫持下载、往页面上插广告的事情可在神州大地上广泛发生着。

[1] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/UdDqO6K4YpU

@XDiLa 40#

我说历史上有很多伪造证书中间人攻击的先例，并举例。在 26#

你跟我说我没有能力实现中间人攻击。在 40#

确实我没这个能力，妨碍别人有这个能力攻击吗？

小可爱！

@XDiLa #31 CA 的根本职能就是对其签发证书的安全性负责，硬要不负责也很简单，就是被浏览器拿掉。CA/B 里基本 B 说了算，CNNIC 的根证书一样说下就下掉了。

@XDiLa 48#

OP 在 2#说了什么 好好看下

你问 AI 的回答明显是忽视了 2#

搞信任背书的企业出现信任问题，有点太灾难了，这个 bug 搞不好从业务上线的第一天持续至今了。幸好这件事是 bug 披露的，如果是签了不该签的证书并利用，又被正主发现并曝光呢……

@XDiLa
其实流量劫持也很容易。连接商场的公共 WiFi ，伪造一个 DHCP 服务器，在 DHCP Offer 里面配置虚假的 DNS 服务器，就能实现流量劫持了。
虽然有 DHCP Snooping 可以杜绝此问题，但很多商场的公共 WiFi 都没有开启 DHCP Snooping ，甚至一些餐厅直接使用的家用路由器，连 DHCP Snooping 功能都没有。

@XDiLa 46#

我发现你这是在强行诡辩

42#提到的运营商强行给用户网页弹广告是曾经确确实实发生过的事情。2000 年前后接触互联网的老网民都无不对其咬牙切齿。

你在 46#的 n 连问的质疑诡辩不怎么高明。

如果你是真不知道 还是去搜索一下吧

@unused #58 是的，作为 CA 我们会对签发的证书负责，今天会确认清单，并通知用户。

同时我们也需要遵循 CAB/F 的要求，需要对相关证书在 24 小时内进行吊销处理，以降低对生态的威胁。初步排查涉及 100 多张证书，正在进一步核对。

由于目前 ACME 客户端对 ARI 特性（自动重签发证书，再吊销）支持还不完善， @caola 您这边平台是怎么对接我们 LiteSSL 获得 EAB 的，是否有客户联系方式，能否协助我们尽量通知到客户。#51

@myssl #64 我这边只有 OP 上面提到的用于测试临时创建的域名，仅这一个域名的证书，所以我这边不用做通知了。

如果要做通知我这边也无法进行通知，因为都是匿名的……

@ZeroClover Z 大无处不在啊，我看了下帖子，你有一些理解错误。这个 bug 它影响所有使用 DNS-01 方式颁发的证书，包括普通的域名证书。我选通配符证书做复现只是因为通配符证书一定是 DNS-01 方式验证的，而其它的域名证书不一定，并不是只影响通配符证书。

@caola 事发紧急，为了最大程度降低对您这边用户的影响，烦请您发个联系方式到 [email protected] 。

LiteSSL 目前主要通过 FreeSSL 渠道分发，我们拥有账户体系，目前正在紧急安排通知受影响的客户。

我看 cao.la 申请证书时是需要微信或邮箱登录的，想确认下您是在 FreeSSL.cn 注册的吗？如果是，麻烦邮件告知一下您的注册账号，我们可以将针对您证书的具体处理情况精准通知到您。 #65

@caola 用你站里的 litessl 签发证书的只有我一个人这么夸张吗？

毕竟是共用品牌，免费说白了也是积累品牌信誉转化付费用户，但如果有安全隐患，就会起反作用，对造成付费用户造成顾虑，及时发现和修正是绝对有必要的

虽然确实是个严重的漏洞，毕竟谁都不能保证自己写的程序没漏洞嘛，但是厂商的代表 @myssl 能第一时间站出来承认并立马进入紧急修复状态，值得表扬！

@myssl #67 是 freessl 上的账号，前缀为 gg-long 的 QQ 邮箱，
@00oo00 #68 那不至于只有你一个人用 litessl ，之前使用 DNS 验证的也就几个证书而已，也都是使用匿名申请的（非登录用户），即使微信扫码登录的账号，我也无法通知，因为没有做扫码的授权信息通知…

早就知道了，一直在用，为什么有人曝光呢。

@caola 观测到您目前似乎是将同一个 EAB 共享给多位终端用户使用。这种模式存在较大的安全隐患，我们也非常不鼓励这样做，这不仅会导致域名预验证信息被共享，导致未经鉴权的签发。如果 EAB 身份密钥泄漏，甚至可能导致用户证书被恶意吊销。

考虑到证书有效期即将进一步缩短的大趋势，我们建议采用更原生、更安全的用户直连 ACME 模式。如有需要，欢迎联系 [email protected] ，我们可以探讨更规范的对接合作方案，保障您用户的安全。

同时，也借此说明下 LiteSSL 的初衷：这是我们对 ACME 新特性（如 ARI 、Profile 等）的先行探索项目。我们坚持做免费社区版，就是为了与开发者共同进化。非常欢迎各类开源 ACME 客户端（例如 acme.sh 等）与我们集成，共同完善生态。

@myssl 我这个网站的这种模式确实也会存在这种可能，但目前我没有发现有重复申请的用户，现在的 ACME 客户端确实无法直接支持区分类似于我这种的二级分销，除非是为每个用户生成和使用不同的 EAB ，或者有什么办法能让 ACME 免于验证的过期时间快速失效，比如在申请完成后可以主动让对应的域名免于验证的过期时间直接过期掉。为了方便我更倾向于后者，申请完成后订单免于重复验证的过期时间，可以设置为立即过期就行了

之前对亚信还挺有好感的，好像是为数不多的非政府机构中国 CA ，做的工具也都挺实用方便，没想到这么草台，IP 限制都能限制到反代私网 IP 上

@00oo00 #66 这不是我发的帖子

这他妈有点恐怖啊

@CEBBCAT #12
按照 OP 的说法，应该是只有之前使用 LiteSSL 签过证书的域名，才有可能被其他人偷到。并不是想签什么域名就能签什么。
Google 没有在 LiteSSL 签过，因此是没法利用这点去给 Google.com 签证书的。

@all 昨晚问题已修复，受影响的证书已撤销，初步报告已经发布在 https://bugzilla.mozilla.org/show_bug.cgi?id=2011713 ，根因分析会在晚些时候同步。

楼主这个越权思路不错，安全大佬的直觉？

myssl 的处理速度不错，透明及时。要不借机向老板申请开一个 SRC(安全响应中心)吧。

@mikewang 是的，本质是和 EAB 绑定的域名验证缓存（有效期 30 天）被利用了，从审慎的角度，我们昨晚已将最近上线以来的所有 ACME 授权的域名状态从 VALID 重置为 REVOKED #78

@xzl380 感谢认可！楼主 @00oo00 的嗅觉确实非常敏锐，帮我们排除了一个重大隐患。

关于 SRC 的建议非常好！目前我们主要通过邮件接收反馈。这次事发第一时间，我们也从多个渠道收到热心社区用户给我们反馈此帖子，包括邮件、在线客服，这让我们能在第一时间收到并进行处理，将影响降到最低。

确实我们后面需要建立更完善的漏洞响应和奖励机制，希望能和白帽子们建立更长期的良性互动，也欢迎大佬们给点建议。

@myssl #80 缓存有效期 30 天确实有点长了，我说怎么隔了 7 8 个小时再签发都不需要验证。
在线客服反馈的话，应该是我，通过 freessl 反馈的，没想到让你们忙到了一两点，应该今天上午再发帖的哈哈

@myssl 如果可以手动设置过期时间短一点，比如可以手动设置 EAB 申请的所有证书都是 2 个小时就需要重新验证的话会更好，虽然其他 SSL 都是有很长的时间，比如 ZeroSSL 直接就是 90 天缓存时间。另外除了支持 Profile 新特性，还要考虑支持 Let's Encrypt 即将上线的另一种 DNS 验证方式 DNS-PERSIST-01 这个验证方式比较友好一点，ACME 客户端就不用去更新 DNS 解析了

@caola @00oo00 前面有提到 DNS-PERSIST-01 （长效验证）已在计划中。

LiteSSL ACME 相关域名验证重用有效期（ Reuse Period)已在昨晚从 30 天调整为 7 天。 #83 #84

你们这个太吊了，我第一次见到这里出问题的 CA 。你们用的什么 ACME 实现？自己搓的吗？

国内入根主流浏览器的多么，有问题紧急修复就行，支持国货品牌 >_<

@caola https://repository.trustasia.com/zh/repo/cps/adoc/v2.1.1#3-2-2-5-ip%E5%9C%B0%E5%9D%80%E7%9A%84%E7%A1%AE%E8%AE%A4%E5%92%8C%E9%89%B4%E5%88%AB

“3.2.2.5 IP 地址的确认和鉴别
亚洲诚信 CA 接受订户使用公有 IP 申请 SSL 证书，不为 IP 签发域名型和增强型证书”

CPS 焊死了，无法签发 DV 的 IP 证书。

OP 牛的，支持你的无私反馈