4 ms·

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 certif

by 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!)
      - thayne 3y ago
        You have to check that a cert includes a signature that it was logged, or you risk accepting a certificate that wasn't logged.
- agwa 3y ago
  There is not currently a good story for non-browser clients. Generally, non-browser clients don't enforce CT, and those that do are at risk of breaking if they don't stay on the ball with changes to the CT ecosystem. Browser makers can stay on the ball because they are well-resourced and competently staffed; non-browser apps, not so much. Case in point: earlier this year a bunch of CT-enforcing Android apps were suddenly unable to establish any TLS connections because Google stopped publishing a JSON file which these apps should never have been consuming in the first place. There was plenty of warning that this would happen, but the author of the Android CT library was not on the ball, and app developers were not keeping their dependencies up-to-date: https://groups.google.com/g/certificate-transparency/c/38Lr9K46cCA/m/mtwe68NTHwAJ https://groups.google.com/g/certificate-transparency/c/38Lr9... I hope this will get better with time and we will find a way to safely extend the benefits of CT to non-browser apps. I think we're more likely to find success with CT than with DNSSEC, but there is no free lunch.
acqq 3y ago
If I read it correctly, it's in Chrome since the middle of 2018: https://www.ssl2buy.com/wiki/google-will-start-enforcing-certificate-transparency-chrome-68 https://www.ssl2buy.com/wiki/google-will-start-enforcing-cer... In that context, reading the already mentioned Firefox bugzilla communication is even more interesting: https://www.ssl2buy.com/wiki/google-will-start-enforcing-certificate-transparency-chrome-68 https://www.ssl2buy.com/wiki/google-will-start-enforcing-cer... It seems Firefox implementing it or not doesn't change much, in this case, due to its low matket share.

by g_p 3y ago

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!)
    - thayne 3y ago
      You have to check that a cert includes a signature that it was logged, or you risk accepting a certificate that wasn't logged.
agwa 3y ago
There is not currently a good story for non-browser clients. Generally, non-browser clients don't enforce CT, and those that do are at risk of breaking if they don't stay on the ball with changes to the CT ecosystem. Browser makers can stay on the ball because they are well-resourced and competently staffed; non-browser apps, not so much. Case in point: earlier this year a bunch of CT-enforcing Android apps were suddenly unable to establish any TLS connections because Google stopped publishing a JSON file which these apps should never have been consuming in the first place. There was plenty of warning that this would happen, but the author of the Android CT library was not on the ball, and app developers were not keeping their dependencies up-to-date: https://groups.google.com/g/certificate-transparency/c/38Lr9K46cCA/m/mtwe68NTHwAJ https://groups.google.com/g/certificate-transparency/c/38Lr9... I hope this will get better with time and we will find a way to safely extend the benefits of CT to non-browser apps. I think we're more likely to find success with CT than with DNSSEC, but there is no free lunch.

acqq 3y ago

If I read it correctly, it's in Chrome since the middle of 2018: https://www.ssl2buy.com/wiki/google-will-start-enforcing-certificate-transparency-chrome-68 https://www.ssl2buy.com/wiki/google-will-start-enforcing-cer... In that context, reading the already mentioned Firefox bugzilla communication is even more interesting: https://www.ssl2buy.com/wiki/google-will-start-enforcing-certificate-transparency-chrome-68 https://www.ssl2buy.com/wiki/google-will-start-enforcing-cer... It seems Firefox implementing it or not doesn't change much, in this case, due to its low matket share.