7 ms·

So what is the solution to big banks and big CAs? We are just in the process of collectively creating the biggest CA the world ha sver seen.

mrb 10y ago
With CT we could in theory revoke big CAs without impacting sites currently using them.
- geofft 10y ago
  You need the CA to either have been cooperating with CT all along, or have kept a copy of all the certs it ever issued, neither of which an incompetent CA is likely to have done. Symantec, whom one would expect to be one of the more competent CAs out there, cannot do this: https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html https://security.googleblog.com/2015/10/sustaining-digital-c... But Google did require them to use CT for all new certificates, which I think they are enforcing by assuming Symantec won't lie about the issuance date of new certs.
  - ak217 10y ago
    You may not be able to immediately spot a bad CA, but the more major CAs buy in to CT, the easier it is to spot fraudulent certs through fingerprint reporting. SSL clients can then choose to have a side-channel trust revocation mechanism. Once adoption snowballs, the overall level of trust in the system will rise. The other problem is that CAs need to be regionally confined in which TLD CNs they can issue certs for.
    - geofft 10y ago
      > The other problem is that CAs need to be regionally confined in which TLD CNs they can issue certs for. Ryan Sleevi makes a good argument here about why that's bad policy for the internet: https://groups.google.com/d/msg/mozilla.dev.security.policy/pF4aVsF21ww/31qQd3i0ulIJ https://groups.google.com/d/msg/mozilla.dev.security.policy/... There are some good arguments in both directions on that thread. I do happen to like the world in which, say, Let's Encrypt is capable of issuing for any TLD. If we don't think WoSign is good enough for signing .com, we probably shouldn't be exposing .cn users to those attacks, either.
      - ak217 10y ago
        I find the arguments from "it's wrong to recognize borders on the Internet" a bit naive, or impractical. The borders recognize us, and state-sponsored attacks will continue, and have very far-reaching implications. We need better tools to fight them, including this one. I like the discussion in that thread about how to make the scheme reasonably flexible, though. Thanks for the link.
jMyles 10y ago
The certificate system - like the federal reserve - doesn't just fail us in these specifics, but is generally incompatible with the underlying philosophies of distributed technology.
Kadin 10y ago
I think we should just pull the rug out. Site operators need to be more aware of which CAs they're using, and need to feel some of the pain from the failure if they're going to shop for CAs based on anything except price. The behavior of consumers in the certificate marketplace is part of the systemic problem: nobody cares very much about their CA, as long as it causes the little padlock to display correctly (and, more importantly, for warnings to not display) in users' browsers. That's it; beyond that it's a race to the bottom on price. If a few CAs went down in flames and in doing so created a nasty firedrill for all their customers (which, on the scale of firedrills, getting new certs issued really shouldn't be that big of a deal, compared to a zero-day vulnerability in some piece of the server stack, which happens fairly regularly), suddenly there might be an interest in acquiring certificates from somewhere other than the cheapest-possible source.
- joosters 10y ago
  Site operators need to be more aware of which CAs they're using How? I've got no way to judge the security / responsibility of any CA. The amount of money that they charge may have no relation to their behaviour. I don't think anyone has claimed that the CAs who issued wrong certs were charging less than their competitors. You can't blame the CA customers for this.
  - 0x0 10y ago
    Very often, marketing material and the language used for for that is a good indicator on whether a particular service knows their stuff, or if they appear to peddle fluff... :) How CAs respond to issues on these mailing lists and in bugzilla is also pretty telling. In this particular case, there's been concerns raised for several days. An extra vigilant web site operator who sees these discussions might perhaps come to the conclusion that it would be wise to evaluate switching CAs today, perhaps.
    - joosters 10y ago
      Very often, marketing material and the language used for for that is a good indicator on whether a particular service knows their stuff, or if they appear to peddle fluff... :) We're all doomed then! Asides from LetsEncrypt, most CA web pages are full of marketing fluff :) I've just been reading through the mailing list discussion, and from that I agree with you completely, WoSign looks pretty incompetent in their responses. If I had a WoSign certificate, I'd definitely be looking around to get an alternative now. However, that's a bit late for 'people power' to force CAs to act better.
