Private key of DigiCert Certificate Transparency log compromised
1–10 of 40 posts
Re: Private key of DigiCert Certificate Transparency log compromised
#2This 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...
Re: Private key of DigiCert Certificate Transparency log compromised
#3This 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)
Re: Private key of DigiCert Certificate Transparency log compromised
#4This 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...
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.
Re: Private key of DigiCert Certificate Transparency log compromised
#5This 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)
Cryptocurrency continues to improve security by polluting attackers with short-sighted incentives that prevent real damage from occurring.
Re: Private key of DigiCert Certificate Transparency log compromised
#6As I understand it, this is not a big deal: there are multiple CT servers, and auditors verifying their entries, the design of the system assumes the possibility of compromised log operators.
Re: Private key of DigiCert Certificate Transparency log compromised
#7As I understand it, this is not a big deal: there are multiple CT servers, and auditors verifying their entries, the design of the system assumes the possibility of compromised log operators.
Correct. It's an interesting incident, but the consequences for Internet users are pretty much zero.
(Conversely, multiple CT server compromises would be a significant concern, but even then without a compromised Certificate Authority, the impact is almost zero.)
Re: Private key of DigiCert Certificate Transparency log compromised
#8This 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...
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
Agree with you, it's entirely incorrect that a CT log operator "defines the security of the entire CA system". They can't issue certs and their output is already regarded with suspicion by default.
Re: Private key of DigiCert Certificate Transparency log compromised
#9This 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...
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 system [2].
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1281469
[1a] https://developer.mozilla.org/en-US/docs/Web/Security/Certif...
Re: Private key of DigiCert Certificate Transparency log compromised
#10This 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...
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 already
DNSSEC is Incomplete -> Agreed, we need browser adoption