3 ms·

Can someone explain in a nutshell what CT is, and how does it help security for the average user?

djaychela 2y ago
There's a site for it here (linked 2 levels deep from the original article): https://certificate.transparency.dev/ https://certificate.transparency.dev/
perching_aix 2y ago
CT is an append-only distributed log for certificate issuances. People and client software can use it to check if a certificate is being provided by a trusted CA, if it has been revoked, or is being provided by multiple CAs (the latter possibly indicating CA compromise). CA meaning Certificate Authority, the organizations that issue certificates. This provides a further layer of technological defense to attempting the mitigation of your web browser traffic being intercepted and potentially tampered with. In practice a regular person is unlikely to run into this, because web PKI is mostly working as expected, so there's no reason for the edge cases to happen en masse. This change is covering one such edge case. No idea how the typical corporate interception solutions (e.g. Zscaler) circumvent it in other browsers where this check has long been implemented.
- q2dg 2y ago
  Will Mitmproxy stop working?
  - notpushkin 2y ago
    Chrome treats certificates added by user as not requiring CT: https://github.com/mitmproxy/mitmproxy/discussions/5720 https://github.com/mitmproxy/mitmproxy/discussions/5720
    - zinekeller 2y ago
      And to wit, Firefox too: > Setting this preference to 2 causes Firefox to enforce CT for certificates issued by roots in Mozilla's Root CA Program.
  - perching_aix 2y ago
    I believe so. You'll need to disable CT enforcement / or add your SPKI hash to the ignore list in the browser settings temporarily to get it working. [0] I guess this is also how corporations get around this issue? Still unsure. [0] https://wiki.mozilla.org/SecurityEngineering/Certificate_Transparency https://wiki.mozilla.org/SecurityEngineering/Certificate_Tra...
    - mcpherrinm 2y ago
      No. CT is only required for public CAs. You only need those browser policy settings if you’re using a public CA without CT.
      - perching_aix 2y ago
        I'd imagine this is why certs that terminate in root certificates manually added to the trust store will work fine then [as stated by other comments]?
        mcpherrinm 2y ago
        Right, any CA you add yourself that isn’t part of what Mozilla ships isn’t considered a publicly trusted CA.
tgsovlerkhgsel 2y ago
It's a public, tamper-proof log of all certificates issued. When a CA issues a certificate, it sends a copy to at least two different logs, gets a signed "receipt", and the receipt needs to be included in the certificate or browsers won't accept it. The log then publishes the certificate. This means that a CA cannot issue a certificate (that browsers would accept) without including it in the log. Even if a government compels a CA, someone compromises it, or even steals the CAs key, they'd have to either also do the same to two CT logs, or publish the misissued certificate. Operators of large web sites then can and should monitor the CT logs to make sure that nobody issued a certificate for their domains, and they can and will raise hell if they see that happen. If e.g. a government compels a CA to issue a MitM certificate, or a CA screws up and issues a fake cert, and this cert is only used to attack a single user, it would have been unlikely to be detected in the past (unless that user catches it, nobody else would know about the bad certificate). Now, this is no longer possible without letting the world know about the existence of the bad cert. There are also some interesting properties of the logs that make it harder for a government to compel the log to hide a certificate or to modify the log later. Essentially, you can store a hash representing the content of the log at any time, and then for any future state, the log can prove that the new state contains all the old contents. The "receipts" mentioned above (SCTs) are also a promise to include a certificate by a certain time, so if a log issues an SCT then publishes a new state more than a day later that doesn't include the certificate, that state + the SCT are proof that the log is bad.
- brookst 2y ago
  Thanks for the great explanation of both tech design and real world benefits!
