
Chrome Requiring Certificate Transparency in 2017 - edmorley
https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/78N3SMcqUGw/ykIwHXuqAQAJ
======
rfugger
For those wondering what Certificate Transparency is:

[https://www.certificate-transparency.org/what-is-ct](https://www.certificate-
transparency.org/what-is-ct)

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

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

------
mcpherrinm
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
It's not in this post, but this will only apply to publicly trusted roots, not
"enterprise" ones.

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

------
aRationalMoose
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
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
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
_snap_ yes.

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

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

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

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

~~~
pfg
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](http://www.certificate-transparency.org/how-ct-works)

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

------
_nalply
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
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
So let's hope developers don't need to jump through hoops with internal
certificates.

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

------
justinclift
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
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
k, that sounds sensible. :)

