[Routing to David for prioritization]

bulk-edit of Unconfirmed feature requests

@dlimor, just tried the root cert setting and I don't see the enterprise logo you mention in the bug. Would you mind attaching a video repro on latest stable? Screencastify extension is an easy way to produce screencasts on a Chrome device. Thanks!

I remember reading the code for this.
When a policy-installed certificate has been used in the profile at least once, a flag is flipped (UsedPolicyCertificates/UsedPolicyInstalledCertificate[1]), and from there on, the security display settings change[2]. We even have a special message for this case[3]. We do switch to the "business icon"[4] in the toolbar.

The text referenced in [3] currently says "You have accessed content using an administrator-provided certificate. Data you provide to <domain> can be intercepted by your administrator."

Note that for this to trigger, it is not sufficient for the policy-installed CA certificate to be present, it must have actually been used in at least one (successful, IIRC) certificate verification process.

[1] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/policy/policy_cert_service.cc?l=97&gs=cpp%253Apolicy%253A%253Aclass-PolicyCertService%253A%253AUsedPolicyCertificates()-const%2540chromium%252F..%252F..%252Fchrome%252Fbrowser%252Fchromeos%252Fpolicy%252Fpolicy_cert_service.cc%257Cdef&gsn=UsedPolicyCertificates&ct=xref_usages and https://cs.chromium.org/chromium/src/chrome/browser/ssl/security_state_tab_helper.cc?l=171&gs=cpp%253Aclass-SecurityStateTabHelper%253A%253AUsedPolicyInstalledCertificate()-const%2540chromium%252F..%252F..%252Fchrome%252Fbrowser%252Fssl%252Fsecurity_state_tab_helper.cc%257Cdef&gsn=UsedPolicyInstalledCertificate&ct=xref_usages
[2] https://cs.chromium.org/chromium/src/components/security_state/core/security_state.cc?rcl=bce609e812bce6b02e1326773f06fb639020a847&l=163
[3] https://cs.chromium.org/chromium/src/components/page_info_strings.grdp?rcl=bce609e812bce6b02e1326773f06fb639020a847&l=63
[4] https://cs.chromium.org/chromium/src/components/toolbar/toolbar_model_impl.cc?rcl=bce609e812bce6b02e1326773f06fb639020a847&l=92

My concern is that cases #1 and #3 seem equivalent to me - if I control the network/DNS server, can't I MITM traffic even without explicitly setting up a proxy?

I do think the idea of limiting which domains a given trust root applies to is promising - not sure if our SSL infra supports this (yet), though.

Re: MITM 'detection'
Yes, when an additional trust anchor is in use, chrome assumes someone can be MITMing/sniffing on your traffic.
chrome can't know for sure that no one is MITMing. There are other ways of routing traffic through a malicious instance than proxy (e.g. DNS, network switches, routers, ...). "No proxy is set up" does not rule out that traffic may still be going through some malicious actor.

Re: Disabling multi-profile:
My understanding is that this is an artifact of the infrastructure currently used to perform certificate verification on Chrome OS. In particular, the NSS library uses shared caches, so the certificate validation result could "leak" into the other profile through the NSS cache.
Work is in progress on changing this, but as certificate verification is a very sensitive topic with a lot of weird setups especially in enterprise environments, this is a challenging effort.

Re: The icon is displayed for sites which don't use the cert in their cert verification path.
Good question. This may be related to (2), but I wasn't around when that decision has been made.

Absolutely loving this conversation. Thanks all for jumping in.

 Issue 792097  has been merged into this issue.

Hi,

Has there been any further thought on this?

Thanks,

I think pmarko@ answered the bulk of it. One additional clarfiication that has surfaced since then re the icon displayed for sites which don't use the cert in their cert verification path

is that the team made a concious decision to do that after the first invocation on any website as the browser can pull down various resources through that connection that can be used in subsequenct connections without any knowledge from the network stack such as cached JS files and cached images.


I'm adding a few extra folks to this thread from privacy and networks if there is anything further they'd like to say.

Correct. Platforms cannot effectively distinguish between the three cases, and, as noted, the ability to provide a non-trusted certificate for a single host can lead to the effective equivalent of MITM.

The displaying of UI is consistent with other Google platforms, such as Android, that seek to ensure the user is fully informed of the risks, potentially when using an Enterprise-managed device, to the safety and security of their communications.

As captured in Comment #6 captures, the multi-profile disabling is an artifact of code limitations in which trust is OS-wide (much as it is on other platforms), and thus control over a single profile does not indicate control over multiple profiles, and that the ChromeOS security model would prevent such interception for a user outside of the Enterprise using that device.

Regarding the per-domain scoping, that has been explored in the past, generally referred to as "name constraining" a CA. While there are technical possibilities to explore there (conditioned upon the certificate verification no longer tied to the OS), that does bring with it considerable UX complexity and technical complexity to implement and maintain, for a feature that will likely be very limited in use. This is because no such OS grants such control, and organizations are rarely configured to support it in practice. It's also something that can be obtained from the public CA market (if you're name constraining), generally with significantly better security properties (by operating as a managed service in which the keys are protected in hardware security modules).

