> Chrom[e/ium] requires that multiple logs provide proof of disclosure, and those logs themselves are subject to additional policies (for example, presently, at least one log MUST be operated by Google).
Is this true for all websites? We did look at that, but thought "CT-certified" (ie, one google one non-google log) requirement is only imposed on EV certs? That has no protection in my opinion since EV has no "memory" as HPKP and Expect-CT do. That is, even if we set up a EV site, the MITM can simply create a non-EV site, which chrome does not require CT-certified, so can easily work with one colluded non-google log. Please don't say that EV cert looks different on browsers so users will notice if changed, I could not believe gmail was not using EV until told so and checked that, so the look of EV can not be an adequate protection.
The above page did mention "This may also be based on site operators signalling that certificates for a particular domain be CT Qualified in order to ensure transparency of the issued certificates." Then what is the procedure for site operators to do that? Is there an application form for Chrome for that purpose? Or is there a setting for this in Expect-CT or something that has "memory"? (Because non-"memory" setting like EV is not helpful as above.) Sorry I can not find any instruction on that.
> If you do not trust your OS vendor to carefully curate those root stores and take action against malfeasance, then you should not trust any of the OS-provided certificates, and should manually curate that list yourself. This functionality already exists on all supported Chrome platforms, and would be a more accurate response to your threat concerns.
Thanks, this is indeed what we are currently trying to do, to write a program to make sure the OS only trusts the CA we use while chrome is running. Still that is cumbersome.
You seem to suggest Chrome has a user setting to permanently only trust the CA list we choose and never worry a future OS update may overwrite that. Is that true? How to do that?
Please forget about my second email above that imagined the MITM can change forged cert every 23 hours and that colluded CT log never actually write that SCT to its log. Certainly the client will notice that according to the proposed CT Gossip and will report. I apologize!
Sorry if I sounds paranoid, but our supports are being mass tortured and killed right now and we know we are not the only group suffering that. In a country that a mere election of village head can be answered by machine guns that jumped to worldwide headlines and a suspect can be located within 7 minutes by facial recognition everywhere as verified by BBC reporters, we really worry about people's lives.
One problem is it also may take a few years to remove a trust. For example, WoSign's problems started to surface early 2015, but WoSign and StarCom were in Chrome's Qualified CT log list until a few days ago, in 2018.
That made things clearer now and sounds assuring! I noticed the latest Expect-CT draft did mention that UA demands CT-qualified to proceed. The strange thing is that "CT-qualified" is not defined anywhere in that draft, nor in the rfc for CT. Are your above statements explicitly documented somewhere? I know one can draw that conclusion by combining the Expect-CT draft with that chrome document on CT qualified and I do trust what you said though.
Still, there appears to be a loophole: since Google CT logs accept certs from any CAs, so the MITM can just obtain SCTs from google and non-google CT logs.
In my understanding the google log will actually log it within an hour, so we can notice the forged cert shortly after that. Still:
1. is there an automatic or fast channel to notify google about its SCT for that forged cert?
2. even if google is notified, google and the site owner can do little, right? This is because:
A. google CT log does not verify how the CA created the cert, the logs even do not verify the domain's CAA DNS record.
B. CT log is add-only, so the google CT log has no way to remove that fault SCT record, and it has no way to flag it to UA.
And the only thing the site owner can do is to beg the criminal to stop doing it, or wait until google to release a new version of chrome removing that CA, right?
So in this sense, the one google one non-google requirement (of CT-qualified) actually has no teeth to prevent or stop MITM, it merely helps expose it, right?
In another word, Expect-CT allows the site operator to choose which CT logs can testify for his domain, but it does not allow the site operator to choose which CAs can testify for his domain. Yet the latter is actually what matters.
> This was already true of HPKP today. If Microsoft added a new CA to the ecosystem, HPKP would be disabled for that new CA until Chrome updated to enforce HPKP for that CA. This is why it is critically important to carefully select what CAs you trust, and what OS you use.
We do trust the (Microsoft Windows) OS. We just don't trust some CA roots it choose to include, which is what Chrome uses.
In our HPKP setup we actually pinned to our server's own key, and we provide PGP-signed TransportSecurity file containing our HPKP record for our users to download, as mentioned above. In my understanding there is no way for Microsoft's CA to spoil our HPKP, right?
> Given the threat model you have shared, you need to look holistically at the system, and that means addressing the issue at the root of trust, not per-application.
Hi Ryan, I just carefully read all your replies, and believe you worry that:
pinning is disabled for locally-installed CAs + the device can come with locally installed CAs
==>> flaws in HPKP or other security setup.
Is that right?
We recommend people to buy PCs of trusted brands from U.S. and other countries. They are not known to pre- or remotely install local CAs without user consent.
So I thought on these devices (desktops/laptops and probably tablets from trusted brands) we can achieve reliable protection, such as HPKP and more.
We also realized that after HPKP is gone, even with Expect-CT and CT-qualified, MITM does not neeed any colluded CT log. It only needs one CA to forge the cert, then it can obtain SCTs from any google-non-google logs, and mount the attack.
Sure it will be discovered quickly, but now there are 5 CAs from one repressive regime in Chrome and the number is increasing over the years, so it's probably not a big deal to lose one every few years.
We will follow your advice to go along the line of removing CAs while Chrome is running.
Chrome provides a user interface, so that people can choose which CAs they trust for which websites, even choose to blankly only whitelist certain CAs, and/or CAs from certain countries.
"whitelist" or "trust" is the keyword, not "blacklist'. Because otherwise "new" CAs can keep spoil the trust, especially because "new" "different" CAs keep coming.
I imagine it will be a terrific feature that people will rave about, and thus further Chrome adoption.
Even people in U.S. may want to use it, because I remember quite some people said why on earth should I trust CAs from countries I never heard of, which can be used to eavesdrop my banks and emails?
Such feature appears to have no security danger and appears to be merely a UI task.
Possible downsides I can think of would be:
1. Corporates need to legally MITM, and this feature may block it.
2. Websites may change CAs, so users will end up unable to visit websites they whitelisted CAs.
Possible solutions to the above problems:
1. like other solutions, locally-installed CAs will be always whitelisted.
2. UI can explain when that happens. It may even suggest possible solutions. Note it also needs to indicate attacking might be going on. Hopefully by displaying the country of that new CA, most situations should be self-evident to users.
Again, If my guess is right, this will be a feature that will be appreciated by numerous people, actually saving lives. It will be a very cool feature that many people rave about, and drive more Chrome adoption.
Of course, it's just my naive suggestion. You certainly have many difficult aspects to balance that I can not imagine. I highly respect your work and decision.
Hi Ryan,
Thanks for the patient and helpful explanations. We will take your advice to disable root certificate update in addition. And I can understand your points of raising the bar for all CAs and that UI is not free (think the success of Apple's minimal UI).
There are two things I want to make sure to understand in what you said:
> the means of determining locally-installed can, on some platforms (most notably, Windows), cause OS-provided CAs to be treated as locally-installed CAs. This means that it's possible for OS updates to disable pinning, which seems to be your concern/threat model.
We trust Microsoft Windows not to intentionally install malware to risk their entire business.
And we have to enable Windows autoupdate to make sure the OS itself is free of vulnerabilities.
> You should do this not just when Chrome is running, but system wide.
In my understanding those CAs are only used when IE/chrome visit the web. Or? Why do I need to worry about them when the browser is not running?
So in this sense, the one google one non-google requirement (of CT-qualified) actually has no teeth to prevent or stop MITM, it merely helps expose it, right?Correct.