Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Private key of DigiCert Certificate Transparency log compromised

feistyduck.com

Post reply on HN
Print view View original

21–30 of 40 posts

Re: Private key of DigiCert Certificate Transparency log compromised

#21

Post by lowbloodsugar »

blakesterz wrote: post #3

This was reported first at the begining of May. They got into the server via that Salt vuln and just ran crypto miners on the server, they didn't (as far as anyone knows) use the keys to do anything bad. From the original email reporting the problem: (the attacker doesn't seem to realize that they gained access to the keys and were running other services on the instracture)

Two approaches to doing nasty things on other people's servers: 1) be very quiet and try not to get caught at all. 2) be very noisy doing something "innocent" like running a bitcoin miner.

If you do not assume that everything bad that could have happened, did happen, then you will have some interesting explaining to do later, with lawyers.

Re: Private key of DigiCert Certificate Transparency log compromised

#22

Post by dane-pgp »

CiPHPerCoder wrote: post #11
pinhead26 wrote: post #10

Earlier quoted context omitted.

Ah hello 2015, my old friend. DNSSEC is a Government-Controlled PKI -> Not if the root of trust is secured by a proof-of-work blockchain DNSSEC is Cryptographically Weak -> Not if zone operators upgrade to ECDSA as defined for DNSSEC in https://tools.ietf.org/html/rfc6605 DNSSEC is Unsafe -> NSEC3 is mentioned by the article itself DNSSEC is Expensive To Deploy -> We can make tools for this, so much has gotten easier…

> Not if the root of trust is secured by a proof-of-work blockchain https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoc... https://paragonie.com/blog/2017/07/chronicle-will-make-you-q... > Not if zone operators upgrade to ECDSA as defined for DNSSEC in https://tools.ietf.org/html/rfc6605 First: That's a big "if". Lots of RSA legacy support. Furthermore, ECDSA is so bad that Ed25519 and Ed448 are even coming…

For context, some statistics:

"Currently [2018], in more than 90% of cases if a user passes DNS queries to a resolver that performs DNSSEC validation of an RSA digital signature the same resolver will also perform DNSSEC validation of ECDSA P-256 digital signatures."

https://blog.apnic.net/2018/08/23/measuring-ecdsa-in-dnssec-...

"Since the second quarter of 2019 [to the first quarter of 2020], the population of [strict DNSSEC] validating users has risen from 12% to 22%, close to doubling. At the same time, the proportion of [non-strict DNSSEC validating] users has risen from 5% to 10%."

https://blog.apnic.net/2020/03/02/dnssec-validation-revisite...

Re: Private key of DigiCert Certificate Transparency log compromised

#23

Post by Spivak »

rasengan wrote: post #9
some_furry wrote: post #4

Earlier quoted context omitted.

I'm pretty sure the SCT requirement contained the blast radius of this compromise to avoid anyone from actually being affected by it, so your comment doesn't really follow here. Also, DANE relies on DNSSEC [1], which is bad. https://sockpuppet.org/blog/2015/01/15/against-dnssec

> I'm pretty sure the SCT requirement contained the blast radius of this compromise to avoid anyone from actually being affected by it, so your comment doesn't really follow here. I think this would be true except my statement wasn't just about SCT but the CA system in general. Furthermore, browsers like Firefox [1] do not even have CT checks. > Also, DANE relies on DNSSEC [1], which is bad. Handshake completes this…

Despite being supported, relying on browsers checking CT logs was never something that what going to be deployed at scale because, just like revocation lists, it adds a performance hurdle to every request.

Auditors and monitors are the real protection you get from CT logs.

You get the same problem with any form of DNS validation because you'll never get every little caching server to validate records.

Re: Private key of DigiCert Certificate Transparency log compromised

#24

Post by dane-pgp »

pinhead26 wrote: post #10
some_furry wrote: post #4

Earlier quoted context omitted.

I'm pretty sure the SCT requirement contained the blast radius of this compromise to avoid anyone from actually being affected by it, so your comment doesn't really follow here. Also, DANE relies on DNSSEC [1], which is bad. https://sockpuppet.org/blog/2015/01/15/against-dnssec

Ah hello 2015, my old friend. DNSSEC is a Government-Controlled PKI -> Not if the root of trust is secured by a proof-of-work blockchain DNSSEC is Cryptographically Weak -> Not if zone operators upgrade to ECDSA as defined for DNSSEC in https://tools.ietf.org/html/rfc6605 DNSSEC is Unsafe -> NSEC3 is mentioned by the article itself DNSSEC is Expensive To Deploy -> We can make tools for this, so much has gotten easier…