From my perspective, the disclosure to the user that their connection may be monitored by their organization is a good one.  However, I do believe that the current flagging of all future connections as this state is not the best way to disclose this information.  Instead, it would be better if all forced enterprise policies which could read or tamper with information be consolidated to a single place, instead of this current mechanism.

For example, we could deploy an extension which reads, modifies, and reports home all web content, but the 'Secure' indicator would remain because those actions are happening outside of the transport layer.

I would like to see the office building icon moved to either the Chrome browser toolbar, or to the Chrome OS status bar, where a user could click and easily see what policies an administrator has set which could lead to information tampering or disclosure, including extensions, certificate authorities, proxies, VPNs, or anything else of the sort.  Consolidating this would make it easier for the users to see what is going on, while retaining the expected UI of the browser.

For our organization, the UI changes above would help quite a bit, but the current state is not yet a blocker as they are just UI issues.  The bigger issue for us is disabling multiple sign in when a nonstandard certificate authority is loaded, as it is a feature that would go a long way to be able to deploy Chromebooks to our knowledge workers in any broad way.  

By far, the top complaint from our current users who have traded a MacBook for a Chromebook is that there's no sensible way for them to also have a personal session going at the same time.  They can sign into multiple Google accounts in the same Chrome session, but this causes issues with multiple products including Gsuite, where it isn't immediately obvious which account documents are getting created under.  They can use an incognito window, but this means they can't use that for other testing and lose their state as it's not signed into Chrome.  Either way, they are of course still susceptible to our internal certificate authority reading all of their data.  We don't, and we publish a transparency log of all issued certificated, but of course it's a possibility.

I understand that modifying the platform to have different levels of trust for different simultaneous sessions is probably not going to happen due to complexity.  However, what would really be great here would be to permit multiple sign in while disclosing to the user what the implications are for their secondary account when it is signed into.  Tell the user that the administrator of the device has the power to lock it out, unlock it, has a certificate authority installed which could potentially intercept traffic, and forces connection to a network where traffic can also be tampered with too if so configured.

A question to ask might be this:  On macOS or Windows, if a non-system certificate authority is detected, should Sign into Chrome be automatically disabled for personal accounts? Today, our users understand that on an enterprise controlled Mac there are controls we have in place which could potentially lead to our organization reading personal information if they choose to login to personal accounts on that device, but there are substantial warnings in place that this could happen.  We never require a user to sign into their personal accounts on their work Mac, but this is something that the users expect to be able to do in some meaningful fashion, whether it is to keep in touch with others during the day or simply to listen to music.

Put simply, we need multiple sign in to be supported in our environment in order for Chrome OS to proliferate beyond the Chromebox platform we've already embraced.  We want the user to be able to simultaneously sign into a personal account, while receiving a disclosure of what is possible.  If they don't agree, they can choose to use a personal device or just not have simultaneous sessions.

> I understand that modifying the platform to have different levels of trust for different simultaneous sessions is probably not going to happen due to complexity. 

It is our goal to facilitate that use case, without requiring complex disclosure or training. That is, we're much more likely to change the code to support the case, then the UI to warn the users that the code doesn't support the case :)

That was what was referenced in Comment #6

Regarding the macOS and Windows security model, those are understandably different security models, and are addressed in https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md . For ChromeOS, the goal has been to be more secure.

Triage question - is there any further action to take here? From a quick skim it seems like this is understood / intentional behavior that work is under way to improve, but I have not read in detail.

OP / other external parties: do you have further questions?

""No proxy is set up" does not rule out that traffic may still be going through some malicious actor."

Google effectively gutted life line Syria state media on their youtube platform prior to the upcoming Idlib offensive against American sponsored Al-Queda terrorists, who are preparing another chemical False Flag to be blamed on the Syrian government. The likelyhood that CT DNS proof fetching data will be siphoned by the American military and intelligence establishment though FISA court orders and used for espionage and illegal wars of aggression against sovereign states around the world should make weighing in the blocking of these protocols a high priority for states , ISP's, DNS revolvers, and users around the globe who value breathing and living.


Privacy Concerns:

1 **Requesting an inclusion proof leaks each and every https visited domain to the client software supplier in realtime, that being Google, even for Chromium users; This gives Google droves of data once only accessible to the users ISP, and consolidates further the American companies monopoly on international population surfing data, statistics, & demographics. Chrome now leaks sensitive cached hosts and certificate hashes not obtained publicly or by a DNS resolver, including IP to IP, IP to router, SQL and any other remote & local servers accessed through a Chrome browser... potentially mapping sensitive global server infrastructure.
2Cross-resolver leakage (Leaking after enabling/disabling VPN/TOR, or switching DNS services)
3 Leakage of client information via edns-client-subnet
4 Realtime Disclosure of actual visited hosts vs only resolved hosts [previously only known by ISP]
5 Realtime Disclosure for hosts whose address was not obtained via DNS lookup [direct connection via ip]
6 Local authoritative resolver leakage**

https://docs.google.com/document/d/1DY2OsrSJDzlRHY68EX1OwQ3sBIbvMrapQxvANrOE8zM/edit#
https://www.agwa.name/blog/post/how_will_certificate_transparency_logs_be_audited_in_practice

Rewriting the bug title to focus on the key point of the discussion.