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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Driftwood: Know if private keys are sensitive

78 点作者 orangepenguin超过 3 年前

6 条评论

seanieb超过 3 年前
Oh this is interesting. Often bug bounty’s claim a published private key wasn’t in use or sensitive. This gives researchers the ability to call BS on that.
tialaramex超过 3 年前
One thing that you&#x27;ll see happen is, something is supplied with an example or test key and at some point somebody who doesn&#x27;t understand what&#x27;s going on need a &quot;Private key&quot;. Huh. Where can I get a &quot;Private key&quot;? Oh, here&#x27;s one, I&#x27;ll use that. Sometimes it&#x27;s in the context where it was found, but sometimes far away from that.<p>For example, back in March 2020, somebody on m.d.s.policy wondered why seemingly unrelated Web PKI certs had the same private key. So I stared at the certs and I came to the following conclusion:<p>This company Paessler makes a Windows tool called PRTG with a web interface. It is supplied with a demo certificate. So you set up the tool on a Windows server and it basically works, but the certificate isn&#x27;t trustworthy.<p>Some people will click &quot;Ignore&quot; and press on. This is horribly insecure but what&#x27;s new?<p>However, some people will decide they need to get a Certificate. Getting a certificate requires a Private Key. Fortunately, PRTG is supplied with a Private Key so no need to go learn how to make one yourself.<p>So, the people who made PRTG didn&#x27;t screw up here in the sense that <i>they</i> really did make a test or demo key, and from their point of view <i>obviously</i> it isn&#x27;t sensitive since everybody has the same key.<p>Unfortunately their users may not realise and come to depend on this key as &quot;their&quot; private key, and so in this sense it is sensitive, just not for the people who made it.<p>--<p>Regardless of who minted the key you have, and whether they understood its importance, in the Web PKI the correct thing to do is always the same and should be pretty easy:<p>Revoke the certificates for these public keys. Email contacts or Instructions are here: <a href="https:&#x2F;&#x2F;ccadb-public.secure.force.com&#x2F;ccadb&#x2F;AllProblemReportingMechanismsReport" rel="nofollow">https:&#x2F;&#x2F;ccadb-public.secure.force.com&#x2F;ccadb&#x2F;AllProblemReport...</a><p>For Let&#x27;s Encrypt you can actually do this mechanically, their API will accept proof you know the private key as grounds to revoke the certificate even though that&#x27;s not listed above.<p>If the CA refuses to revoke a certificate you&#x27;ve <i>genuinely</i> proved you have the key for (follow any instructions carefully) or just goes silent with no action for a prolonged period, report this problem to m.d.s.policy yourself. You should not need to send the private key itself to anybody as &quot;proof&quot; you have it, the whole <i>point</i> of private keys is that you can prove you know this key without revealing it.
评论 #29156833 未加载
nijave超过 3 年前
Why are there so many private keys in repos? It seems preferable to just generate them when needed instead of risk one being misused
评论 #29155028 未加载
评论 #29155087 未加载
malchow超过 3 年前
Congrats to Dylan and team on this release; incredibly cool - more companies, especially those for whom software is a functional organization but not the primary one -- need to take key leaks seriously.
midasuni超过 3 年前
This was flagged and marked dead at <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29152572" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29152572</a><p>Which is a shame, thanks for resubmitting
评论 #29156413 未加载
nixpulvis超过 3 年前
I&#x27;m sorry, what?! All private keys are sensitve.<p>Please be more spesific.
评论 #29155870 未加载
评论 #29156107 未加载
评论 #29156194 未加载