A better argument against the preposterous claim that DNSSEC is "government-controlled" (and one that doesn't rely on blockchains, which are controversial in their own right), is that with DNSSEC you can choose which government (i.e. ccTLD) your domain is under, or choose one of the many generic TLDs.

The web PKI, by contrast, requires users to trust a bunch of CAs, any one of which could have been compromised by a government and can issue a certificate for your domain. Also, if a government can compromise your DNS records, they can also be granted domain-validated certificates for those domains, so the web PKI is not an improvement.

Anyway, if your threat model is that every single country in the world is willing to subvert the security of their own DNS hierarchy specifically to attack you, then the limitations of DNSSEC are the least of your worries.

Re: Private key of DigiCert Certificate Transparency log compromised

#25

Post by bawolff »

cjbprime wrote: post #13
bawolff wrote: post #12

Earlier quoted context omitted.

Well the political consequences are kind of bad. CA system is built around trust. Not being able to secure their servers, even non critical ones, degrades trust.

The CT system is built around controlled suspicion, not trust.

Sure, but if i can't trust someone to run a CT server, why would i trust them to run a CA?

Re: Private key of DigiCert Certificate Transparency log compromised

#26

Post by Avamander »

dane-pgp wrote: post #24
pinhead26 wrote: post #10

Earlier quoted context omitted.

Ah hello 2015, my old friend. DNSSEC is a Government-Controlled PKI -> Not if the root of trust is secured by a proof-of-work blockchain DNSSEC is Cryptographically Weak -> Not if zone operators upgrade to ECDSA as defined for DNSSEC in https://tools.ietf.org/html/rfc6605 DNSSEC is Unsafe -> NSEC3 is mentioned by the article itself DNSSEC is Expensive To Deploy -> We can make tools for this, so much has gotten easier…

A better argument against the preposterous claim that DNSSEC is "government-controlled" (and one that doesn't rely on blockchains, which are controversial in their own right), is that with DNSSEC you can choose which government (i.e. ccTLD) your domain is under, or choose one of the many generic TLDs. The web PKI, by contrast, requires users to trust a bunch of CAs, any one of which could have been compromised by a g…

With the CT system I can monitor the CA's issuance, with DNSSEC I can't retroactively monitor if someone has changed the DANE keys and intercepted traffic.

Re: Private key of DigiCert Certificate Transparency log compromised

#27

Post by Avamander »

rasengan wrote: post #2

This CA system is designed for maximum reduction in security - not defense in depth. The company with the least security defines the security of the entire CA system. It’s time for DANE [1]. We don’t need any more “men in the middle.” [1] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

How would you monitor that your DNS provider hasn't changed your DANE records and intercepted traffic?

Re: Private key of DigiCert Certificate Transparency log compromised

#28

Post by cjbprime »

bawolff wrote: post #25
cjbprime wrote: post #13

Earlier quoted context omitted.

The CT system is built around controlled suspicion, not trust.

Sure, but if i can't trust someone to run a CT server, why would i trust them to run a CA?

It was a 0day in a popular open source package. They didn't do anything wrong. Presumably they use stronger defense in depth, as required by the CA guidelines, to prevent software compromises to the actual CA signing machines. There's no need to go through that level of paranoia for CT log machines.

Re: Private key of DigiCert Certificate Transparency log compromised

#29

Post by tialaramex »

trishankdatadog wrote: post #19

The problem with Transparent Logs / Certificate Transparency is that they don't have the best story with regarding to recovering from compromise. We wrote an article comparing The Update Framework (TUF) to CT/TL: https://ssl.engineering.nyu.edu/blog/2020-02-03-transparent-...

Your blog post is about yet another X Transparency, rather than about Certificate Transparency. Because CT works well people tried to apply the same approach to lots of other problems, most of them obviously dumb.

CT is a narrow solution to a narrow problem. We had that specific problem, and so this is a very good solution. You almost certainly don't have that problem, our solution can't help you, we aren't sorry about that.

Re: Private key of DigiCert Certificate Transparency log compromised

#30

Post by dane-pgp »

Avamander wrote: post #26
dane-pgp wrote: post #24

Earlier quoted context omitted.

A better argument against the preposterous claim that DNSSEC is "government-controlled" (and one that doesn't rely on blockchains, which are controversial in their own right), is that with DNSSEC you can choose which government (i.e. ccTLD) your domain is under, or choose one of the many generic TLDs. The web PKI, by contrast, requires users to trust a bunch of CAs, any one of which could have been compromised by a g…

With the CT system I can monitor the CA's issuance, with DNSSEC I can't retroactively monitor if someone has changed the DANE keys and intercepted traffic.

True, DNSSEC Transparency is not as developed a technology as Certificate Transparency. There has been experimental deployment of such a system[0] but to give higher assurance there is a small addition to the DNS data that needs to be adopted first[1], which is still going through the IETF process.

[0] https://twitter.com/ln4711/status/754516056878772224

[1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-deleg...

Post reply on HN