突发：多个国别顶级域名遭到劫持 谷歌通过Chrome紧急封锁未授权签发的TLS证书
突发：多个国别顶级域名遭到劫持，谷歌通过 Chrome 紧急封锁未经授权签发的 TLS 证书。据谷歌安全团队发布的最新消息，加纳 GH 域名、塞拉利昂 SL 域名、美属萨摩亚 AS 域名遭到域名注册机构级别的劫持。黑客篡改 DNS 记录为包括谷歌在内的多个域名申请 TLS 证书用于后续劫持。目前谷歌正在通过 Chrome CRLSet 机制封锁已经识别出来的异常证书，建议用户在访问相关域名时提高警惕，因为此时这些域名可能已经被黑客控制。
据谷歌安全团队发布的最新博客，近期加纳国别顶级域名 GH、塞拉利昂国别顶级域名 SL、美属萨摩亚地区顶级域名 AS 遭到攻击者劫持。黑客直接通过域名注册机构级别的攻击获得大量域名的控制权，然后篡改 DNS 记录用于申请签发 TLS 证书，最终这些证书将被用于面向用户的劫持。
包括谷歌在内多个域名被劫持：
黑客获得域名控制权后主要行为是篡改 DNS 记录用于申请签发 TLS 证书，当成功签发证书后就可以将域名指向黑客服务器并用于劫持和流量解密。谷歌在博客中透露，包括谷歌在内的多个机构网站域名都出现未经授权签发的 TLS 证书。
谷歌强调该公司内部系统并未遭到入侵，也没有理由认为签发证书的证书颁发机构 (CA) 违反相关流程，因为按照现有 CA 流程只要域名添加有效的 DNS 记录那就可以证明申请者拥有域名所有权，所以可以签发证书。
谷歌通过 Chrome 浏览器拦截异常证书：
发现此次事件后谷歌通过 Chrome CRLSet 机制封锁大量已经识别出来的未授权证书，同时谷歌联系相关证书颁发机构撤销证书以保护其他浏览器和客户端。随后谷歌分析证书透明度日志，发现还有多家全球品牌和常用在线服务可能受影响，因此用户访问对应网站时也会看到 Chrome 的拦截提示。
谷歌并没有透露受影响的企业或服务名单以及证书数量，谷歌称 DNS 劫持情况非常复杂、无法保证找到所有受影响的域名；浏览器端拦截也不能可靠地保护非 Chrome 用户，相关域名使用者应当检查证书和 DNS 防护记录，如发现异常记录应当及时删除。
通过证书透明度网站监控证书签发：
如果使用 GH、SL 和 AS 域名，域名持有者可以访问 crt.sh 网站查询对应域名签发的证书，如果发现存在非自己申请的证书则应当尽快联系证书颁发机构吊销对应的证书，避免黑客继续使用这些证书对用户进行劫持。
消息源：Google
包括谷歌在内多个域名被劫持：
黑客获得域名控制权后主要行为是篡改 DNS 记录用于申请签发 TLS 证书，当成功签发证书后就可以将域名指向黑客服务器并用于劫持和流量解密。谷歌在博客中透露，包括谷歌在内的多个机构网站域名都出现未经授权签发的 TLS 证书。
谷歌强调该公司内部系统并未遭到入侵，也没有理由认为签发证书的证书颁发机构 (CA) 违反相关流程，因为按照现有 CA 流程只要域名添加有效的 DNS 记录那就可以证明申请者拥有域名所有权，所以可以签发证书。
谷歌通过 Chrome 浏览器拦截异常证书：
发现此次事件后谷歌通过 Chrome CRLSet 机制封锁大量已经识别出来的未授权证书，同时谷歌联系相关证书颁发机构撤销证书以保护其他浏览器和客户端。随后谷歌分析证书透明度日志，发现还有多家全球品牌和常用在线服务可能受影响，因此用户访问对应网站时也会看到 Chrome 的拦截提示。
谷歌并没有透露受影响的企业或服务名单以及证书数量，谷歌称 DNS 劫持情况非常复杂、无法保证找到所有受影响的域名；浏览器端拦截也不能可靠地保护非 Chrome 用户，相关域名使用者应当检查证书和 DNS 防护记录，如发现异常记录应当及时删除。
通过证书透明度网站监控证书签发：
如果使用 GH、SL 和 AS 域名，域名持有者可以访问 crt.sh 网站查询对应域名签发的证书，如果发现存在非自己申请的证书则应当尽快联系证书颁发机构吊销对应的证书，避免黑客继续使用这些证书对用户进行劫持。
消息源：Google
关于作者
评论1次
这事其实不复杂，攻击者拿下注册局级别的权限后想签证书太容易了，DNS 记录一改就走正常 DCV 流程，CA 那边没毛病。关键还是 .gh/.sl/.as 这几个后缀的域名持有者自己赶紧自查。
几个可以直接落地的点：
立刻去 crt.sh 把自己的主域名和子域都查一遍，时间窗口拉长到最近一两个月，看有没有不认识的 CA 给签了证书，认准 issuer 和 notBefore 时间。看到不认识的就别等了，直接拿证书序列号去找对应 CA 申请吊销，Let's Encrypt、GoGetSSL、DigiCert 这些都给吊销通道的。
DNS 这边全量过一遍，NS、A、AAAA、MX、CAA、DS 该对的都对着看，有任何陌生记录直接清掉，顺便把 TTL 改短一点方便后面再被改能快速切。
注册局那边该锁就锁，能上 clientHold / serverTransferProhibited / clientUpdateProhibited 全部勾上，能上 registry lock 最好（虽然这几个 ccTLD 大概率没有，但先问问），把 transfer auth code 流程收紧，能改 Registrant/Admin 邮箱为前提的 EPP auth 也加上。
加一条 CAA 记录，只允许你信任的一两家 CA 给你签证书，这样就算以后又被劫持了，黑客拿着改好的 DNS 去找野鸡 CA 也签不出来。这个是 0 成本高收益的，立刻就能上。
CT 日志监控搭起来，crt.sh 的订阅、Facebook 的 CT monitor、或者自己写脚本拉 Sonar 的 feed，关键词命中就告警，别等下一次出事才发现。
至于说"被劫持期间有没有中间人风险"——有，但客户端这边只能靠浏览器弹证书错误或者 Chrome CRLSet 兜底，Firefox/Safari 用户其实这波是裸奔的。所以企业侧要做的其实更重：邮件收发、API 调用、OAuth callback 域名都列出来过一遍，看有没有走这些后缀的临时资产。
说到底这事给所有小国 ccTLD 用户提了个醒，注册局被一锅端的时候 CA 体xi是帮不了你的，证书透明度 + 主动监控才是最后一道防线。