7 ms·

Chrome Requiring Certificate Transparency in 2017

185 points by edmorley 10y ago

mcpherrinm 10y ago
This is very cool. CT is a good step in monitoring for CA misbehavior. My employer's users can be target of phishing attacks, so having all TLS certs in CT is a great source of data to detect phishing sites earlier. I wonder how this will work for "internal" domains issued off a private CA, though. Will this be enforced by chrome, or is this just a CA/B rule?
- kingkilr 10y ago
  It's not in this post, but this will only apply to publicly trusted roots, not "enterprise" ones.
  - JoshTriplett 10y ago
    I hope that's just a "give us time to ease people into it" step. Most private-use-only CAs don't have the infrastructure for CT yet, so requiring it right away would cause a problem. But eventually it needs to happen, and all CAs any browser trusts need to require CT.
    - tptacek 10y ago
      How does that make sense? CT, in the sense we all understand it, would imply that all these enterprises would have to publish their internal hostnames --- names used only within their own networks by their own users --- to public logs.
      - JoshTriplett 10y ago
        The logs don't necessarily have to be public; they just have to be accessible to the browsers browsing sites using those certificates. Requiring CT universally, even for "private" CAs, provides detailed evidence for several kinds of problems, such as various laptop vendors who have pre-installed MITMing proxies. It doesn't prevent those kinds of behaviors, but it makes denials less credible.
        aeijdenberg 10y ago
        Should such a requirement (CT for private CAs) exist, wouldn't the said laptop vendor simply ship embedded SCTs in their fake certs signed by their own fake log key, also baked into Chrome? (that doesn't even need to correspond to a log, at least in the case of static SCT validation) When a laptop vendor is building the device that's being shipped, I don't think it's practical for a browser vendor to be able to expect to win that arms race.
        JoshTriplett 10y ago
        As mentioned in my previous comment: > It doesn't prevent those kinds of behaviors, but it makes denials less credible. Once you start doing more malicious modifications of the browser, it should be more obvious (to both you and anyone observing or doing forensics on your behavior) that you're doing something malicious.
        tptacek 10y ago
        Companies running their own MITM policies for their own devices aren't doing something malicious. This is one of the older Internet trust ideological battles, and those claiming that browsers should add features to make it harder for companies to manage their own equipment have lost it, pretty conclusively. See also: pinning overrides.
        vtlynch 10y ago
        There are a lot of reasons that CT does not make sense for private CAs, and there is no indication that Google will be requiring it any any point.
    - iancarroll 10y ago
      To be clear, these enterprise roots are the ones workplaces install on local machines but are not shipped by the OS. Currently, CT logs have a list of roots that may submit to their log. If you run your own self-signed CA, you cannot (usually) use these logs, and there is a lot of effort and little benefit to running your own log setup. CT tries to protect relying parties from bad issuers, but when the relying party is the same person as the issuer, it is not as beneficial.
    - viraptor 10y ago
      Why do you think it would be useful internally in enterprises? CTs are useful to publish what has been signed. Enterprises already know that (tickets, logs, etc.) And likely they have no intention of publishing CT logs even internally (this reveals names and sizes of new projects)
  - Buge 10y ago
    It appears to be in the post to me >announced plans that publicly trusted website certificates issued in October 2017
- technion 10y ago
  It is a specific component of the CT protocol that the CT server will only accept certificates signed by a CA that it trusts. Google actually launched a separate CT log which allowed certain CAs that aren't usually "trusted", but still only from a specific list: https://security.googleblog.com/2016/03/certificate-transparency-for-untrusted.html https://security.googleblog.com/2016/03/certificate-transpar... Edit: Section 3.1 of the CT RFC: the log SHALL publish a list of acceptable root certificates ... Logs MUST verify that the submitted end-entity certificate or Precertificate has a valid signature chain leading back to a trusted root CA certificate
- Ajedi32 10y ago
  > My employer's users can be target of phishing attacks, so having all TLS certs in CT is a great source of data to detect phishing sites earlier. I'm confused. How does CT help with phishing? I thought its purpose was to detect misbehaving CAs.
dantiberian 10y ago
This is a big step, but my first thought is "How many times will this be pushed back before it is implemented?". I get the impression that the browser vendors have to drag most CA's kicking and screaming into programs that offer greater security.
- technion 10y ago
  Indeed, Comodo view it as positive to make "optional", defeating the purpose: https://blog.instantssl.com/ssl/certificate-transparency-clarification-requirements-comodo-ssl-customers/ https://blog.instantssl.com/ssl/certificate-transparency-cla...
  - dantiberian 10y ago
    To be fair, that was in May 2016 where it was optional, AFAIK today was the first major announcement that CT will be required for all certs in Chrome (although obviously it was always coming). That blog post reads as much about Comodo throwing shade on Symantec as it does about clarifying CT.
