4 ms·

> Certificates signed by TrustCor that were issued before December 1st will still be trusted (for now); certificates issued on December 1st or later will not be

by jannic 4y ago

> Certificates signed by TrustCor that were issued before December 1st will still be trusted (for now); certificates issued on December 1st or later will not be. How does this work? If TrustCor is no longer trusted, what keeps them from creating certificates which claim to be issued before December 1st, even after that date?

AceJohnny2 4y ago
Certificate Transparency [1]: Public logs of issued certificates. [1] https://en.wikipedia.org/wiki/Certificate_Transparency https://en.wikipedia.org/wiki/Certificate_Transparency
- daveoc64 4y ago
  Assuming the untrusted and unreliable CA actually follows the rules and publishes things to the CT log.
  - pimterry 4y ago
    If you don't then the certificates usually aren't usable at all. All modern browsers should reject certs from any root CA if the cert isn't correctly included in a CT log.
    - est31 4y ago
      Firefox doesn't: https://bugzilla.mozilla.org/show_bug.cgi?id=1281469 https://bugzilla.mozilla.org/show_bug.cgi?id=1281469 (But it's the only browser that doesn't support CT)
    - DethNinja 4y ago
      Do modern browsers check this though? It would introduce a large latency to each request, I bet none of the browsers do that. Moreover, Chrome removed the browser extension API for TLS certificate details, so it is not even possible to do CT log verification via extensions. Only way to do CT log verification would be by customising an existing TLS MITM software. As far as I’m aware no such solution exists at the moment. Certificate system is actually rather insecure, and although solutions are possible to develop, nobody has taken time to do it.
      - nmjohn 4y ago
        > Do modern browsers check this though? It would introduce a large latency to each request, I bet none of the browsers do that. Yes they do. Only firefox doesn't.
      - siebenmann 4y ago
        Chrome and Safari require that TLS certificates include cryptographic promises of future log inclusion ('SCTs') from N trusted CT logs. As far as I know, neither of them actually contact the log's API endpoints to make sure that this has gone through, but in practice IMHO it's not much of a security gap for various reasons.
        jsmith45 4y ago
        The SCT is a promise of the log to include the certificate (or pre-certificate, which is used for embedded SCTs) within a time window. The only way a cert could have a valid embedded SCT is to have actually sent the pre-certificate to the log in question. The SCT contains a signature over some log related information (which is also included in the SCT itself) and everything in the pre-certificate except the signature and poison (which means everything in the real cert, except the SCTs and signature). This means the browser can reconstruct the signed data and verify the signature. Thus the only way to have a valid SCT and not have at least the pre-certificate show up in the log (after the merge delay) is if the log operator/software messed up. For transparency purposes, a pre-certificate is basically as good as a full certificate, although if I recall correctly the CAs are also supposed to submit the full certificates too.
pimterry 4y ago
> what keeps them from creating certificates which claim to be issued before December 1st, even after that date? See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/WJXUELicBQAJ https://groups.google.com/a/mozilla.org/g/dev-security-polic... for the actions proposed depending on how the TrustCor situation plays out: > If there is reason to believe that the CA has mis-used certificates or the CA backdates certificates to bypass the distrust-after settings, then remove the root certificates from Mozilla’s root store in an expedited timeline, without waiting for the end-entity certificates to expire. Right now, they're being slowly removed for poor behaviour in general, but there's no direct evidence of abuse of CA powers. If any clear evidence of that appears in future, including backdating certificates, then they'll be completely removed from the trust store immediately.

by jannic 4y ago

AceJohnny2 4y ago

Certificate Transparency [1]: Public logs of issued certificates. [1] https://en.wikipedia.org/wiki/Certificate_Transparency https://en.wikipedia.org/wiki/Certificate_Transparency

daveoc64 4y ago
Assuming the untrusted and unreliable CA actually follows the rules and publishes things to the CT log.
- pimterry 4y ago
  If you don't then the certificates usually aren't usable at all. All modern browsers should reject certs from any root CA if the cert isn't correctly included in a CT log.
  - est31 4y ago
    Firefox doesn't: https://bugzilla.mozilla.org/show_bug.cgi?id=1281469 https://bugzilla.mozilla.org/show_bug.cgi?id=1281469 (But it's the only browser that doesn't support CT)
  - DethNinja 4y ago
    Do modern browsers check this though? It would introduce a large latency to each request, I bet none of the browsers do that. Moreover, Chrome removed the browser extension API for TLS certificate details, so it is not even possible to do CT log verification via extensions. Only way to do CT log verification would be by customising an existing TLS MITM software. As far as I’m aware no such solution exists at the moment. Certificate system is actually rather insecure, and although solutions are possible to develop, nobody has taken time to do it.
    - nmjohn 4y ago
      > Do modern browsers check this though? It would introduce a large latency to each request, I bet none of the browsers do that. Yes they do. Only firefox doesn't.
    - siebenmann 4y ago
      Chrome and Safari require that TLS certificates include cryptographic promises of future log inclusion ('SCTs') from N trusted CT logs. As far as I know, neither of them actually contact the log's API endpoints to make sure that this has gone through, but in practice IMHO it's not much of a security gap for various reasons.
      - jsmith45 4y ago
        The SCT is a promise of the log to include the certificate (or pre-certificate, which is used for embedded SCTs) within a time window. The only way a cert could have a valid embedded SCT is to have actually sent the pre-certificate to the log in question. The SCT contains a signature over some log related information (which is also included in the SCT itself) and everything in the pre-certificate except the signature and poison (which means everything in the real cert, except the SCTs and signature). This means the browser can reconstruct the signed data and verify the signature. Thus the only way to have a valid SCT and not have at least the pre-certificate show up in the log (after the merge delay) is if the log operator/software messed up. For transparency purposes, a pre-certificate is basically as good as a full certificate, although if I recall correctly the CAs are also supposed to submit the full certificates too.

pimterry 4y ago

> what keeps them from creating certificates which claim to be issued before December 1st, even after that date? See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/WJXUELicBQAJ https://groups.google.com/a/mozilla.org/g/dev-security-polic... for the actions proposed depending on how the TrustCor situation plays out: > If there is reason to believe that the CA has mis-used certificates or the CA backdates certificates to bypass the distrust-after settings, then remove the root certificates from Mozilla’s root store in an expedited timeline, without waiting for the end-entity certificates to expire. Right now, they're being slowly removed for poor behaviour in general, but there's no direct evidence of abuse of CA powers. If any clear evidence of that appears in future, including backdating certificates, then they'll be completely removed from the trust store immediately.