Viable solution after HPKP in dictator regime with endless new CAs and which kill innocent people

[paull...@gmail.com]

Hi Chromium/blink developers,

We heard about chrome's plan to deprecate HPKP in chrome, but just realized that the recommended alternative, Expect-CT, won't help in our situation.  Therefore we are looking for your help on possible solutions.

First I need to apologize, we should have brought this up last November when you were discussing this.  We thought chrome has proposed alternative so nothing to worry, but really we should have tried to contribute more actively.

Background

We are a human rights group (roughly speaking) with supporters worldwide including many in U.S.  We have many supporters living in a dictator regime, where many of our supporters have been persecuted to death and many many more jailed and tortured.  That regime, where google etc are blocked, has a keen interest in intercepting communication of our supporters in and out of that regime.  We have relied on HPKP to prevent that successfully.

What will happen with Expect-CT

We just learned that Expect-CT can not prevent interception.  Specifically, even if we configured Expect-CT and a user visited our website before.  If a website fakes our certificate with a CA of that regime and submit to a cooperating CT log of that regime, and mounts MITM, here is what can happen:

1. within 24 hours, the CT log can withhold publishing that fake cert.  So we can't tell the existence of the fake cert.
2. right before end of 24 hours, that CT log publishes that cert.  We then start to hear of that fake cert after some delay.
3. we then need to beg that CA to revoke that fake cert.  That CA can ignore our request as long as they don't care their future existence.
4. the MITM can only stop if google published a new chrome removing that CA, or until/if that CA removes that fake cert.

In short, for at least 24 hours and up to indefinite number of days, we are subject to MIT with no way to actually stop it.

Consequences

During that time window, many people can be confirmed by that regime and subsequently jailed, tortured, many killed.

Issues not addressed with Expect-CT

1. it can not stop MITM, so many people in dictator regimes can be killed due to that.

2. this is important, certain dictator regime ships new, "different", CAs every fews years into the root trust store of browsers.  So losing a CA (and CT log) is not a problem to them.  And they can do this every few years.

Heightened Arm Race, or a losing war?

CT resolved the problem of making sure to identify the existence of rogue certs and to hold CAs accountable.  Attackers can only mount MITM at the price of compromising or creating a CA.  

HOWEVER, one tactics a resourceful regime can do and is doing, is to pump endlessly new, "different", CAs into the root trust store of browsers, effectively erasing the gain of CT.  That dictatorship regime can mount MITM any time at the price of losing one of its multiple CAs (and possibly logs) which it can readily replace in another couple years.

HPKP had once created a sharp edge for defenders preventing that.  

But now chrome trusts more than ever number of CAs from certain dictator regime (surely with more to come when needed), which creates a ready-to-use system to mount MITM as above every few years with no problem. 

And CT has to live with that.

So with the disappearance of HPKP in sight,  we appear to be in a worse situation than ever.

Possible solutions we thought of

The obvious solution is to keep using Firefox.  But after chrome removes HPKP, there is no guarantee how long Firefox will keep HPKP.  We can not wait until that time to ask for help.  And with shrinking market share of Firefox, we need to keep flexible.

Since we are pretty sure which CAs we will use such as letsencrypt etc, we can develop a chrome extension so that users can configure which CAs they will trust for which domains they care, then the extension can detect the upcoming website and CA, and prevent the https if they don't match the user's whitelist.  But we learned that chrome does not provide API to tell the upcoming CA before establishing https connection, nor an API to prevent https connection.

We may develop a small software to remove all but our trusted CA roots from the Windows system before launching chrome, then restore the Windows CA roots after exiting chrome.  This is currently the most viable option to us.  Problem is we can't do that on mobile devices without rooting, and rooting is too difficult or impossible to many users.

Possible solutions we can see that Chrome may help

1. keep HPKP

2. allow websites to add to that static PKP list since it will be kept indefinitely, so people risking lives can enjoy the same protection of google.  One reason to remove HPKP is that websites risks losing connection if configured improperly etc.  But in our situation, that's nothing compared to losing many people's lives.

3. chrome provides interface to allow people to configure which CAs they trust for certain websites.

4. or chrome opens API to allow third party to develop extensions which can tell upcoming website and its cert, and allow extensions to prevent the https connection based on that.

Or what better idea you can suggest?



Sincerely,
Paul Lee

[paull...@gmail.com]

