4 ms·

I’m not sure how CT logs actually work, but is it impossible for the CA to issue a certificate that is not entered into the CT logs? If it’s possible, then gove

I’m not sure how CT logs actually work, but is it impossible for the CA to issue a certificate that is not entered into the CT logs? If it’s possible, then governments would surely just require that, and then it would only be caught by interception of the actual certificate being used.

Khoth 3y ago
Browsers won't accept a certificate unless it comes with proof that it was submitted to a CT log. So a government could MITM you but they'd have to burn a CA to do it, whether you personally noticed the attack or not, so it's a very high cost attack
- tialaramex 3y ago
  The proof is an SCT, a signed document from the Log which says "I promise I logged this pre-certificate". [[ In some cases it'll be the actual certificate, but for most real world TLS certificates it's a pre-certificate with the same substantive details, if you think about it you will see why the SCT baked inside your certificate cannot mention the actual document it is baked inside ]] Now, of course at the moment this document is created, there's no way to be sure this claim is true. The logs are a distributed system. Twenty four hours later, (the Maximum Merge Delay, this is a global policy decision) the log should, if you interrogate it, be able to show you a log entry matching the SCT, which traces to the agreed Merkle Tree head for that log. If it cannot, in principle that log has failed and must be distrusted. This happens (to one of the dozens of public logs, somewhere) a few times per year on average. In principle, everybody who sees the log could agree that they see the same Merkle Tree head, thus the certificate really is logged. In practice the mechanisms to ensure this works, a Gossip protocol, do not exist and have never been deployed in practical use. It's probably fine, but without ever completing the system as designed, it does have flaws.
  - agwa 3y ago
    > In principle, everybody who sees the log could agree that they see the same Merkle Tree head, thus the certificate really is logged. In practice the mechanisms to ensure this works, a Gossip protocol, do not exist and have never been deployed in practical use. It has been - the commercial instance of Cert Spotter gossips STHs with Chrome's SCT auditing infrastructure. Edit: here's the gossip feed of STHs observed by Chrome's SCT auditing infrastructure: https://www.gstatic.com/ct/gossip/ct/v1/sth-pollination https://www.gstatic.com/ct/gossip/ct/v1/sth-pollination And here's the gossip feed of STHs observed by Cert Spotter: https://certspotter.com/.well-known/ct/v1/sth-pollination https://certspotter.com/.well-known/ct/v1/sth-pollination
    - tialaramex 3y ago
      Ooh interesting, when did that start?
      - agwa 3y ago
        2017, but it only started having real value once SCT auditing rolled out in 2022.
- tptacek 3y ago
  This is theoretically true but not really true in practice right now. If a CA misissues a cert for something major, like Facebook or Google Mail, and Google or Mozilla find out, my current belief is that they'd be in for a world of hurt. But if a CA misissued such a cert for a single specific target, without a CT SCT, neither Chrome nor Safari will report that (currently, CAs are explicitly allowed to issue non-CT-logged certs; the check on that is that Chrome and Safari won't honor that certificate --- a reason, by the way, to reconsider Firefox). If Google found out that you'd misissued a non-logged Google Mail certificate, you'd get nuked. But there's nothing currently in place to make Google find that out. It's clear what tweaks to the system would need to occur to make this work that way it would "ideally" work, and the problems are mostly not technical; you'd just have Chrome (or Safari, or Firefox) report certs without SCTs in its default configuration. But that kind of surveillance isn't really a thing right now. I've been cagey about this in past discussions because my understanding was that the Chrome team did do some of this kind of surveillance informally. And I believe they did --- but I'm told that stopped being a thing years ago. Now they just don't accept certs unless they're logged, and that's that.
  - agwa 3y ago
    > If a CA misissues a cert for something major, like Facebook or Google Mail, and Google or Mozilla find out, my current belief is that they'd be in for a world of hurt. It doesn't even need to be major. Misissuing for example.com and test.com were major factors in the distrust of Symantec and Certinomis, respectively. > It's clear what tweaks to the system would need to occur to make this work that way it would "ideally" work, and the problems are mostly not technical; you'd just have Chrome (or Safari, or Firefox) report certs without SCTs in its default configuration. This would require a pretty big paradigm shift which is hard to see happening. But as long as clients require SCTs (Firefox needs to hurry up already) this is not really necessary. > I've been cagey about this in past discussions because my understanding was that the Chrome team did do some of this kind of surveillance informally. And I believe they did --- but I'm told that stopped being a thing years ago. I'm pretty sure this has never been the case. I think at one point Chrome may have reported certificates for Google domains that were not issued by a Google CA, but this was unrelated to CT. Or maybe you're thinking of the Googlebot, which logs the certificates it sees while crawling the web.
