28

As far as I can tell, a CA is in a position to unilaterally revoke a certificate via the standard mechanisms (CRL, OCSP).

In an increasingly TLS world, what current technology stops a CA shutting down a service they don't like?

Phil Lello
  • 1,122
  • 10
  • 15
  • 1
    The thing is elimination of CA as a role. There's alot of cases of "leaks", "accidents", cloning main CA certificates for traffic inspectors, etc - we must trust each other, but no central point. [Perspectives Projects](http://perspectives-project.org) is a good start at this point – Alexey Vesnin Mar 17 '16 at 00:32
  • Can whoever voted to close for "unclear what your asking" add a comment asking for clarification? It seems pretty clear to me. – Phil Lello Mar 18 '16 at 15:30

3 Answers3

41

Peer pressure, effectively.

There is a multi-layer structure of trust - the CAs trust the browser makers to include their root certificates, and not remove them without reason. The browser manufacturers trust the CAs to only sign certificates for legitimate requests, and implicitly agree to believe this, with the threat of removing the root certificates of CAs that don't actually do this. Website owners trust the CAs to work to keep their root certificates in all popular browser bundles (since manually adding certificates is a massive hurdle to user experience), and the browser manufacturers to keep root certificates in their bundles, unless there is some good reason not to (e.g. the CA asked for them to be removed).

Therefore, if a CA unilaterally revoked a certificate, the browser manufacturers could demand a reason, and, if they found that the reason was insufficient, remove the root certs belonging to that CA. They're unlikely to do so, unless it's a pattern (for example, revoking certificates belonging to sites in favour of a given political party).

Matthew
  • 27,263
  • 7
  • 89
  • 101
  • Also add that all big search engines also have deals with browser makers and CAs. – blankip Mar 16 '16 at 19:31
  • 3
    @blankip Quite seriously, is that a safeguard or a risk? – Phil Lello Mar 16 '16 at 19:57
  • @matthew Interesting that you give the political party example; given the time needed for dialogue between browser vendors and CA, plus time for updates to propogate, there's a risk of abuse in a critical pre-election period. – Phil Lello Mar 16 '16 at 20:09
  • 1
    @PhilLello Yes, although as mentioned by MikeOunsworth in a comment to one of the other answers, "critical" systems like that should use multiple CAs, to be able to deal with issues involving root revocation - imagine a party that secretly generates a bunch of fraudulent CSRs, a CA signs them innocently, the party points out the dodgy signings, and the root cert is revoked - conveniently taking out the opposition party website for no fault of its own... – Matthew Mar 16 '16 at 20:17
  • 12
    Also, who wants to get their cert from a CA that's known to randomly revoke certs? – user253751 Mar 17 '16 at 02:22
  • @immibis This is about _security_. Just because something is unlikely, that's no reason not to care about it. Statistically, an individual on the planet is unlikely to experience targeted MITM (or win the lottery). It still happens. – Phil Lello Mar 17 '16 at 17:21
  • @PhilLello ... what? – user253751 Mar 17 '16 at 18:30
25