- LoSboccacc 10y ago
  More importantly, how secure will the monitor be, and how flexible the monitor system will be? Will Chrome be hard-coded to only trust Google monitors, forcing the whole trust chain to be held at ransom by a single private entity?
  - Natanael_L 10y ago
    If it would, use Chromium and monitors you trust. If Google's own monitors would miss critical events that others didn't, they'd be blamed and shamed. If they didn't share knowledge of critical events which other monitors for whatever reason couldn't detect, they'd be attacked in media. The most plausible outcome is that all major monitors will share data openly. There's no point with a public certificate transparency scheme if they don't. As for the security (ability to report on critical events) of individual monitors, you have to read up on the guarantees that the CT logs can provide.
rfugger 10y ago
For those wondering what Certificate Transparency is: https://www.certificate-transparency.org/what-is-ct https://www.certificate-transparency.org/what-is-ct
cm2187 10y ago
Does anyone knows how it's going to work in practice? I presume google would act as a monitor. Does that mean that chrome will download an exhaustive list of all valid certificates regularly? Or does that mean that chrome will verify the validity of a certificate with google's monitor regularly? On every request? Will google log what IP requested validation for what domain? Then isn't that a massive privacy issue? Or will monitors only be used as a ad hoc control tool, when google wants occasionally to check that a certificate is legitimate?
- xnyhps 10y ago
  A number of SCTs (basically statements signed by qualifying logs that they saw that certificate at time X) must be delivered to the client during the handshake. Those can be embedded in the certs (by using pre-certificates), included in the TLS message directly or as part of a stapled OCSP response.
- pfg 10y ago
  For Chrome, the policy is that you need to deliver SCTs from a certain number of trusted Google- and non-Google log servers. These can be cryptographically verified to have been included in those logs. There's no real privacy issue because this does not involve any real-time queries from the client to those log servers; rather, the SCTs are either embedded in the certificate or delivered via OCSP or a TLS extension. Chrome itself does not act as a monitor, that is left to domain owners. CT guarantees detectability, but only if someone's looking. CT also has a gossip protocol that should help detect misbehaving log servers; I'm not too familiar with that protocol and whether Chrome has implemented any of it. That's an area where I guess there might be some privacy concerns to think about.
  - rkangel 10y ago
    Realistically, Google will run a monitor. But the important thing to realise is that the monitoring process is completely different from the validation process. The fundamental idea is to make all certificate creation public, by putting it in a publicly auditable list. THis allows anyone to check that someone else hasn't given out a certificate for their domain, or for a large chunk of the internet etc. In order to make that work, you have to make all certificates that aren't in that list unusable, and you do that by having the browser check that the certificate it is checking is in the list.
captn3m0 10y ago
There are multiple CT repo, run by various vendors. A very good aggregator that allows searching is https://crt.sh/ https://crt.sh/, which is run by Comodo and tracks multiple CT services. Enter in a domain name, and you can see all certs known for that domain.
_nalply 10y ago
What will happen with certificates from internal CAs? I created a CA. I imported and added it to the trusted roots. Very useful for development.
- pfg 10y ago
  This is only for publicly-trusted CAs. I'm not aware of any plans for local CAs, and I don't think it would make sense to require CT for them.
  - _nalply 10y ago
    So let's hope developers don't need to jump through hoops with internal certificates.
    - cmdrfred 10y ago
      You won't. Self signed certificates ignore HPKP as well in Chrome.
aRationalMoose 10y ago
I have my reservations about google and their omnipresent hunger and capability to consume my personal information(and what that may mean in the future for privacy etc), but they really seem to do a bang-up job when it comes to pushing for reforms to secure and implementing tools that are helpful for securing, the web; browsing and otherwise.
- ocdtrekkie 10y ago
  That's just the natural effect of being both a search and browser monopoly. Either branch of their company is capable of forcing the entire Internet to comply with their will if they want to remain findable and accessible. Of course, there's two sides to that coin.
  - Ajedi32 10y ago
    I think his point was that it's great that they're using that power to push for better security measures which benefit everyone.
    - aRationalMoose 10y ago
      snap yes.
- deleted 10y ago
  [deleted]
justinclift 10y ago
Hmmm, it's unclear if this will impact websites running on intranets. eg Places using their own CA + certs for internal sites That wouldn't be good. :(
- pfg 10y ago
  Local trust anchors have never really been something that CT concerns itself with, and I don't see that changing. For local/internal CAs, nothing is changing with this. Only certificates chaining up to a publicly-trusted root are affected.
  - justinclift 10y ago
    k, that sounds sensible. :)