In fact, with the help of a CA and a CT log, another thing the attacker(s) can do is, the CT log never publishes the fake cert, and the attacking website uses a new fake cert every 23 hours.

Reporting is not exactly helpful in MITM since the attacker(s) will likely block all reporting urls and feedback route.

In this way, we may never know a website is MITM'ed for many many days.

In case caught, the dictator regime simply delivers a "different" CA and CT log into browsers and repeat the attack, every few years.

So CT and Expect-CT do not appear helpful in the current situation that a dictator regime can pump endless CAs and CT logs into browsers.


Paul Lee

[rsl...@chromium.org]

Thanks for reaching out with your concerns about the deprecation of HPKP. I wanted to reply to some of the concerns you raised, so that you and your members can be appropriately secured. I will try to address your attack concerns first, discuss a little bit about the HPKP implementation in Chrome today, and then end with actionable next steps you and your members can take to stay safe.

There are a few attack scenarios you raised that deserve addressing explicitly.

You raised a concern about repressive regimes adding CAs for the express purpose of MITM. We take CA security quite seriously, as shown through our past actions to limit or remove trust in CAs that violate our expectations and users security — such as DigiNotar, India CCA, CNNIC, WoSign/StartCom, and most recently, Symantec. If you have information or evidence of malfeasance or misbehaviour, I encourage you to file a Security Bug using the template at https://bugs.chromium.org/p/chromium/issues/entry?template=Security+Bug with details.

Note that the addition of new CAs is not an easy process — it typically takes years — and, in conjunction with efforts led by Mozilla, we encourage and actively support efforts to publicly review and discuss every new CA being proposed. If you have reason to believe there are new CAs being stood up for illegitimate purposes, I encourage you to participate in those discussions, on the mozilla.dev.security.policy mail list — https://lists.mozilla.org/listinfo/dev-security-policy

You also spoke about the risk of compromising a Certificate Transparency log. However, a critical piece of Certificate Transparency is that logs are designed not to be single points of failures in the same way that the CAs are. 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). The design of the system is specifically to preclude a CA from colluding with a single log, and at present, would also require collusion with Google to prevent discovery of a certificate. If you trust Google, which is implicit in using Chrome, then you’re no worse off. If you don’t trust Google (and therefore run Chromium instead of Chrome), then you may not have had HPKP enabled to begin with (and certainly would not have had the static HPKP list).

This leads into the next point, which is discussing Chrom[e/ium]’s HPKP implementation. As I mentioned, static HPKP has never been enabled for Chromium users, as it’s simply not safe to bake in static pins without a reliable and consistent means of updating — which Google Chrome provides, but Chromium distributions do not. We don’t enable static pinning on Chrome for Android and iOS for the same reason. Chrom[e/ium] on iOS uses Apple’s provided network stack, and Apple does not implement pinning.

It’s also important to note that pinning is disabled for locally-installed CAs — which means if someone has access to your device to install a CA, or to coerce the installation, they can bypass pinning. Similarly, on some platforms, the ability to reliably detect and distinguish between these two types of CAs is limited, and when the signal is not strong, we opt to treat it as locally installed, thereby disabling pinning.

Thinking more broadly, however, you’re also at risk if you ever access any of this sensitive information through unpinned connections. As noted in the Intent To Deprecate email, unless the Application Developer is explicitly managing their trust store, then they should not be pinning either. Most commonly, this means mobile apps SHOULD NOT pin, since managing a trust store is complex, as you note, and it’s the kind of complexity that scales well for platform/browser developers, but less so for hundreds of thousands of mobile apps. Thus, if you or your users use such apps to access the data that you hope key pinning protects, you’re also at risk.

Your concern may be predicated on a problematic threat model. As you note, if there are CAs you do not trust, you should remove those CAs from your system and distrust them. 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. In short, in a life-or-death situation, you shouldn’t use a device that trusts a root CA that is owned by the entity that is targeting you — and solving that requires client-side action.

I realize this may sound unsatisfying — but hopefully provides you ideas on how to best protect yourself and your users, in a way that’s aligned with your threats.

[paull...@gmail.com]

Thank you for taking time to provide the explanations, and for pointing to some possible options.  We really appreciate!  Your reply may have pointed to some options and we hope you can clarify as in the following.

To help you understand, we have been using the Chrome browser for Windows.  We certainly trust google, that's why we are here :-)  We understand HPKP is first use first trust, so we prepared chrome's TransportSecurity file with our pin expiring long time in the future built-in (thankfully it appears that there is no upper limit on that), and ask our supporters to download from our website.  It also comes with our PGP signature, and hopefully they have already downloaded our PKP public key years ago.  So it pretty much created a bulletproof solution (literally, considering the consequences).

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