g_p 3y ago
Many major browsers expect CT, and won't accept a certificate from a default CA without it being in CT. Therefore it matters a little less whether such a certificate can be issued, but rather whether it can be accepted by a browser (which many popular ones won't). And therefore it will become relatively noisy and detectable if such a certificate is deployed at any sense of scale. Chrome - https://chromestatus.com/feature/6244547273687040 https://chromestatus.com/feature/6244547273687040 Safari - https://support.apple.com/en-gb/HT205280 https://support.apple.com/en-gb/HT205280 Firefox doesn't support it yet though - https://bugzilla.mozilla.org/show_bug.cgi?id=1281469 https://bugzilla.mozilla.org/show_bug.cgi?id=1281469 In essence, a cryptographic proof that the certificate was sent to CT providers needs to be enclosed along with the certificate. That can come via an OSCP staple, or a TLS extension. More info - https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency https://developer.mozilla.org/en-US/docs/Web/Security/Certif...
- thayne 3y ago
  But what about clients that aren't browsers?
  - tptacek 3y ago
    What about them? It's not like any of this technology requires a Javascript implementation to run.
    - thayne 3y ago
      But how prevalent is it that other clients verify a cert is in a CT log?
      - tptacek 3y ago
        That's not how CT works! You don't have to go check if a cert is in a log! (How many client/embedded systems do fully recursive DNSSEC verification? Zero!)
        3y ago

Khoth 3y ago

Browsers won't accept a certificate unless it comes with proof that it was submitted to a CT log. So a government could MITM you but they'd have to burn a CA to do it, whether you personally noticed the attack or not, so it's a very high cost attack

tialaramex 3y ago
The proof is an SCT, a signed document from the Log which says "I promise I logged this pre-certificate". [[ In some cases it'll be the actual certificate, but for most real world TLS certificates it's a pre-certificate with the same substantive details, if you think about it you will see why the SCT baked inside your certificate cannot mention the actual document it is baked inside ]] Now, of course at the moment this document is created, there's no way to be sure this claim is true. The logs are a distributed system. Twenty four hours later, (the Maximum Merge Delay, this is a global policy decision) the log should, if you interrogate it, be able to show you a log entry matching the SCT, which traces to the agreed Merkle Tree head for that log. If it cannot, in principle that log has failed and must be distrusted. This happens (to one of the dozens of public logs, somewhere) a few times per year on average. In principle, everybody who sees the log could agree that they see the same Merkle Tree head, thus the certificate really is logged. In practice the mechanisms to ensure this works, a Gossip protocol, do not exist and have never been deployed in practical use. It's probably fine, but without ever completing the system as designed, it does have flaws.
- agwa 3y ago
  > In principle, everybody who sees the log could agree that they see the same Merkle Tree head, thus the certificate really is logged. In practice the mechanisms to ensure this works, a Gossip protocol, do not exist and have never been deployed in practical use. It has been - the commercial instance of Cert Spotter gossips STHs with Chrome's SCT auditing infrastructure. Edit: here's the gossip feed of STHs observed by Chrome's SCT auditing infrastructure: https://www.gstatic.com/ct/gossip/ct/v1/sth-pollination https://www.gstatic.com/ct/gossip/ct/v1/sth-pollination And here's the gossip feed of STHs observed by Cert Spotter: https://certspotter.com/.well-known/ct/v1/sth-pollination https://certspotter.com/.well-known/ct/v1/sth-pollination
  - tialaramex 3y ago
    Ooh interesting, when did that start?
    - agwa 3y ago
      2017, but it only started having real value once SCT auditing rolled out in 2022.