- deleted 10y ago
  [deleted]

185 points by edmorley 10y ago

This is very cool. CT is a good step in monitoring for CA misbehavior. My employer's users can be target of phishing attacks, so having all TLS certs in CT is a great source of data to detect phishing sites earlier. I wonder how this will work for "internal" domains issued off a private CA, though. Will this be enforced by chrome, or is this just a CA/B rule?

kingkilr 10y ago
It's not in this post, but this will only apply to publicly trusted roots, not "enterprise" ones.
- JoshTriplett 10y ago
  I hope that's just a "give us time to ease people into it" step. Most private-use-only CAs don't have the infrastructure for CT yet, so requiring it right away would cause a problem. But eventually it needs to happen, and all CAs any browser trusts need to require CT.
  - tptacek 10y ago
    How does that make sense? CT, in the sense we all understand it, would imply that all these enterprises would have to publish their internal hostnames --- names used only within their own networks by their own users --- to public logs.
    - JoshTriplett 10y ago
      The logs don't necessarily have to be public; they just have to be accessible to the browsers browsing sites using those certificates. Requiring CT universally, even for "private" CAs, provides detailed evidence for several kinds of problems, such as various laptop vendors who have pre-installed MITMing proxies. It doesn't prevent those kinds of behaviors, but it makes denials less credible.
      - aeijdenberg 10y ago
        Should such a requirement (CT for private CAs) exist, wouldn't the said laptop vendor simply ship embedded SCTs in their fake certs signed by their own fake log key, also baked into Chrome? (that doesn't even need to correspond to a log, at least in the case of static SCT validation) When a laptop vendor is building the device that's being shipped, I don't think it's practical for a browser vendor to be able to expect to win that arms race.
        JoshTriplett 10y ago
        As mentioned in my previous comment: > It doesn't prevent those kinds of behaviors, but it makes denials less credible. Once you start doing more malicious modifications of the browser, it should be more obvious (to both you and anyone observing or doing forensics on your behavior) that you're doing something malicious.
        tptacek 10y ago
        Companies running their own MITM policies for their own devices aren't doing something malicious. This is one of the older Internet trust ideological battles, and those claiming that browsers should add features to make it harder for companies to manage their own equipment have lost it, pretty conclusively. See also: pinning overrides.
      - vtlynch 10y ago
        There are a lot of reasons that CT does not make sense for private CAs, and there is no indication that Google will be requiring it any any point.
  - iancarroll 10y ago
    To be clear, these enterprise roots are the ones workplaces install on local machines but are not shipped by the OS. Currently, CT logs have a list of roots that may submit to their log. If you run your own self-signed CA, you cannot (usually) use these logs, and there is a lot of effort and little benefit to running your own log setup. CT tries to protect relying parties from bad issuers, but when the relying party is the same person as the issuer, it is not as beneficial.
  - viraptor 10y ago
    Why do you think it would be useful internally in enterprises? CTs are useful to publish what has been signed. Enterprises already know that (tickets, logs, etc.) And likely they have no intention of publishing CT logs even internally (this reveals names and sizes of new projects)
- Buge 10y ago
  It appears to be in the post to me >announced plans that publicly trusted website certificates issued in October 2017
technion 10y ago
It is a specific component of the CT protocol that the CT server will only accept certificates signed by a CA that it trusts. Google actually launched a separate CT log which allowed certain CAs that aren't usually "trusted", but still only from a specific list: https://security.googleblog.com/2016/03/certificate-transparency-for-untrusted.html https://security.googleblog.com/2016/03/certificate-transpar... Edit: Section 3.1 of the CT RFC: the log SHALL publish a list of acceptable root certificates ... Logs MUST verify that the submitted end-entity certificate or Precertificate has a valid signature chain leading back to a trusted root CA certificate
Ajedi32 10y ago
> My employer's users can be target of phishing attacks, so having all TLS certs in CT is a great source of data to detect phishing sites earlier. I'm confused. How does CT help with phishing? I thought its purpose was to detect misbehaving CAs.

dantiberian 10y ago

This is a big step, but my first thought is "How many times will this be pushed back before it is implemented?". I get the impression that the browser vendors have to drag most CA's kicking and screaming into programs that offer greater security.

technion 10y ago
Indeed, Comodo view it as positive to make "optional", defeating the purpose: https://blog.instantssl.com/ssl/certificate-transparency-clarification-requirements-comodo-ssl-customers/ https://blog.instantssl.com/ssl/certificate-transparency-cla...
- dantiberian 10y ago
  To be fair, that was in May 2016 where it was optional, AFAIK today was the first major announcement that CT will be required for all certs in Chrome (although obviously it was always coming). That blog post reads as much about Comodo throwing shade on Symantec as it does about clarifying CT.
