Chrome Requiring Certificate Transparency in 2017 | Hacker News Reader

Chrome Requiring Certificate Transparency in 2017

groups.google.com

185 pointsedmorley44 comments

For those wondering what Certificate Transparency is:

https://www.certificate-transparency.org/what-is-ct

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.

Indeed, Comodo view it as positive to make "optional", defeating the purpose:

https://blog.instantssl.com/ssl/certificate-transparency-cla...

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.

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?

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.

Browsers will make their own policies regarding which log servers they'll trust, similar to the CA system. Google's policy for log server operators is documented here[1] and is fairly strict - a number of third-party log servers have been removed in the past due to non-compliance. Chrome's policy for what they consider a "CT qualified" certificate can be found here[2] and asks for SCTs from at least one Google and non-Google-operated log server.

[1]: https://www.chromium.org/Home/chromium-security/certificate-...

[2]: https://a77db9aa-a-7b23c8ea-s-sites.googlegroups.com/a/chrom...

That's the real trick in a trust-based system. We have multiple CAs to prevent single points of failure or control, but now that there are so many CAs, and well-known powerful actors seeking to exploit CAs, there's a need for more oversight and enforcement, which leads back to a central authority and a single point of failure and control.

Chromium has a CT policy in place, and the Google CT team and the Chromium team who make inclusion decisions are separate, so currently this is working well. There are a number of non-google logs currently included.

The issue with mandating CT isn't the CAs. CAs are generally supportive of CT. The big push back comes from corporations and the fact that CT logging also logs any of their internally issued SSL Certificates if it was issued by a public Certificate Authority.

So any internal domain and domain hierarchy is exposed to the general public who queries for the organization's domain in the CT log.

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?

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-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

It's not in this post, but this will only apply to publicly trusted roots, not "enterprise" ones.

It appears to be in the post to me

>announced plans that publicly trusted website certificates issued in October 2017

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.

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.

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.

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.

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.

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.

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.

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.

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)

> 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.

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.

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.

I think his point was that it's great that they're using that power to push for better security measures which benefit everyone.

snap yes.

There are multiple CT repo, run by various vendors. A very good aggregator that allows searching is 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.

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?

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.

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.

Hence whoever maintains this list will be able to observe the traffic on a third party website.

No, that's not a valid conclusion. Browsers do not query log servers in real-time whenever they see a new certificate. Rather, servers send SCTs which are "a promise to add the certificate to the log within some time period"[1]. Comparatively speaking, think of this more like OCSP stapling as opposed to real-time OCSP queries.

Auditors and CT gossiping are responsible for ensuring that the log servers are not misbehaving.

[1]: http://www.certificate-transparency.org/how-ct-works

Correct. What might be interesting to add to this: you can't query Certificate Transparency servers by certificate. You can query them by index or by using an SCT hash, but if you want a definitive answer to "when was this certificate first logged?" you'll need to process the log completely. CT is not designed for live-checking of certificates, only for monitoring by domain owners.

That is an interesting point.

I suppose a client could act more like a monitor and download chunks of the log at a time, thereby hiding which site in the chunk they were interested in. That wouldn't be hugely efficient though.

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.

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.

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.

So let's hope developers don't need to jump through hoops with internal certificates.

You won't. Self signed certificates ignore HPKP as well in Chrome.

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. :(

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.

k, that sounds sensible. :)

Reply on news.ycombinator.com