TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ssl.com: DCV bypass and issue fake certificates for any MX hostname

217 点作者 xPaw26 天前

9 条评论

btown25 天前
Public service announcement: CAA records exist and allow you to whitelist the CAs you trust to issue certificates for your domain.<p><a href="https:&#x2F;&#x2F;letsencrypt.org&#x2F;docs&#x2F;caa&#x2F;" rel="nofollow">https:&#x2F;&#x2F;letsencrypt.org&#x2F;docs&#x2F;caa&#x2F;</a><p>You can use <a href="https:&#x2F;&#x2F;www.entrust.com&#x2F;resources&#x2F;tools&#x2F;caa-lookup" rel="nofollow">https:&#x2F;&#x2F;www.entrust.com&#x2F;resources&#x2F;tools&#x2F;caa-lookup</a> (or e.g. `dig caa paypal.com`) to see if any domain is protected.<p><a href="https:&#x2F;&#x2F;isc.sans.edu&#x2F;diary&#x2F;26738" rel="nofollow">https:&#x2F;&#x2F;isc.sans.edu&#x2F;diary&#x2F;26738</a> is a cautionary study from 2020 indicating only 3% of the Alexa top 1M had CAA records. And just now, I&#x27;ve seen numerous news and government sites that do not have CAA enabled... making them vulnerable to issuance bugs like this on CAs they may never have heard of, and thus making their readership&#x2F;constituencies vulnerable to misinformation and fraud, especially in the context of a potential multifaceted attack against router infrastructure to perform MITM attacks at scale.<p>Of course, you&#x27;ll want to make sure you don&#x27;t accidentally disavow an important subdomain where an engineer used a different CA than your usual suspects. But looking at all historic issuers for your domain hierarchies on transparency logs using e.g. <a href="https:&#x2F;&#x2F;crt.sh&#x2F;" rel="nofollow">https:&#x2F;&#x2F;crt.sh&#x2F;</a> might be a good place to start.<p>It&#x27;s also good to monitor certificate transparency logs, but then the onus is on your security team to react if an incident occurs. Proactive controls are vital as well, and IMHO CAA avoids many of the downsides of pinning.
评论 #43740160 未加载
评论 #43739899 未加载
评论 #43743758 未加载
评论 #43741419 未加载
评论 #43740118 未加载
0x026 天前
So I guess you couldn&#x27;t get certificates for any random (MX) domain, only for those where you can obtain an inbox &#x2F; user account. Still really bad, especially for things like gmail.com, but also larger enterprises. Intense.
评论 #43738787 未加载
评论 #43740144 未加载
评论 #43739987 未加载
评论 #43738802 未加载
评论 #43741884 未加载
cmeacham9826 天前
This is a ... pretty serious oversight.<p>But at least it initially appears SSL.com is taking it seriously, we&#x27;ll have to see what the report says.
jenny9125 天前
Wow... this is the most serious TLS issue I&#x27;ve seen since following these things.
评论 #43740386 未加载
AdamJacobMuller25 天前
&gt; We will provide a preliminary report on or before 2025-04-21.<p>Bunch of engineers just got their easter weekend ruined. Sucks.
评论 #43739722 未加载
CrimsonRain26 天前
I guess they can check logs and find how many times this has been abused already? Can we trust them to release full transparent report?
评论 #43739964 未加载
评论 #43739259 未加载
评论 #43738734 未加载
评论 #43759227 未加载
评论 #43739079 未加载
评论 #43738929 未加载
Galanwe25 天前
The whole PKI concept is dead anyway. Users have been trained to bypass certificate warnings by CA store wars between browsers and OSes, MitM corporate SSL proxies a-la ZScaler &#x2F; Intune, corporate self signing CAs for intranets and whatnot, blindfolded public CAs giving certs to whatever.
评论 #43742533 未加载
thayne26 天前
Have they started revoking invalid certs?
评论 #43738812 未加载
0xbadcafebee25 天前
And remember kids: there&#x27;s hundreds of CAs, they all implement validation independently, and you just need <i>one</i> to do <i>one</i> of the three validation methods wrong to make any cert you want. And there&#x27;s two dozen different attacks that work aside from bugs in validation. Cert validation is swiss cheese.<p>But there&#x27;s a fix: have the registrars confirm authority to issue certs using a public key uploaded by the domain owner. The CSR contains a request signed by the same domain owner key. The CA sends the CSR to the registrar, the registrar verifies it was signed by the same key they have, then they send back a newly signed object (that the eventual-https-end-user can later confirm was signed by the registrar, so everybody knows that every step of the way was confirmed cryptographically). This ensures a single secure authorization by the actual domain owner, verified by the registrar of the domain. All you have to change is how the CA validates, and the registrar needs to handle an extra step or two. Solves 95% of the vulnerabilities.<p>....but nobody&#x27;s going to do that, because the fact that Web PKI is swiss cheese hasn&#x27;t threatened a big enough business yet. Once money or politics is threatened, they&#x27;ll fix it.
评论 #43742591 未加载
评论 #43741823 未加载