By definition, the CA is managing the revocation. In fact, it is a conceptually better way to express thing as: the CA reissues all certificates on a daily basis. The CRL is a kind of data compression: from the point of view of the verifier (say, the Web browser that validates the SSL server's certificate), the certificate is valid as long as the CA says it is OK. To make things lighter, instead of the CA signing a new certificate for each customer every day, the CA signs long-lived certificates and includes only revoked certificates in the CRL. This is an optimization that works under the assumption that most certificates won't be revoked.

Since keeping the certificate afloat is the CA daily job, there is no technology that may prevent the CA from ceasing to do so. What "forces" CA not to revoke certificates on a whim is contract law (you paid the CA for the service, so it is bound by law to maintain that service) and market pressure (if the CA revokes certificates without justification, customers will simply move their business to a competitor).

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 3
    It's amazing how much of our trust in CAs rests on audits and market pressure. As far as we know, the system works though... – Mike Ounsworth Mar 16 '16 at 19:11
  • 8
    "the system works though" - just like the democracies that bring us NSA and GCHQ :) – Phil Lello Mar 16 '16 at 19:41
  • Also worth noting that one argument in favour of 'SSL Everywhere' is the availability of free certs. IANAL, but probably in some jurisdictions, payment is required for to create a contract. – Phil Lello Mar 16 '16 at 20:03
  • "_...it is conceptually better way to express thing as: the CA reissues all certificates on a daily basis_" --- Why on a daily basis? Why not on a hourly basis or every nanosecond? If a certificate has to be verifiable offline it must have a validity time window and the CRL must have it too. – pabouk - Ukraine stay strong Mar 17 '16 at 13:48
  • 2
    @pabouk: I use "daily" as a summary. Each CA sets its CRL renewal policy. However, an hourly CRL validity incurs problems in practice, because the verifying machine may have a slightly incorrect clock (especially around changes to and from daylight saving time). Conversely, if CRL are renewed on a monthly basis, then revocation is rather useless. Most deployed CA thus use CRL renewed daily or weekly, or some in-between rhythm. – Thomas Pornin Mar 17 '16 at 14:10
  • 1
    Also, revocation is usually asynchronous -- a certificate is revoked because of an unexpected condition that has been just detected (say, a key compromise). It does not make a lot of sense to insist on "immediate" revocation for key compromises, since key compromises often take hours or even days to be detected. – Thomas Pornin Mar 17 '16 at 14:11
7

The owner of the site could simply get another certificate from a different CA, and be back up and running.

mti2935
  • 21,098
  • 2
  • 47
  • 66
  • 11
    Further to your point: anybody running a critical service over TLS relying on an external CA should have multiple certs from multiple CAs as a backup plan in case that CA has a breach and has its root cert pulled. The couple hundred dollars to have a cert that you never use is well worth it against the cost of a massive service outage if a CA goes under. – Mike Ounsworth Mar 16 '16 at 19:14
  • 2
    Generally yes, but it might be more problematic if technologies like DANE, HSTS and HPKP are used. – Ctx Mar 16 '16 at 19:44
  • @MikeOunsworth I don't think it is feasible to automate the switch of certificate under those circumstances. (How would your webserver know that a CA has been removed from some major browser?) So I imagine that you will do the switch manually. But in that case it doesn't make a major difference whether the procedure to switch certificate involves a step of acquiring a certificate or not. – kasperd Mar 17 '16 at 07:57
  • @kasperd It matters if you are using HSTS pinning - preload lists include valid certificate signing CAs for given sites – Matthew Mar 17 '16 at 10:40
  • 1
    @kasperd Really? Getting an EV certificate requires TONS of paperwork, phone calls, sometimes physical meetings. It takes days at best. You're willing to let your servers be offline for that long? – Mike Ounsworth Mar 17 '16 at 11:51
  • @MikeOunsworth No. I never suggested that in the first place. – kasperd Mar 17 '16 at 12:28
  • 1
    @kasperd uuuuhhhhhh, then how do you explain your comment "it doesn't make a major difference whether the procedure to switch certificate involves a step of acquiring a certificate or not." ... because in the case of an EV cert, it makes a big difference. – Mike Ounsworth Mar 17 '16 at 12:38
  • @MikeOunsworth And where exactly did you see me suggesting to use an EV certificate? – kasperd Mar 17 '16 at 12:42
  • I see, you're running a cheap webserver. Then fine, do what you want. – Mike Ounsworth Mar 17 '16 at 12:46
  • 1
    @Ctx HSTS only enforces TLS usage, it doesn't specify **which** certificate should be used. HPKP allows for backup key to be pinned. Switching a certificate will be transparent for users in this case. – Dmitry Grigoryev Mar 17 '16 at 14:42
  • 2
    @MikeOunsworth Frankly, most people don't know what an EV certificate is, and don't check for the green box. I agree that having an EV certificate is a good thing, for the small percentage of users that will, but I think most sites could afford to get a cheap non-EV cert while waiting for all of that paperwork to go through. Especially since the chances of your certificate being revoked without warning and being unable to get a replacement is very small. – Patrick M Mar 18 '16 at 06:30