- xg15 2y ago
  > Operators of large web sites then can and should monitor the CT logs to make sure that nobody issued a certificate for their domains, and they can and will raise hell if they see that happen. The tech is definitely an improvement from the previous situation, but I've always wondered about this step: Suppose you've found an unauthorized certificate for your site in the log (and you're not Google, Apple or Microsoft). Then what? What can you actually do about it?
cyberax 2y ago
Basically, a git repository for all the issues certificates.

There's a site for it here (linked 2 levels deep from the original article): https://certificate.transparency.dev/ https://certificate.transparency.dev/

perching_aix 2y ago

CT is an append-only distributed log for certificate issuances. People and client software can use it to check if a certificate is being provided by a trusted CA, if it has been revoked, or is being provided by multiple CAs (the latter possibly indicating CA compromise). CA meaning Certificate Authority, the organizations that issue certificates. This provides a further layer of technological defense to attempting the mitigation of your web browser traffic being intercepted and potentially tampered with. In practice a regular person is unlikely to run into this, because web PKI is mostly working as expected, so there's no reason for the edge cases to happen en masse. This change is covering one such edge case. No idea how the typical corporate interception solutions (e.g. Zscaler) circumvent it in other browsers where this check has long been implemented.

q2dg 2y ago
Will Mitmproxy stop working?
- notpushkin 2y ago
  Chrome treats certificates added by user as not requiring CT: https://github.com/mitmproxy/mitmproxy/discussions/5720 https://github.com/mitmproxy/mitmproxy/discussions/5720
  - zinekeller 2y ago
    And to wit, Firefox too: > Setting this preference to 2 causes Firefox to enforce CT for certificates issued by roots in Mozilla's Root CA Program.
- perching_aix 2y ago
  I believe so. You'll need to disable CT enforcement / or add your SPKI hash to the ignore list in the browser settings temporarily to get it working. [0] I guess this is also how corporations get around this issue? Still unsure. [0] https://wiki.mozilla.org/SecurityEngineering/Certificate_Transparency https://wiki.mozilla.org/SecurityEngineering/Certificate_Tra...
  - mcpherrinm 2y ago
    No. CT is only required for public CAs. You only need those browser policy settings if you’re using a public CA without CT.
    - perching_aix 2y ago
      I'd imagine this is why certs that terminate in root certificates manually added to the trust store will work fine then [as stated by other comments]?
      - mcpherrinm 2y ago
        Right, any CA you add yourself that isn’t part of what Mozilla ships isn’t considered a publicly trusted CA.

tgsovlerkhgsel 2y ago

It's a public, tamper-proof log of all certificates issued. When a CA issues a certificate, it sends a copy to at least two different logs, gets a signed "receipt", and the receipt needs to be included in the certificate or browsers won't accept it. The log then publishes the certificate. This means that a CA cannot issue a certificate (that browsers would accept) without including it in the log. Even if a government compels a CA, someone compromises it, or even steals the CAs key, they'd have to either also do the same to two CT logs, or publish the misissued certificate. Operators of large web sites then can and should monitor the CT logs to make sure that nobody issued a certificate for their domains, and they can and will raise hell if they see that happen. If e.g. a government compels a CA to issue a MitM certificate, or a CA screws up and issues a fake cert, and this cert is only used to attack a single user, it would have been unlikely to be detected in the past (unless that user catches it, nobody else would know about the bad certificate). Now, this is no longer possible without letting the world know about the existence of the bad cert. There are also some interesting properties of the logs that make it harder for a government to compel the log to hide a certificate or to modify the log later. Essentially, you can store a hash representing the content of the log at any time, and then for any future state, the log can prove that the new state contains all the old contents. The "receipts" mentioned above (SCTs) are also a promise to include a certificate by a certain time, so if a log issues an SCT then publishes a new state more than a day later that doesn't include the certificate, that state + the SCT are proof that the log is bad.

brookst 2y ago
Thanks for the great explanation of both tech design and real world benefits!
xg15 2y ago
> Operators of large web sites then can and should monitor the CT logs to make sure that nobody issued a certificate for their domains, and they can and will raise hell if they see that happen. The tech is definitely an improvement from the previous situation, but I've always wondered about this step: Suppose you've found an unauthorized certificate for your site in the log (and you're not Google, Apple or Microsoft). Then what? What can you actually do about it?

cyberax 2y ago

Basically, a git repository for all the issues certificates.