LoSboccacc 10y ago
More importantly, how secure will the monitor be, and how flexible the monitor system will be? Will Chrome be hard-coded to only trust Google monitors, forcing the whole trust chain to be held at ransom by a single private entity?
- Natanael_L 10y ago
  If it would, use Chromium and monitors you trust. If Google's own monitors would miss critical events that others didn't, they'd be blamed and shamed. If they didn't share knowledge of critical events which other monitors for whatever reason couldn't detect, they'd be attacked in media. The most plausible outcome is that all major monitors will share data openly. There's no point with a public certificate transparency scheme if they don't. As for the security (ability to report on critical events) of individual monitors, you have to read up on the guarantees that the CT logs can provide.

rfugger 10y ago

For those wondering what Certificate Transparency is: https://www.certificate-transparency.org/what-is-ct https://www.certificate-transparency.org/what-is-ct

cm2187 10y ago

Does anyone knows how it's going to work in practice? I presume google would act as a monitor. Does that mean that chrome will download an exhaustive list of all valid certificates regularly? Or does that mean that chrome will verify the validity of a certificate with google's monitor regularly? On every request? Will google log what IP requested validation for what domain? Then isn't that a massive privacy issue? Or will monitors only be used as a ad hoc control tool, when google wants occasionally to check that a certificate is legitimate?

xnyhps 10y ago
A number of SCTs (basically statements signed by qualifying logs that they saw that certificate at time X) must be delivered to the client during the handshake. Those can be embedded in the certs (by using pre-certificates), included in the TLS message directly or as part of a stapled OCSP response.
pfg 10y ago
For Chrome, the policy is that you need to deliver SCTs from a certain number of trusted Google- and non-Google log servers. These can be cryptographically verified to have been included in those logs. There's no real privacy issue because this does not involve any real-time queries from the client to those log servers; rather, the SCTs are either embedded in the certificate or delivered via OCSP or a TLS extension. Chrome itself does not act as a monitor, that is left to domain owners. CT guarantees detectability, but only if someone's looking. CT also has a gossip protocol that should help detect misbehaving log servers; I'm not too familiar with that protocol and whether Chrome has implemented any of it. That's an area where I guess there might be some privacy concerns to think about.
- rkangel 10y ago
  Realistically, Google will run a monitor. But the important thing to realise is that the monitoring process is completely different from the validation process. The fundamental idea is to make all certificate creation public, by putting it in a publicly auditable list. THis allows anyone to check that someone else hasn't given out a certificate for their domain, or for a large chunk of the internet etc. In order to make that work, you have to make all certificates that aren't in that list unusable, and you do that by having the browser check that the certificate it is checking is in the list.

captn3m0 10y ago

There are multiple CT repo, run by various vendors. A very good aggregator that allows searching is https://crt.sh/ https://crt.sh/, which is run by Comodo and tracks multiple CT services. Enter in a domain name, and you can see all certs known for that domain.

_nalply 10y ago

What will happen with certificates from internal CAs? I created a CA. I imported and added it to the trusted roots. Very useful for development.

pfg 10y ago
This is only for publicly-trusted CAs. I'm not aware of any plans for local CAs, and I don't think it would make sense to require CT for them.
- _nalply 10y ago
  So let's hope developers don't need to jump through hoops with internal certificates.
  - cmdrfred 10y ago
    You won't. Self signed certificates ignore HPKP as well in Chrome.

aRationalMoose 10y ago

I have my reservations about google and their omnipresent hunger and capability to consume my personal information(and what that may mean in the future for privacy etc), but they really seem to do a bang-up job when it comes to pushing for reforms to secure and implementing tools that are helpful for securing, the web; browsing and otherwise.

ocdtrekkie 10y ago
That's just the natural effect of being both a search and browser monopoly. Either branch of their company is capable of forcing the entire Internet to comply with their will if they want to remain findable and accessible. Of course, there's two sides to that coin.
- Ajedi32 10y ago
  I think his point was that it's great that they're using that power to push for better security measures which benefit everyone.
  - aRationalMoose 10y ago
    snap yes.
deleted 10y ago
[deleted]

justinclift 10y ago

Hmmm, it's unclear if this will impact websites running on intranets. eg Places using their own CA + certs for internal sites That wouldn't be good. :(

pfg 10y ago
Local trust anchors have never really been something that CT concerns itself with, and I don't see that changing. For local/internal CAs, nothing is changing with this. Only certificates chaining up to a publicly-trusted root are affected.
- justinclift 10y ago
  k, that sounds sensible. :)
deleted 10y ago
[deleted]