ak217 10y ago
I see two solutions to big CAs. One is to reengineer the CA trust system to delegate limited authority to CAs (e.g. there is no good reason for a CA in the US to be able to sign certificates with Chinese TLD CNs, and vice versa). The second is to build out the Certificate Transparency project to the point where the revocation of trust due to a mis-issued certificate is immediate, widespread, and automatic.
- newjersey 10y ago
  > The second is to build out the Certificate Transparency project to the point where the revocation of trust due to a mis-issued certificate is immediate, widespread, and automatic. I'd love to hear more about this. How would it work? Lets Encrypt gets a lot of flack because their certs need to renew every three months. I can't imagine why bad actors wouldn't immediately try to swamp any system of revocation with requests.
  - ak217 10y ago
    Imagine a new flag for certificates issued by CAs that support CT, indicating that the domain owner (e.g. github.com) intends to continue to only use CT-capable authorities. Any certificate issued for e.g. github.com by any other CA immediately become evidence of malicious conduct attributable directly to that CA, and grounds for automated revocation of trust. I'm not sure what the lifetime of Let's Encrypt certs has to do with this. I'm also not certain how the bad actors would exploit this process, can you explain?
    - pfg 10y ago
      Chrome is experimenting with something called Expect-CT[1], which allows site operators to indicate that only certificates with valid SCTs should be trusted. The implementation is quite similar to HSTS. It's report-only for now, but will probably evolve to something like Require-CT (i.e. CT enforcement) in the future. [1]: https://docs.google.com/document/d/1VDtHiKa5c96ohP_p-V1k6u83fIh952e_szZVypO4AvQ/edit https://docs.google.com/document/d/1VDtHiKa5c96ohP_p-V1k6u83...
bzbarsky 10y ago
A viable solution to big CAs is to have all sites have their certs cross-signed by at least two different CAs. Then any single CA can be revoked without affecting any sites at all. Note that this is also how a new CA is bootstrapped: initially the certs it issues are cross-signed by some existing CA so they work even in UAs that don't have the new CA in their trust root. The obvious drawback is that now sites need certs signed by two CAs, and getting them to use even one CA is hard enough...
- Deregibus 10y ago
  I was thinking the same thing. Assuming it's technically feasible I don't see this as being a huge problem. If your site is important enough that you can't have any downtime due to a CA revocation then you spend the extra time/money up front to get get cross-signed certs. If you don't care, then you just fix the problem when it comes up. If CAs start getting revoked more often then this will just become standard practice.
cm2187 10y ago
The solution for big banks is the orderly failure. Things like bail-in, where a bank is required to be able to go through a flash chapter-11 process over a week end. Or the "living will", basically the bank preparing a contingency plan in advance if it needs to wind down its activity. In the CA world, I would assume this would require a standard protocol across CA to request, renew and transfer certificates from CA providers automatically. A sort of commercial version of the ACME protocol. But that requires lots of infrastructure change not just on the CA side, all servers would have to be updated. This is long overdue anyway. It is currently way too complex to request, install and keep updated a certificate. And there isn't enough competition in this market.
- 0x0 10y ago
  Transferring certificates from an untrustworthy CA makes no sense. Burn the certificates. Websites should just obtain brand new ones from a different CA. If you are running a website that's important to you, this should be at most a one hour operation (or, if politics and procedures delay you in obtaining a new cert, maybe you should have planned ahead and kept two different certificates on hand already)
  - cm2187 10y ago
    By transferring I meant re-issuing automatically a new certificate, not keeping the signature. Of course this requires to re-authenticate the request. And that process has to be automated. A bit like the renewal of the certificate should also be automated.
    - 0x0 10y ago
      No, existing certificates should not be reissued. We can't trust that they were issued to the rightful owner originally by the failed CA. Clients should request new certificates and validate their ownership from scratch. Getting a certificate is an hour's work tops if you are doing the csr dance manually. If you use ACME and letsencrypt it's done in seconds. EV certificates are more work but if this matters to you then perhaps you should source multiple certificates to begin with, or act quickly when a CA is dropped (I'm sure browser vendors will give at least a few days notice) Edit: Maybe I misunderstood you. If you just meant that software in general should offer requesting certificates from any provider, then sure, why not just use ACME. CertBot appears to be designed with multiple providers in mind. But this doesn't really have much to do specificially with the case of CAs being dropped from the root. (At first I got the impression you wanted other CAs to "bail out" certificates from the revoked CA)

