9

There seems to be a consensus on the fact that CAs are bad, because we can not really trust them.

Smart people tried to find alternatives, like convergence and perspectives, but they somehow failed to catch on.

Now we have Certificate Transparency, but CAs are still here. Can we get rid of them?

Say for example browsers start to just check if a certificate is logged on a CT log, and stop checking if it is signed by a trusted CA. The domain owner could use a protocol like ACME to log a self signed certificate, and the browser could handle it as trusted.

Could this work?

Could CT logs be enough for the TLS PKI infrastructure of the internet and to establish trust?

11

EDIT IN LIGHT OF COMMENTS:

It sounds like the question you are trying to ask is:

I don't like the all-eggs-in-one-basket nature of CAs, so can we design a new TLS system where each cert needs to be signed by multiple CAs? Can we use CT for this?

Yes, you could design such a system so that multiple CAs would have to work together to issue a fake cert, this raising the bar. It wouldn't change the fundamental nature of needing CAs and needing to trust them, but at least you wouldn't have to trust them individually.

Current TLS implementations can't do this because an X.509 certificate object only has a single CA signature field. Current CT implementations are also not designed for this because CT logs are meant to monitor CAs to make sure they are doing their jobs properly, not to themselves be CAs.

So yes, it's possible to get Let's Encrypt-like functionality with a system like this, but would not be compatible with current technologies. CAs are not ideal, but (for now at least) the world seems happy enough with putting them under a lot of public scrutiny and pulling them from browsers if Google or Mozilla catches them doing something they are not supposed to be.

There are, however, a few trickier points about TLS certificates that I think would be hard to handle:

Revocation

One of the core features of PKI is the ability to contact the CA that issued your certificate and ask them to revoke your certificate. This may be because you had a security breach (hack) and your private key might have been stolen. It might be because you are decommissioning your server and you won't need the cert anymore. Whatever the reason, you want the next time that a browser tries to validate your cert, for the CA to return "NO! Cert Revoked!".

CT logs currently don't track this (it's the job of the CA / OCSP responder). If you went to a multi-CA model, then I guess revoking it on any one CA would do (but then we're back to a single point of failure model where one rogue admin could cause a DOS) so this would need very careful thought.

OV / EV certs

From your question, I take it you only have experience with Domain Validated (DV) certs, these are the ones that Let's Encrypt offers where ownership can be verified by automation. There are two other categories - Organizational Validation and Extended Validation where humans at the CA do extensive record checking, phone calls, and potentially face-to-face meetings before issuing them a cert because with those levels it's not just the website that's being validated, but the entire company that owns it. That's where you see a green bar with the company name embedded in it:

EV cert for bankofamerica.com

OV / EV certs are expensive (several hundred to several thousand dollars per year) but, I assure you, many companies buy them because of the extra assurance. This would be very hard to accomplish in any non-CA PKI model.


PREVIOUS ANSWER

There seems to be a consensus on the fact that CAs are bad, because we can not really trust them.

Fine, but do you have an alternative? CT only? So what's stopping me from CT logging a self-signed cert for google.com and being able to MitM Google?

From your comment:

we could guarantee that only the domain owner can write to a CT log

... so I need to submit a proof that I own the domain, and the CT log server needs to verify this proof before adding it to the CT log? But what if the CT log admins are not trustworthy and slip in one that didn't actually pass the verification? You've just invented CAs again, but now the CA and the person who watches the CA to keep them honest (CT logs) are the same person.

Trustworthy or not, CAs are a necessary part of the PKI system.

  • But what if the CT log admins are not trustworthy and slip in one that didn't actually pass the verification? - Good point. Can we find a solution to this? CT logs are distributed. Domain owners could submit the cert to at least 3 CT logs, and browsers would validate the cert if it is signed by at least 3 logs? Could that be a solution? – Simon Sep 25 '17 at 15:29
  • 1
    @Simon Yeah I think that's ok, but since the CT logs are doing domain validation, let's stop calling them CT logs, and call them instead "distributed CAs (dCA)". So your browser will only trust an https cert if it was "issued by" (aka in the logs of) multiple dCAs. I think that could work, but would be a fairly major change to the fundamental PKI system. As an example, currently offline devices (or devices with no direct internet access) can pin a root CA cert and still validate signatures on PDFs, code, etc. I don't think your model will allow that easily. – Mike Ounsworth Sep 25 '17 at 15:48
  • "at the first sign of trouble" might be quite a bit of an exaggeration... – Mehrdad Sep 26 '17 at 6:11
  • @Mehrdad Ok, I'll change the wording. But I work for a CA and we all live with the constant fear of losing our jobs overnight if Google and Mozilla decide to pull us, so from our end, it seem pretty sword-of-Damocles-y. – Mike Ounsworth Sep 26 '17 at 15:24
5

CT in no way actually replaces the original function of a CA; it just makes it traceable and public.

CA's also have a function to play out in distributing and delegating trust that is not covered by ACME or CT (directly).

The main issues with CA's are that they are costly (or too costly) and that in the past some did not do their work as expected/required — namely, to verify, authorize, and authenticate certification requests and issue certificates to people other than domain owners. CT solves this in part by at least having a traceable source of who created what certificate, and together with their private logs we can retrieve who did said request.

Your proposed solution does not eliminate the risk that is currently there (and as such is not better), namely that of someone impersonating a domain owner and requesting certificates for a domain that is not under their control.

All current replacements for CAs' task of delegating trust (like the web-of-trust) are limited by the bootstrap effect (a.k.a. the chicken-or-the-egg effect) in that you need a larger group of already trusted sites / users to use it.

For returning control to domain controllers and giving them the tools to say what certificates are valid, we have the DANE initiative. This is however highly dependent on DNSSEC, and that is also not widespread enough to make DANE viable as a replacement.

So currently we have no other way to delegate trust than by using CA's to do that job for all of us until the other technologies mature enough and are in use enough to finally replace the CA's.

  • Your proposed solution does not eliminate the risks that [...] someone impersonating a domain owner and requesting certificates for a domain that is not under there control. - If we could guarantee that only the domain owner can write to a CT log, would the proposed solution in your opinion work? – Simon Sep 25 '17 at 14:25
  • there is no basis of trust to begin with. ergo we can not know that the domain owner is trying to write to the CT log. We need a trust anchor to attach something like domain information to an IP. and than we could start validating domains. This requirers a working DNSSEC system in wich all domain providers are fully DNSSEC compliant (hint. there not even close atm.) – LvB Sep 25 '17 at 15:01
  • we can not know that the domain owner is trying to write to the CT log. - letsencrypt uses the acme protocol to validate that the requestor of a certificate owns the domain. We could use a protocol similar to acme to validate that only the owner of the domain can write to the CT log. So we now know that the certificate logged in the CT log is there because the owner of the domain logged it. If that is the case, would the proposed solution in your opinion work? Or is there still something else missing? – Simon Sep 25 '17 at 15:25
  • 2
    @Simon Careful: your model only works if we trust the CT log to be trustworthy and only log if the domain validation checked out. We (the person pointing their browser to some site) can't verify ourselves that the submitter owned the domain at the time of submission. So we have to trust the CT log. It looks like you've just turned the CT log into a CA without solving the underlying problem. – Mike Ounsworth Sep 25 '17 at 15:55
  • @Simon: There is more than just owning a domain. Getting a valid certificate for "g00gle.com" (or whatever typosquat you can think of) is a very powerful enabler for phishing. – Matthieu M. Sep 25 '17 at 16:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.