Thanks for pointing out the difficulty on mobile devices.  Yeah it's hard.  We don't know what to do about that now.

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!

Although as I read that draft-ietf-trans-gossip-05 and found the following:

> If an STH has attempted to be resolved to a newer STH via a consistency proof multiple times, and each time has failed, a client MAY share the STH with an "Auditor of Last Resort" even if the STH in question is no longer within the validity window. ... The Auditor of Last Resort itself represents a point of failure and privacy concerns, so if implemented, it SHOULD connect using public key pinning and not consider an item delivered until it receives a confirmation.

This sounds unusual but will be the reality when attack happens, so is necessary.  Note in this latest revision the CT Gossip calls for static PKP.  Does that mean, static PKP will permanently exist as long as CT is around?  If so, will you re-consider allowing third party to opt-in?

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.

> You raised a concern about repressive regimes adding CAs for the express purpose of MITM. We take CA security quite seriously, as shown through our past actions to limit or remove trust in CAs that violate our expectations and users security — such as DigiNotar, India CCA, CNNIC, WoSign/StartCom, and most recently, Symantec. If you have information or evidence of malfeasance or misbehaviour, I encourage you to file a Security Bug using the template at https://bugs.chromium.org/p/chromium/issues/entry?template=Security+Bug with details.

> Note that the addition of new CAs is not an easy process — it typically takes years — and, in conjunction with efforts led by Mozilla, we encourage and actively support efforts to publicly review and discuss every new CA being proposed. If you have reason to believe there are new CAs being stood up for illegitimate purposes, I encourage you to participate in those discussions, on the mozilla.dev.security.policy mail list — https://lists.mozilla.org/listinfo/dev-security-policy .

Yes, we really appreciate these discussions!  We will certainly try more to participate.

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.

And I did join that huge uphill battle/discussion when the maker of this malware applied for Mozilla's root inclusion.  It then was trusted by all browsers, faked google domain certs, and now remains a Chrome's Qualified CT log, along with at least 4 "different" CAs from the same regime as Chrome's trusted CAs.

The CA may not apply for browser's root inclusion for the sole purpose of MITM.  They may apply for legitimate business purposes, although the presence of multiple CAs and multiple CT logs from the same repressive regime which dictates all resources in the country demonstrated the following:
1. the regime is capable to send multiple CAs and multiple CT logs to browsers
2. they can do MITM that CT can not prevent or stop for days, albeit probably not more frequently than once every few years.

I understand it's extremely difficult for you to balance your product including budget and politics.  We are losing a bulletproof defense to save lives and see situation deteriorating, so we really appreciate your help!

Sincerely,
Paul Lee

[Ryan Sleevi]

On Thu, Feb 8, 2018 at 7:35 PM, <paull...@gmail.com> wrote:

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

That policy defines what is CT Qualified (for all certificate types).

Additionally, EV certificates must be CT Qualified.

Expect-CT is a signal that certificates for that site should be CT Qualified.

Chrome is working to require all newly issued certificates be CT Qualified.

 

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.

Yes, Expect-CT is that mechanism.

 

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

Rather, the functionality today is that Chrome trusts the OS setting, so you should curate the OS list. There is not a Chrome-specific override at this time. If you are worried about future OS updates, then you don't trust your OS vendor, and that you are back to the initial problem.

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!

Chrome does not implement CT Gossip, nor does it have any timetable to do so. Rather, in your scenario, even if the Evil CA rotated certificates every 23 hours, they would be discovered - for example, by virtue of having been logged in both one Google and one non-Google log, even if the non-Google log colludes, the Google log will not, and at T=24, you will discover this.

 

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.

Understandably, however, trusting your browser on a system you do not trust is not going to be something that is safe. You need to ensure you trust the computer, and from your description, you do not trust the OS vendor's update mechanism or selection of CAs. You would then need to disable the OS vendor's update of CA trust, and disable trust in those CAs.

For example, on Windows, explicitly adding certificates to the "Distrusted" list will ensure that they are not trusted. However, if at any point in the future the OS vendor trusts additional certificates from your attacker, you will need to ensure you do not trust those either.

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.

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.

