10 ms·

Private key of DigiCert Certificate Transparency log compromised

79 points by CiPHPerCoder 6y ago

rasengan 6y ago
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_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
- some_furry 6y ago
  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 https://sockpuppet.org/blog/2015/01/15/against-dnssec
  - cjbprime 6y ago
    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.
  - rasengan 6y ago
    > 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1281469 [1a] https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency https://developer.mozilla.org/en-US/docs/Web/Security/Certif... [2] https://github.com/handshake-org/hdns https://github.com/handshake-org/hdns
    - Spivak 6y ago
      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.
    - tptacek 6y ago
      Just so everyone's clear about this, Handshake is a system backed by a cryptocurrency, "HNS", that is actively traded despite being useful only to speculators. Its backers believe that they'll take over control of the Internet and be rewarded financially for it through their currency. If that works, I call ARPcoin next.
  - pinhead26 6y ago
    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 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
    - CiPHPerCoder 6y ago
      > Not if the root of trust is secured by a proof-of-work blockchain https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoculture https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoc... https://paragonie.com/blog/2017/07/chronicle-will-make-you-question-need-for-blockchain-technology 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 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 to FIPS 186-5 later this year. Citing ECDSA adoption in DNSSEC doesn't make as strong of a case as you might think.
      - dane-pgp 6y ago
        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-an-update/ 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-revisited/ https://blog.apnic.net/2020/03/02/dnssec-validation-revisite...
    - dane-pgp 6y ago
- Avamander 6y ago
  How would you monitor that your DNS provider hasn't changed your DANE records and intercepted traffic?
blakesterz 6y ago
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)
- some_furry 6y ago
  Cryptocurrency continues to improve security by polluting attackers with short-sighted incentives that prevent real damage from occurring.
  - nailer 6y ago
    I don't think cryptocurrency has changed much in that regard. Before CC mining the default use for an owned box was warez servers, IRC or jump hosts.
    - gruez 6y ago
      Those are much harder to detect, especially the latter two.
      - nailer 6y ago
        I'm not sure. Most crackers don't use port knocking or other obfuscation techniques, so something that shouldn't be listening on a box and a large amount of bandwidth being used is normally a good indicator.
        gruez 6y ago
        I think there's great overlap between servers that aren't monitored and servers that are vulnerable to exploits. If you're monitoring your servers for unknown listening ports, chances are you're keeping your systems up to date. Same with bandwidth, although if bandwidth is expensive (eg. cloud providers), your accounting dept might notice.
cjbprime 6y ago
As 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.
- some_furry 6y ago
  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.)
- bawolff 6y ago
  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.
  - cjbprime 6y ago
    The CT system is built around controlled suspicion, not trust.
    - bawolff 6y ago
      Sure, but if i can't trust someone to run a CT server, why would i trust them to run a CA?
      - cjbprime 6y ago
        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.
dang 6y ago
See also https://news.ycombinator.com/item?id=23062904 https://news.ycombinator.com/item?id=23062904 from a few weeks ago.
Simulacra 6y ago
This is a little bit of old news and sounds worse than it is. There are plenty of checks and redundancy operators in the CA auth universe.
trishankdatadog 6y ago
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-logs https://ssl.engineering.nyu.edu/blog/2020-02-03-transparent-...
- tialaramex 6y ago
  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.
  - trishankdatadog 6y ago
    Strange comment. I'm not sorry you're not sorry either.

79 points by CiPHPerCoder 6y ago

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_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

some_furry 6y ago
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 https://sockpuppet.org/blog/2015/01/15/against-dnssec
- cjbprime 6y ago
  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.
- rasengan 6y ago
  > 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1281469 [1a] https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency https://developer.mozilla.org/en-US/docs/Web/Security/Certif... [2] https://github.com/handshake-org/hdns https://github.com/handshake-org/hdns
  - Spivak 6y ago
    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.
  - tptacek 6y ago
    Just so everyone's clear about this, Handshake is a system backed by a cryptocurrency, "HNS", that is actively traded despite being useful only to speculators. Its backers believe that they'll take over control of the Internet and be rewarded financially for it through their currency. If that works, I call ARPcoin next.
- pinhead26 6y ago
  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 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
  - CiPHPerCoder 6y ago
    > Not if the root of trust is secured by a proof-of-work blockchain https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoculture https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoc... https://paragonie.com/blog/2017/07/chronicle-will-make-you-question-need-for-blockchain-technology 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 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 to FIPS 186-5 later this year. Citing ECDSA adoption in DNSSEC doesn't make as strong of a case as you might think.
    - dane-pgp 6y ago
      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-an-update/ 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-revisited/ https://blog.apnic.net/2020/03/02/dnssec-validation-revisite...
  - dane-pgp 6y ago
Avamander 6y ago
How would you monitor that your DNS provider hasn't changed your DANE records and intercepted traffic?

blakesterz 6y ago

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)

some_furry 6y ago
Cryptocurrency continues to improve security by polluting attackers with short-sighted incentives that prevent real damage from occurring.
- nailer 6y ago
  I don't think cryptocurrency has changed much in that regard. Before CC mining the default use for an owned box was warez servers, IRC or jump hosts.
  - gruez 6y ago
    Those are much harder to detect, especially the latter two.
    - nailer 6y ago
      I'm not sure. Most crackers don't use port knocking or other obfuscation techniques, so something that shouldn't be listening on a box and a large amount of bandwidth being used is normally a good indicator.
      - gruez 6y ago
        I think there's great overlap between servers that aren't monitored and servers that are vulnerable to exploits. If you're monitoring your servers for unknown listening ports, chances are you're keeping your systems up to date. Same with bandwidth, although if bandwidth is expensive (eg. cloud providers), your accounting dept might notice.

cjbprime 6y ago

As 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.

some_furry 6y ago
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.)
bawolff 6y ago
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.
- cjbprime 6y ago
  The CT system is built around controlled suspicion, not trust.
  - bawolff 6y ago
    Sure, but if i can't trust someone to run a CT server, why would i trust them to run a CA?
    - cjbprime 6y ago
      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.

dang 6y ago

See also https://news.ycombinator.com/item?id=23062904 https://news.ycombinator.com/item?id=23062904 from a few weeks ago.

Simulacra 6y ago

This is a little bit of old news and sounds worse than it is. There are plenty of checks and redundancy operators in the CA auth universe.

trishankdatadog 6y ago

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-logs https://ssl.engineering.nyu.edu/blog/2020-02-03-transparent-...

tialaramex 6y ago
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.
- trishankdatadog 6y ago
  Strange comment. I'm not sorry you're not sorry either.