mrb 10y ago

With CT we could in theory revoke big CAs without impacting sites currently using them.

geofft 10y ago
You need the CA to either have been cooperating with CT all along, or have kept a copy of all the certs it ever issued, neither of which an incompetent CA is likely to have done. Symantec, whom one would expect to be one of the more competent CAs out there, cannot do this: https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html https://security.googleblog.com/2015/10/sustaining-digital-c... But Google did require them to use CT for all new certificates, which I think they are enforcing by assuming Symantec won't lie about the issuance date of new certs.
- ak217 10y ago
  You may not be able to immediately spot a bad CA, but the more major CAs buy in to CT, the easier it is to spot fraudulent certs through fingerprint reporting. SSL clients can then choose to have a side-channel trust revocation mechanism. Once adoption snowballs, the overall level of trust in the system will rise. The other problem is that CAs need to be regionally confined in which TLD CNs they can issue certs for.
  - geofft 10y ago
    > The other problem is that CAs need to be regionally confined in which TLD CNs they can issue certs for. Ryan Sleevi makes a good argument here about why that's bad policy for the internet: https://groups.google.com/d/msg/mozilla.dev.security.policy/pF4aVsF21ww/31qQd3i0ulIJ https://groups.google.com/d/msg/mozilla.dev.security.policy/... There are some good arguments in both directions on that thread. I do happen to like the world in which, say, Let's Encrypt is capable of issuing for any TLD. If we don't think WoSign is good enough for signing .com, we probably shouldn't be exposing .cn users to those attacks, either.
    - ak217 10y ago
      I find the arguments from "it's wrong to recognize borders on the Internet" a bit naive, or impractical. The borders recognize us, and state-sponsored attacks will continue, and have very far-reaching implications. We need better tools to fight them, including this one. I like the discussion in that thread about how to make the scheme reasonably flexible, though. Thanks for the link.

jMyles 10y ago

The certificate system - like the federal reserve - doesn't just fail us in these specifics, but is generally incompatible with the underlying philosophies of distributed technology.

Kadin 10y ago

I think we should just pull the rug out. Site operators need to be more aware of which CAs they're using, and need to feel some of the pain from the failure if they're going to shop for CAs based on anything except price. The behavior of consumers in the certificate marketplace is part of the systemic problem: nobody cares very much about their CA, as long as it causes the little padlock to display correctly (and, more importantly, for warnings to not display) in users' browsers. That's it; beyond that it's a race to the bottom on price. If a few CAs went down in flames and in doing so created a nasty firedrill for all their customers (which, on the scale of firedrills, getting new certs issued really shouldn't be that big of a deal, compared to a zero-day vulnerability in some piece of the server stack, which happens fairly regularly), suddenly there might be an interest in acquiring certificates from somewhere other than the cheapest-possible source.

joosters 10y ago
Site operators need to be more aware of which CAs they're using How? I've got no way to judge the security / responsibility of any CA. The amount of money that they charge may have no relation to their behaviour. I don't think anyone has claimed that the CAs who issued wrong certs were charging less than their competitors. You can't blame the CA customers for this.
- 0x0 10y ago
  Very often, marketing material and the language used for for that is a good indicator on whether a particular service knows their stuff, or if they appear to peddle fluff... :) How CAs respond to issues on these mailing lists and in bugzilla is also pretty telling. In this particular case, there's been concerns raised for several days. An extra vigilant web site operator who sees these discussions might perhaps come to the conclusion that it would be wise to evaluate switching CAs today, perhaps.
  - joosters 10y ago
    Very often, marketing material and the language used for for that is a good indicator on whether a particular service knows their stuff, or if they appear to peddle fluff... :) We're all doomed then! Asides from LetsEncrypt, most CA web pages are full of marketing fluff :) I've just been reading through the mailing list discussion, and from that I agree with you completely, WoSign looks pretty incompetent in their responses. If I had a WoSign certificate, I'd definitely be looking around to get an alternative now. However, that's a bit late for 'people power' to force CAs to act better.

ak217 10y ago