This is conflating CAs and CT, which are entirely different systems. The trustworthiness or lack in a CA does not affect the trustworthiness or lack in a CT Log. This is because a CT Log is cryptographically verifiably consistent in a way CA operations are not.

[paull...@gmail.com]

Thanks for your clarification!

> That policy defines what is CT Qualified (for all certificate types).

Additionally, EV certificates must be CT Qualified.

Expect-CT is a signal that certificates for that site should be CT Qualified.

Chrome is working to require all newly issued certificates be CT Qualified.

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?

We understand the consequence some people mentioned about locking people out if mal-configured.  But as mentioned above there is no more irreversible consequence than having people losing lives.  So far it worked very well.

Sincerely,

Paul Lee

[Ryan Sleevi]

On Fri, Feb 9, 2018 at 12:44 AM, <paull...@gmail.com> wrote:

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.

https://www.chromium.org/Home/chromium-security/certificate-transparency

The CT RFC (and Expect-CT) define the technology. The question about what the policy is for applications is much like the "How do I become a trusted CA" question - that's a matter of application policy, not technical specification. The above link has the relevant policies.

 

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.

This is not a loophole. It is by design, any trusted certificate can be logged to CT. CT serves as a detection mechanism.

 

  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.

This is correct. CT does not serve this purpose.

 

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.

This is also correct. A CT log does not state whether or not a certificate should be trusted. It states whether it exists, and who it was issued by. This allows detection.

 

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?

If your threat model is a hostile CA performing MITM, yes. A CA that actively misissued certificates would be distrusted. CAs know and understand this. An attacker that can convince or compromise a CA to misissue a certificate would have the effect of causing that certificate to be detected, distrusted, and potentially the CA distrusted.

 

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.

 

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.

No, that's not quite correct about what Expect-CT expresses (since the UA determines the set of logs). That is, Expect-CT behaves like HSTS. This is intentional - introducing an HPKP-like mechanism has all of the downsides of HPKP, and none of the advantages.

 

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

Then you need to remove those roots from your users machines.

If your users trust the entity attacking you, then the issue is that your users trust the entity attacking you.

 

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?

Not Microsoft's CA - the CA's you are concerned. As previously mentioned, there are/were a number of flaws in your setup that would expose your users, and the only way to mitigate the threats you are specifically concerned about is to ensure that your users have actively marked those CAs as untrusted, and actively monitor/prevent any updates to the CA trust store. In general, this is still a way to shoot yourself in the foot (e.g. disabling CA updates can cause sites to break as well), but at least it's something the user did, rather than the site.

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.

[paull...@gmail.com]

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

At the same time, if you look at this 9-page group discussion you will quickly realize such needs is diverse and substantial where some regimes tear down various "home churches" with hundreds of followers one after another. 
That's why I really hope you can take a closer look of the this proposal:

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.

Sincerely,

Paul Lee

On Friday, February 2, 2018 at 1:54:52 AM UTC-5, paull...@gmail.com wrote:

[Ryan Sleevi]

On Sat, Feb 10, 2018 at 8:15 PM, <paull...@gmail.com> wrote:

> 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

No, unfortunately, that's not quite correct.

Pinning is disabled for locally-installed CAs, but 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. That's why I was trying to communicate that, even today, HPKP doesn't match your needs.

 

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

Correct, Certificate Transparency does not prevent MITM, it allows reliable detection of MITM. By facilitating this detection, the costs of MITM (and the risks) substantially and significantly increase.

 

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.

Based on that number you shared, I suspect I can guess that regime, but I also can assure you that distrusting a CA is definitely a high-impact decision that is carefully done, based on the data. That is, it's an especially big-deal for these CA operators.

 

We will follow your advice to go along the line of removing CAs while Chrome is running. 

More precisely, if your threat model is that your system has CAs that you personally do not trust, you need to remove those CAs, full stop. There's no way to ensure you or your users safety without taking steps to eliminate trust.

In Windows, this means adding certificates to the "Untrusted Certificates" group (available by running the "Certificates" snap-in for MMC). It also means disabling root update, which is handled via Group Policy settings and the Registry, namely, setting the Software\Policies\Microsoft\SystemCertificates\AuthRoot\DisableRootAutoUpdate to DWORD 1 (Microsoft makes it difficult to find this documentation for good reason - it can result in system security updates being unable to be applied)

You should do this not just when Chrome is running, but system wide.

 

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.

