13 ms·

The browsers are probably running the TLS show now

130 points by gdwatson 7y ago

falcolas 7y ago
This is an unexpected (from someone outside the cert industry) development. I know for sure it will have some impact on servers I manage, since we typically purchase 2 year certs, and issue 5 year certs internally. It's also been shown recently that not all companies are great at managing their certs, with notable shutdowns associated with expired certificates. Increasing the frequency of updating certs should be a good thing, but in practice I'm afraid that it will remain a manual project for some time to come.
- Avamander 7y ago
  I don't think it's unexpected. Browsers are _the_ lifeblood of CAs. Unless CAs insert themselves more into the process of code signing, S/MIME, GPG or something like that. They will remain under the heavy influence of browsers.
  - falcolas 7y ago
    The move to 1 year is what was unexpected to me. Browsers taking over the rules around CAs, I agree that it's a natural expansion.
    - Avamander 7y ago
      Browsers did the same thing with Certificate Transparency earlier, unnoticed to many.
      - tialaramex 7y ago
        And this is like that in an important way, for now. Chrome and Safari both have browsers which implement a check such that you need to present enough "qualified" SCTs or the certificate is treated as invalid. The easiest way to pass that check (for certificates you're going to sell or give to webmasters with no clue) is to log a pre-certificate with Google, and with at least one (preferably two) other logs that Apple and Google agree are trustworthy - then bake the SCTs you get back from those logs into the X.509 certificate you're issuing. But these are not Trust Store policy requirements. If you in fact choose to issue (for a number of reasons some CAs do) without logging that's still permitted, the certificates just won't be trusted in Chrome or Safari. You obviously won't get far selling certificates that don't work out of the box in Chrome or Safari to the average punter, but not every customer is the average punter. Apple's declared intention is that Safari will not trust long-lived certificates. But as far as I've seen it is not specified that they would consider a CA which chooses to issue such certificates to violate Apple trust store policy and pursue any sanction or demand revocation. The certificate just doesn't work in Safari. Now, today Mozilla's Firefox is in a different situation from Safari and Chrome as I mentioned elsewhere. Firefox doesn't do a lot of technical enforcement. Mozilla works hard (and in public where we can all see) on policy decisions, but most of them are not enforced in its flagship browser product. Mozilla champions CT logging for example, but a brand new certificate presented with no SCTs works fine in Firefox even though it'd be rejected by Safari and Chrome. Today Firefox doesn't require 825 day lifetime limits, even though those are the limits set in policy, and so following Apple's suggestion wouldn't actually be easy for them, there isn't a line of code (as there is in Chrome for example) that multiples 825 * 86400 = maximum lifetime in seconds, which can be adjusted to say 398 or some other number of days instead of 825.
walrus01 7y ago
Rather than browsers arbitrarily only trusting certain lengths of certs, of much greater concern to me is the number of root CAs trusted by every major browser, some of which are companies under the control of authoritarian states (Turkey, China). Go take a look at how many CAs your browser trusts, and tell me with a straight face that you absolutely trust every one of those CAs to always do the right thing. Certificate issuance transparency helps, but doesn't get rid of the fundamental issue.
- riobard 7y ago
  Was there any proposal to limit which root CAs can sign what TLDs? Or is DANE still a thing?
  - tptacek 7y ago
    It's a thing in that there are recordsets you can create to implement DANE for your zone, and software you can install that will validate those records. It is not a thing in that no mainstream browser will look at DANE, and in that virtually no popular sites (especially in the technology industry) use DANE. DANE is a dead letter standard.
    - riobard 7y ago
      Are there any viable alternatives to DANE, or is this a dead end in general and we're stuck with CA forever?
      - duskwuff 7y ago
        CAA, which many CAs (including Let's Encrypt) already use: https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au...
        riobard 7y ago
        It looks like CAA does not prevent bad CAs at all? A rogue CA can just skip CAA altogether, no?
tptacek 7y ago
Thank Christ. The browsers have been far, far better stewards of the Web PKI than the CA/B Forum (at large) has been, and, in the main, the Web PKI exists to support browser security. That the major browser vendors are getting more muscular about their demands is a major shift: antitrust was a real concern that prevented a lot of important Web PKI stuff from happening sooner. But with Google and Mozilla breaking the largest CAs over documented misissuance, it's possible that concern has finally gone by the wayside.
Spivak 7y ago
I feel like this is a fairly narrow view of the situation. In theory the CA "System" ought to be much bigger than just web traffic since a globally distributed hierarchical database of certs is neat and could be used for all sorts of stuff. The fact that browsers have so much say in how the CAs operate that database makes me think that the public CA system is actually a wildly successful failure. If the public CA system has no other use than to allow someone to securely connect to one of a handful of web browsers then why all the fanfare over just having letting the companies stewarding the browsers run the show entirely?
- tptacek 7y ago
  People say this a lot. But where are the examples of all the "stuff" that would benefit by being linked into a single global PKI? Many of the most important public key crypto tools people actually use --- Signal, SSH and SSH CAs, U2F and WebAuthn, OAuth2 --- have little or no PKI at all.
  - strbean 7y ago
    I think the lack of standardization for a general purpose PKI is the biggest barrier, and the reason why Joe Schmo has no idea what a key pair is.
    - tptacek 7y ago
      You're not really answering my question. Assume the standardization falls into place, and it's all JSON instead of X.509 so that Javascript developers will actually use it. What gets better? What thing out there was just begging to be encrypted by a giant tree shared by the whole Internet?
      - pvg 7y ago
        What gets better? What thing out there was just begging to be encrypted by a giant tree shared by the whole Internet? The Nine Planes of the Internet would be connected. Níðhöggr, Dáinn, Dvalinn, Duneyrr and Duraþrór would be in their ordained places, no longer roaming lost in endless Violation of the Layers.
rossdavidh 7y ago
It is difficult to find a group of companies less trusted to do the right thing than the major browsers (Apple, Google, Microsoft). However, the CAs qualifies, ironically perhaps, as less trusted.
nullc 7y ago
Why is this an improvement? Has there been a rash of stolen certificates or domain name ownership changes? Is having a third party with a cert for a domain you're using for 12 months acceptable in a way that 2 years isn't? It would be nicer if certs could be issued with long lives but required a stapled revalidation with a short time span (daily? weekly?), which would be automatically issued at any time requested unless the certificate was revoked.
- hamandcheese 7y ago
  How does that help vs simply having short lived certificates?
  - nullc 7y ago
    (re-)Validation costs. In theory, if it was just a "not revoked" signature, anyone could obtain it. No access to thorny private keys needed, etc.
- moviuro 7y ago
  > It would be nicer if certs could be issued with long lives but required a stapled revalidation with a short time span (daily? weekly?), which would be automatically issued at any time requested unless the certificate was revoked. That's called OCSP Must-Staple: see https://en.wikipedia.org/wiki/OCSP_stapling https://en.wikipedia.org/wiki/OCSP_stapling, https://github.com/acmesh-official/acme.sh/blob/d437d6fde95dc7368d4fa76c05648a8dd4cbe69e/acme.sh#L6270 https://github.com/acmesh-official/acme.sh/blob/d437d6fde95d..., https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#35-use-ocsp-stapling https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deploym...
- devrand 7y ago
  It reduces risk since revocation is broken. Therefore the potential time that a compromised or misissued cert can be used is reduced by a year.
prepend 7y ago
Does certificate length really matter? It seems like other factors related to certificates are much more important than the ability for a cert to be stolen, reused, and not revoked.
- will4274 7y ago
  Cert revocation for the web is broken, which is why there's been so much emphasis on lifetime. Revocation checks are a privacy leak and reliability degradation and DoS vector, unless you use something like OCSP stapling, which fairly few sites do.
  - dochtman 7y ago
    Mozilla is starting to do CRLite, which should be an improvement here: https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/ https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a...
quotemstr 7y ago
And the browsers, in turn, are controlled by a few big tech companies. Is it a good idea to give those companies control over the trust architecture of the internet? What happens if you get on tech's persona non grata list? Do you not get to use the PKI?
- tialaramex 7y ago
  You'd need to ask Microsoft about that, theirs is (as far as I know) the only Trust Store which demands they get unilateral override for revocation decisions. That is, if Mozilla, or Apple, or Google reach out to Let's Encrypt and say "killtrump.example is not acceptable, revoke their certificate" Let's Encrypt says "No" and nothing happens. But if Microsoft does so, Let's Encrypt can say "Please reconsider this seems like a bad idea" and then Microsoft can say "We've thought about it, revoke" and the choice is only whether Let's Encrypt wants to remain trusted in Microsoft's products. Nobody else has a rule like that, and it isn't a new rule, it's a published part of Microsoft's policy. Microsoft says they use it only to protect Microsoft's customers from phishing and similar attacks. Perhaps that's even true.
tylerl 7y ago
At no point have the browsers ever not been running the whole TLS show. The CAB forum is a useful construct, but its usefulness has a specific place. Imagine a weird little town with 6 people who buy all the groceries and a 60 grocery stores. The stores get together periodically and meet with the 6 shoppers to talk about what the stores should stock. Maybe they even vote. That be a useful set of meetings. But ultimately those 6 customers are going to buy whatever the hell they want to buy, regardless of how the votes went.

130 points by gdwatson 7y ago

This is an unexpected (from someone outside the cert industry) development. I know for sure it will have some impact on servers I manage, since we typically purchase 2 year certs, and issue 5 year certs internally. It's also been shown recently that not all companies are great at managing their certs, with notable shutdowns associated with expired certificates. Increasing the frequency of updating certs should be a good thing, but in practice I'm afraid that it will remain a manual project for some time to come.

Avamander 7y ago
I don't think it's unexpected. Browsers are _the_ lifeblood of CAs. Unless CAs insert themselves more into the process of code signing, S/MIME, GPG or something like that. They will remain under the heavy influence of browsers.
- falcolas 7y ago
  The move to 1 year is what was unexpected to me. Browsers taking over the rules around CAs, I agree that it's a natural expansion.
  - Avamander 7y ago
    Browsers did the same thing with Certificate Transparency earlier, unnoticed to many.
    - tialaramex 7y ago
      And this is like that in an important way, for now. Chrome and Safari both have browsers which implement a check such that you need to present enough "qualified" SCTs or the certificate is treated as invalid. The easiest way to pass that check (for certificates you're going to sell or give to webmasters with no clue) is to log a pre-certificate with Google, and with at least one (preferably two) other logs that Apple and Google agree are trustworthy - then bake the SCTs you get back from those logs into the X.509 certificate you're issuing. But these are not Trust Store policy requirements. If you in fact choose to issue (for a number of reasons some CAs do) without logging that's still permitted, the certificates just won't be trusted in Chrome or Safari. You obviously won't get far selling certificates that don't work out of the box in Chrome or Safari to the average punter, but not every customer is the average punter. Apple's declared intention is that Safari will not trust long-lived certificates. But as far as I've seen it is not specified that they would consider a CA which chooses to issue such certificates to violate Apple trust store policy and pursue any sanction or demand revocation. The certificate just doesn't work in Safari. Now, today Mozilla's Firefox is in a different situation from Safari and Chrome as I mentioned elsewhere. Firefox doesn't do a lot of technical enforcement. Mozilla works hard (and in public where we can all see) on policy decisions, but most of them are not enforced in its flagship browser product. Mozilla champions CT logging for example, but a brand new certificate presented with no SCTs works fine in Firefox even though it'd be rejected by Safari and Chrome. Today Firefox doesn't require 825 day lifetime limits, even though those are the limits set in policy, and so following Apple's suggestion wouldn't actually be easy for them, there isn't a line of code (as there is in Chrome for example) that multiples 825 * 86400 = maximum lifetime in seconds, which can be adjusted to say 398 or some other number of days instead of 825.

walrus01 7y ago

Rather than browsers arbitrarily only trusting certain lengths of certs, of much greater concern to me is the number of root CAs trusted by every major browser, some of which are companies under the control of authoritarian states (Turkey, China). Go take a look at how many CAs your browser trusts, and tell me with a straight face that you absolutely trust every one of those CAs to always do the right thing. Certificate issuance transparency helps, but doesn't get rid of the fundamental issue.

riobard 7y ago
Was there any proposal to limit which root CAs can sign what TLDs? Or is DANE still a thing?
- tptacek 7y ago
  It's a thing in that there are recordsets you can create to implement DANE for your zone, and software you can install that will validate those records. It is not a thing in that no mainstream browser will look at DANE, and in that virtually no popular sites (especially in the technology industry) use DANE. DANE is a dead letter standard.
  - riobard 7y ago
    Are there any viable alternatives to DANE, or is this a dead end in general and we're stuck with CA forever?
    - duskwuff 7y ago
      CAA, which many CAs (including Let's Encrypt) already use: https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au...
      - riobard 7y ago
        It looks like CAA does not prevent bad CAs at all? A rogue CA can just skip CAA altogether, no?

tptacek 7y ago

Thank Christ. The browsers have been far, far better stewards of the Web PKI than the CA/B Forum (at large) has been, and, in the main, the Web PKI exists to support browser security. That the major browser vendors are getting more muscular about their demands is a major shift: antitrust was a real concern that prevented a lot of important Web PKI stuff from happening sooner. But with Google and Mozilla breaking the largest CAs over documented misissuance, it's possible that concern has finally gone by the wayside.

Spivak 7y ago

I feel like this is a fairly narrow view of the situation. In theory the CA "System" ought to be much bigger than just web traffic since a globally distributed hierarchical database of certs is neat and could be used for all sorts of stuff. The fact that browsers have so much say in how the CAs operate that database makes me think that the public CA system is actually a wildly successful failure. If the public CA system has no other use than to allow someone to securely connect to one of a handful of web browsers then why all the fanfare over just having letting the companies stewarding the browsers run the show entirely?

tptacek 7y ago
People say this a lot. But where are the examples of all the "stuff" that would benefit by being linked into a single global PKI? Many of the most important public key crypto tools people actually use --- Signal, SSH and SSH CAs, U2F and WebAuthn, OAuth2 --- have little or no PKI at all.
- strbean 7y ago
  I think the lack of standardization for a general purpose PKI is the biggest barrier, and the reason why Joe Schmo has no idea what a key pair is.
  - tptacek 7y ago
    You're not really answering my question. Assume the standardization falls into place, and it's all JSON instead of X.509 so that Javascript developers will actually use it. What gets better? What thing out there was just begging to be encrypted by a giant tree shared by the whole Internet?
    - pvg 7y ago
      What gets better? What thing out there was just begging to be encrypted by a giant tree shared by the whole Internet? The Nine Planes of the Internet would be connected. Níðhöggr, Dáinn, Dvalinn, Duneyrr and Duraþrór would be in their ordained places, no longer roaming lost in endless Violation of the Layers.

rossdavidh 7y ago

It is difficult to find a group of companies less trusted to do the right thing than the major browsers (Apple, Google, Microsoft). However, the CAs qualifies, ironically perhaps, as less trusted.

nullc 7y ago

Why is this an improvement? Has there been a rash of stolen certificates or domain name ownership changes? Is having a third party with a cert for a domain you're using for 12 months acceptable in a way that 2 years isn't? It would be nicer if certs could be issued with long lives but required a stapled revalidation with a short time span (daily? weekly?), which would be automatically issued at any time requested unless the certificate was revoked.

hamandcheese 7y ago
How does that help vs simply having short lived certificates?
- nullc 7y ago
  (re-)Validation costs. In theory, if it was just a "not revoked" signature, anyone could obtain it. No access to thorny private keys needed, etc.
moviuro 7y ago
> It would be nicer if certs could be issued with long lives but required a stapled revalidation with a short time span (daily? weekly?), which would be automatically issued at any time requested unless the certificate was revoked. That's called OCSP Must-Staple: see https://en.wikipedia.org/wiki/OCSP_stapling https://en.wikipedia.org/wiki/OCSP_stapling, https://github.com/acmesh-official/acme.sh/blob/d437d6fde95dc7368d4fa76c05648a8dd4cbe69e/acme.sh#L6270 https://github.com/acmesh-official/acme.sh/blob/d437d6fde95d..., https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#35-use-ocsp-stapling https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deploym...
devrand 7y ago
It reduces risk since revocation is broken. Therefore the potential time that a compromised or misissued cert can be used is reduced by a year.

prepend 7y ago

Does certificate length really matter? It seems like other factors related to certificates are much more important than the ability for a cert to be stolen, reused, and not revoked.

will4274 7y ago
Cert revocation for the web is broken, which is why there's been so much emphasis on lifetime. Revocation checks are a privacy leak and reliability degradation and DoS vector, unless you use something like OCSP stapling, which fairly few sites do.
- dochtman 7y ago
  Mozilla is starting to do CRLite, which should be an improvement here: https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/ https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a...

quotemstr 7y ago

And the browsers, in turn, are controlled by a few big tech companies. Is it a good idea to give those companies control over the trust architecture of the internet? What happens if you get on tech's persona non grata list? Do you not get to use the PKI?

tialaramex 7y ago
You'd need to ask Microsoft about that, theirs is (as far as I know) the only Trust Store which demands they get unilateral override for revocation decisions. That is, if Mozilla, or Apple, or Google reach out to Let's Encrypt and say "killtrump.example is not acceptable, revoke their certificate" Let's Encrypt says "No" and nothing happens. But if Microsoft does so, Let's Encrypt can say "Please reconsider this seems like a bad idea" and then Microsoft can say "We've thought about it, revoke" and the choice is only whether Let's Encrypt wants to remain trusted in Microsoft's products. Nobody else has a rule like that, and it isn't a new rule, it's a published part of Microsoft's policy. Microsoft says they use it only to protect Microsoft's customers from phishing and similar attacks. Perhaps that's even true.

tylerl 7y ago

At no point have the browsers ever not been running the whole TLS show. The CAB forum is a useful construct, but its usefulness has a specific place. Imagine a weird little town with 6 people who buy all the groceries and a 60 grocery stores. The stores get together periodically and meet with the 6 shoppers to talk about what the stores should stock. Maybe they even vote. That be a useful set of meetings. But ultimately those 6 customers are going to buy whatever the hell they want to buy, regardless of how the votes went.