4

I have huge problems to understand how certificate transparency is different from mechanism like CRL or OCSP which allow to get the status of a certificate by contacting the CA directly.

  • Which domains names are contacted when an application want to check the certificate of a specific server. What is sent to those domains name? (I just know it’s about logs)
  • Since no request are send to CA in any part of the process, why can’t it work if the certificate issuer doesn’t support certificate transparency?
  • Does it only protect against mis‑issued certificates, or can it fully replace OCSP because it protects every case of revoked certificates (for example, from attackers who has stolen private keys on a server)?
  • Does the server, which the client tries to connect to, have to support certificate transparency? (like with OCSP stapling)
Finn
  • 11
  • 4
user2284570
  • 1,402
  • 1
  • 14
  • 33
  • 4
    Some of those questions don't entirely make sense. Read this answer here and see if you want to revise your wording a bit: http://security.stackexchange.com/a/52838/2264 – tylerl Jul 17 '16 at 05:14
  • @tylerl : I can’t see any part of my questions answered in this answer. – user2284570 Jul 17 '16 at 13:12
  • "...by contacting the ca directly." -- it protects against misused trust where the CA failed to do their job. – mgjk Jul 17 '16 at 13:51
  • @mgjk : yes I understand that things like ocsp and crl do that. but from I what understand *(unlike with things like crls)*, no data is fetched from ca when a client want to verify a certificate. – user2284570 Jul 17 '16 at 13:57

1 Answers1

5

Certificate Transparency solves a different problem from CRLs and OCSP.

OCSP and CRLs handle the problem of certificate revocation. The CA is offering resolution for mistakes and bad actions on the part of the CA's users. That is, the CA is assumed to be infinitely trustworthy, but a certificate may need to be revoked because of poor key management or some sort of mistake surrounding the certificate issuance. The infinitely-trusted CA then publishes a list of revoked certificates (the CRL) and uses OCSP to ensure that the clients get the message.

Certificate Transparency on the other hand addresses the fact that CAs are not, in fact, infinitely trustworthy. Misbehaving CAs have previously been able to exploit the fact that certificate signing is not a public event. A certificate may be properly signed but never seen by the public. If a malicious CA signs a certificate for use against a single victim, that victim may be the only client to ever see the certificate, making the malfeasance extremely difficult to detect.

Certificate Transparency moves certificate signing into the public view. Cooperating CAs immediately publish the details of every certificate they sign to one of several public logs maintained outside of the CA's control. If the client requires transparency from the CA in question, then the CA's certificates are not considered valid by the browser unless they were published to the public log. CT is relatively new, though, so enforcement is mostly nonexistent.

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
tylerl
  • 82,225
  • 25
  • 148
  • 226
  • So if a server get it’s private keys stolen, does it means the server maintainers have no way to prevent the use of the compromised certificate through certificate transparency ? – user2284570 Jul 18 '16 at 00:08
  • 3
    No, that's not what certificate transparency is for. Revocation (e.g. CRL, etc.) is what you're looking for. CT does not replace revocation. – tylerl Jul 18 '16 at 01:28
  • So do you mean, there’s no way to mark a certicate as untrusted in the logs ? Also, it doesn’t tells on which server those public logs are stored. – user2284570 Jul 18 '16 at 02:08
  • 2
    You're conflating two different problems. CRL and OCSP answer the question "is this certificate still valid," while CT answers the question "what certificates have been issued for my domain." – tylerl Jul 18 '16 at 02:50
  • But if logs would have entries marking certificates as invalid, it could also replace ᴏᴄꜱᴘ, isn’t it ? – user2284570 Jul 18 '16 at 02:59
  • 2
    That's not its purpose and it is poorly optimized and positioned for that use-case. Just because you *could* doesn't mean you *should*. – tylerl Jul 18 '16 at 04:29
  • Can you include talk about this in the answer please : certificate-transparency.org/known-logs ? Also which is the protocol and port being used ? unencrypted ʜᴛᴛᴘ ? – user2284570 Jul 20 '16 at 08:06