Thanks for these suggestions. Unfortunately, many of them share the same limitations that motivate HPKP's removal - by making it difficult to migrate CAs, users' security can be harmed, rather than helped. That is, disabling things like root auto update, or having users restrict certain sites to certain CAs, prevent those sites from migrating to more trustworthy CAs. I realize that your concern is that untrustworthy CAs will be introduced into the ecosystem, but in general, it's substantially harder to introduce a new CA into the ecosystem than it is to have an existing CA be coerced or compromised. For this reason, we're especially focused on raising the bar for all CAs - both new and existing - to ensure they meet a high bar for security.

UI is also, unfortunately, not free. We've tried to balance the user interface in Chrome to be reflective of most users needs, and this occasionally means that some niche needs are not able to be met. This is an unfortunate tradeoff, in which the needs of the many outweigh the needs of the few. On the upside, for your specific case, modifying the system trust store is one way that you can use to reduce or limit the trust in the CAs.

For a life-or-death threat model such as yours, solutions invariably are complex and layered. Threat models require thinking about all of the components holistically, and often-times are very specific to your use case. As one of the authors of HPKP, I certainly would not advise relying on it for your threat model - the limitations inherent to such a situation necessitate a much stronger set of mitigations. Hopefully, with the above advice on how to modify your trust store (and the risks involved with disabling autoupdate), you can find the right balance for your needs.

[paull...@gmail.com]

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.  And I believe Microsoft Windows auto-update patches are signed so can not be tempered during transmission.  So do you suggest Microsoft Windows's autoupdate may un-intentionally install some CAs as locally-installed CAs?  Or under what circumstances do you think Microsoft OS update can treat a CA as locally-installed CA?

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

Sincerely,

Paul Lee


On Friday, February 2, 2018 at 1:54:52 AM UTC-5, paull...@gmail.com wrote:

[Ryan Sleevi]

On Thu, Feb 15, 2018 at 2:04 AM, <paull...@gmail.com> wrote:

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. 

I fear you may be confusing things. I'm saying Microsoft shipping a root CA update can cause those new CAs to be treated as locally installed. That's not malware.

From your threat model, it's clear that you do not trust Microsoft, in as much as it has allowed some CAs into its Root Program that you do not feel are trustworthy. That's the disconnect, which is why you're needing to distrust CAs that Microsoft has stated are trustworthy. Microsoft may add new CAs at any point in the future, and if you do not trust Microsoft's decisions about trustworthiness, then your systems are at risk from the attacks you are concerned about.

 

And we have to enable Windows autoupdate to make sure the OS itself is free of vulnerabilities. 

This is a good posture. Unfortunately, it's where this threat model breaks down. Because you don't trust CAs that have been installed by Microsoft, you don't really trust Microsoft. This is the challenging part that HPKP cannot and does not solve, unfortunately.

 

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

You very much should be concerned, which is why HPKP doesn't address your threat model. Any application you use can end up trusting those CAs, and in doing so, may expose your users and your systems to risk, if you feel those CAs are likely to engage in or support hostile behaviour. Further, Certificate Transparency requirements and pinning requirements would only apply to the browser, and thus your other software is at risk. 

For example, CAs that can sign software updates or drivers, or MITM third-party software updaters, or a host of other badness.

[duer...@gmail.com]

On Friday, February 9, 2018 at 1:53:19 PM UTC+8, Ryan Sleevi wrote:

 

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.

hi ryan, this is  shaun post, my understanding is there is a way for CT to prevent or stop MITM by disconnetion. If I'm wrong, pls tell me . Thanks. Here are shaun's post:

Implementing a report-uri endpoint for Expect-CT (and other headers)
Posted December 13, 2017 by shaun

The executive summary of Expect-CT is that Chrome can now compare the SSL/TLS certificates it encounters against the public transparency logs published by each Certificate Authority. By sending an Expect-CT header, you as a site operator are instructing Chrome to enable this protection mechanism for your site. [b][color=#0000FF]If the browser finds a discrepancy, it can perform two different actions at your discretion:

Terminate the current connection, protecting the user from an impostor / MITM / other risk;
Submit a report containing information about the request to a report-uri you specify in your header.[/color][/b]

In this way, Expect-CT helps your users and also serves as an early warning system for certificate forgery and misuse. If someone who's visited your site (and received your header, which Chrome stores) later encounters another site impersonating yours, or if something hinky is detected with your TLS certificate, Chrome will post a notification to let you know.

[duer...@gmail.com]

In another word, CT is able to prevent MITM by mechanism , regardless of who build the log.