I see two solutions to big CAs. One is to reengineer the CA trust system to delegate limited authority to CAs (e.g. there is no good reason for a CA in the US to be able to sign certificates with Chinese TLD CNs, and vice versa). The second is to build out the Certificate Transparency project to the point where the revocation of trust due to a mis-issued certificate is immediate, widespread, and automatic.

newjersey 10y ago
> The second is to build out the Certificate Transparency project to the point where the revocation of trust due to a mis-issued certificate is immediate, widespread, and automatic. I'd love to hear more about this. How would it work? Lets Encrypt gets a lot of flack because their certs need to renew every three months. I can't imagine why bad actors wouldn't immediately try to swamp any system of revocation with requests.
- ak217 10y ago
  Imagine a new flag for certificates issued by CAs that support CT, indicating that the domain owner (e.g. github.com) intends to continue to only use CT-capable authorities. Any certificate issued for e.g. github.com by any other CA immediately become evidence of malicious conduct attributable directly to that CA, and grounds for automated revocation of trust. I'm not sure what the lifetime of Let's Encrypt certs has to do with this. I'm also not certain how the bad actors would exploit this process, can you explain?
  - pfg 10y ago
    Chrome is experimenting with something called Expect-CT[1], which allows site operators to indicate that only certificates with valid SCTs should be trusted. The implementation is quite similar to HSTS. It's report-only for now, but will probably evolve to something like Require-CT (i.e. CT enforcement) in the future. [1]: https://docs.google.com/document/d/1VDtHiKa5c96ohP_p-V1k6u83fIh952e_szZVypO4AvQ/edit https://docs.google.com/document/d/1VDtHiKa5c96ohP_p-V1k6u83...

bzbarsky 10y ago

A viable solution to big CAs is to have all sites have their certs cross-signed by at least two different CAs. Then any single CA can be revoked without affecting any sites at all. Note that this is also how a new CA is bootstrapped: initially the certs it issues are cross-signed by some existing CA so they work even in UAs that don't have the new CA in their trust root. The obvious drawback is that now sites need certs signed by two CAs, and getting them to use even one CA is hard enough...

Deregibus 10y ago
I was thinking the same thing. Assuming it's technically feasible I don't see this as being a huge problem. If your site is important enough that you can't have any downtime due to a CA revocation then you spend the extra time/money up front to get get cross-signed certs. If you don't care, then you just fix the problem when it comes up. If CAs start getting revoked more often then this will just become standard practice.

cm2187 10y ago

The solution for big banks is the orderly failure. Things like bail-in, where a bank is required to be able to go through a flash chapter-11 process over a week end. Or the "living will", basically the bank preparing a contingency plan in advance if it needs to wind down its activity. In the CA world, I would assume this would require a standard protocol across CA to request, renew and transfer certificates from CA providers automatically. A sort of commercial version of the ACME protocol. But that requires lots of infrastructure change not just on the CA side, all servers would have to be updated. This is long overdue anyway. It is currently way too complex to request, install and keep updated a certificate. And there isn't enough competition in this market.

0x0 10y ago
Transferring certificates from an untrustworthy CA makes no sense. Burn the certificates. Websites should just obtain brand new ones from a different CA. If you are running a website that's important to you, this should be at most a one hour operation (or, if politics and procedures delay you in obtaining a new cert, maybe you should have planned ahead and kept two different certificates on hand already)
- cm2187 10y ago
  By transferring I meant re-issuing automatically a new certificate, not keeping the signature. Of course this requires to re-authenticate the request. And that process has to be automated. A bit like the renewal of the certificate should also be automated.
  - 0x0 10y ago
    No, existing certificates should not be reissued. We can't trust that they were issued to the rightful owner originally by the failed CA. Clients should request new certificates and validate their ownership from scratch. Getting a certificate is an hour's work tops if you are doing the csr dance manually. If you use ACME and letsencrypt it's done in seconds. EV certificates are more work but if this matters to you then perhaps you should source multiple certificates to begin with, or act quickly when a CA is dropped (I'm sure browser vendors will give at least a few days notice) Edit: Maybe I misunderstood you. If you just meant that software in general should offer requesting certificates from any provider, then sure, why not just use ACME. CertBot appears to be designed with multiple providers in mind. But this doesn't really have much to do specificially with the case of CAs being dropped from the root. (At first I got the impression you wanted other CAs to "bail out" certificates from the revoked CA)