Hacker News new | ask | show | jobs
by kingkilr 3524 days ago
It's not in this post, but this will only apply to publicly trusted roots, not "enterprise" ones.
2 comments

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)