tptacek 3y ago
This is theoretically true but not really true in practice right now. If a CA misissues a cert for something major, like Facebook or Google Mail, and Google or Mozilla find out, my current belief is that they'd be in for a world of hurt. But if a CA misissued such a cert for a single specific target, without a CT SCT, neither Chrome nor Safari will report that (currently, CAs are explicitly allowed to issue non-CT-logged certs; the check on that is that Chrome and Safari won't honor that certificate --- a reason, by the way, to reconsider Firefox). If Google found out that you'd misissued a non-logged Google Mail certificate, you'd get nuked. But there's nothing currently in place to make Google find that out. It's clear what tweaks to the system would need to occur to make this work that way it would "ideally" work, and the problems are mostly not technical; you'd just have Chrome (or Safari, or Firefox) report certs without SCTs in its default configuration. But that kind of surveillance isn't really a thing right now. I've been cagey about this in past discussions because my understanding was that the Chrome team did do some of this kind of surveillance informally. And I believe they did --- but I'm told that stopped being a thing years ago. Now they just don't accept certs unless they're logged, and that's that.
- agwa 3y ago
  > If a CA misissues a cert for something major, like Facebook or Google Mail, and Google or Mozilla find out, my current belief is that they'd be in for a world of hurt. It doesn't even need to be major. Misissuing for example.com and test.com were major factors in the distrust of Symantec and Certinomis, respectively. > It's clear what tweaks to the system would need to occur to make this work that way it would "ideally" work, and the problems are mostly not technical; you'd just have Chrome (or Safari, or Firefox) report certs without SCTs in its default configuration. This would require a pretty big paradigm shift which is hard to see happening. But as long as clients require SCTs (Firefox needs to hurry up already) this is not really necessary. > I've been cagey about this in past discussions because my understanding was that the Chrome team did do some of this kind of surveillance informally. And I believe they did --- but I'm told that stopped being a thing years ago. I'm pretty sure this has never been the case. I think at one point Chrome may have reported certificates for Google domains that were not issued by a Google CA, but this was unrelated to CT. Or maybe you're thinking of the Googlebot, which logs the certificates it sees while crawling the web.

g_p 3y ago

Many major browsers expect CT, and won't accept a certificate from a default CA without it being in CT. Therefore it matters a little less whether such a certificate can be issued, but rather whether it can be accepted by a browser (which many popular ones won't). And therefore it will become relatively noisy and detectable if such a certificate is deployed at any sense of scale. Chrome - https://chromestatus.com/feature/6244547273687040 https://chromestatus.com/feature/6244547273687040 Safari - https://support.apple.com/en-gb/HT205280 https://support.apple.com/en-gb/HT205280 Firefox doesn't support it yet though - https://bugzilla.mozilla.org/show_bug.cgi?id=1281469 https://bugzilla.mozilla.org/show_bug.cgi?id=1281469 In essence, a cryptographic proof that the certificate was sent to CT providers needs to be enclosed along with the certificate. That can come via an OSCP staple, or a TLS extension. More info - https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency https://developer.mozilla.org/en-US/docs/Web/Security/Certif...

thayne 3y ago
But what about clients that aren't browsers?
- tptacek 3y ago
  What about them? It's not like any of this technology requires a Javascript implementation to run.
  - thayne 3y ago
    But how prevalent is it that other clients verify a cert is in a CT log?
    - tptacek 3y ago
      That's not how CT works! You don't have to go check if a cert is in a log! (How many client/embedded systems do fully recursive DNSSEC verification? Zero!)
      - 3y ago