Re: "Filter to" list for SSLErrorOverrideAllowed

[Emily Stark]

Adding security-dev@ for more thoughts.

Personally I think this sounds reasonable (I'm from the security team, not enterprise). Just to be clear, the functionality would be to disallow error override on specific websites, right? Not to suppress certificate errors on certain websites? It's a little unclear from the feature requests which one is being requested.

It would also be important to document and test that the policy doesn't override other reasons that the error might not be bypassable. For example, an HSTS site should still be non-bypassable even if the policy is set to allow overrides on that site.

On Monday, December 7, 2020 at 4:05:35 PM UTC-8 nia...@microsoft.com wrote:

Hi all,

At Microsoft Edge, we got a feature request to create a new policy that would target the existing SSLErrorOverrideAllowed policy to specific pages.

The explanation for this feature request I got was: "This could be useful in a scenario where customer is not using PKI and needs to exempt internal sites but not external sites from SSL errors". Overall, it seems like this could make some users more safe since they'd have the option of only allowing SSL error page overrides in a small subset of sites as opposed to the entire web. Implementation-wise, it seems like this change won't be too scary.

Any interest in having a policy like that in Chrome? We could add a new policy or deprecate the existing policy in favor of a new one with a more versatile schema.

Thanks,

Nicolas

[Ryan Sleevi]

Just to clarify, since I'm not sure about nudging.

Today, setting the policy to a non-default state disables bypassing warnings everywhere.

If I understand the proposal, the goal is "disable bypassing warnings everywhere, except for these few internal sites, which we allow users to bypass warnings on"

I saw some discussion about "only disable warnings on these pages" (note: a big difference compared to "disable bypassing warnings") or "only disable bypassing warnings on these pages" (i.e. the default being to allow bypassing warnings everywhere, except for a few pages), and those both seem regressions from the current policy, so I wasn't sure if I was misunderstanding.

It'd be useful to better understand the use case of "Allow bypassing warnings on these internal sites", since it seems like an ideal outcome is that Enterprise customers would, ideally, be able to avoid warnings being generated on their own sites to begin with. But that's perhaps for follow-up.

On Tue, Dec 8, 2020 at 3:02 PM 'Brandon Heenan' via chromium-enterprise <chromium-...@chromium.org> wrote:

I'm a little bit late to the convo, and agreed that putting this discussion in a crbug makes sense. But some initial thoughts:

Given that the proposed policy is strictly more secure than the existing SSLErrorOverrideAllowed policy, it seems like a good idea. I also think we could go as far as deprecating the existing "disable everywhere" in favor of "disable for these domains". Admins could still specify "*" for the same effect, but this would gently nudge towards better behavior with more scoped permissions.

On Tue, Dec 8, 2020 at 2:29 PM 'Nicolas Arciniega' via chromium-enterprise <chromium-...@chromium.org> wrote:

Ah, to be clear, the feature request was to provide the customer a way to allow their users to skip past the SSL error page only on specific domains. For example, they might want their users to skip past an SSL error in "trusted-internal-site.com", but not in "suspicious-site.com". Today, enabling the policy allows users to skip past the SSL error page on all sites.

Yeah, I can file it as a bug and we can go over it there!

On Tuesday, December 8, 2020 at 3:18:18 AM UTC-8 pasta...@chromium.org wrote:

I also don't see a reason for a finer grained policy from an enterprise perspective. Following other recent examples like AutoLaunchProtocolsFromOrigins which is also a contribution from the Edge engineers. I think the best way to continue this discussion is to file it as a bug at crbug.com and go over the details there. 

Best,

Julian

--
You received this message because you are subscribed to the Google Groups "chromium-enterprise" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-enterp...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-enterprise/a5b42127-d565-4439-895a-0a6d66ded138n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "chromium-enterprise" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-enterp...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-enterprise/ee547ced-7519-48a7-ae51-a9c417562ee2n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "chromium-enterprise" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-enterp...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-enterprise/CAFKd2qVHrOBVVhuc4quL%2BVqheRGM%3D1SV1vxiC2ScviWs-0G8_w%40mail.gmail.com.

[Brandon Heenan]

I'm a little bit late to the convo, and agreed that putting this discussion in a crbug makes sense. But some initial thoughts:

Given that the proposed policy is strictly more secure than the existing SSLErrorOverrideAllowed policy, it seems like a good idea. I also think we could go as far as deprecating the existing "disable everywhere" in favor of "disable for these domains". Admins could still specify "*" for the same effect, but this would gently nudge towards better behavior with more scoped permissions.

On Tue, Dec 8, 2020 at 2:29 PM 'Nicolas Arciniega' via chromium-enterprise <chromium-...@chromium.org> wrote:

Ah, to be clear, the feature request was to provide the customer a way to allow their users to skip past the SSL error page only on specific domains. For example, they might want their users to skip past an SSL error in "trusted-internal-site.com", but not in "suspicious-site.com". Today, enabling the policy allows users to skip past the SSL error page on all sites.

Yeah, I can file it as a bug and we can go over it there!

On Tuesday, December 8, 2020 at 3:18:18 AM UTC-8 pasta...@chromium.org wrote:

I also don't see a reason for a finer grained policy from an enterprise perspective. Following other recent examples like AutoLaunchProtocolsFromOrigins which is also a contribution from the Edge engineers. I think the best way to continue this discussion is to file it as a bug at crbug.com and go over the details there. 

Best,

Julian

On Tue, Dec 8, 2020 at 5:56 AM Emily Stark <est...@chromium.org> wrote:

--

You received this message because you are subscribed to the Google Groups "chromium-enterprise" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-enterp...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-enterprise/a5b42127-d565-4439-895a-0a6d66ded138n%40chromium.org.

[Yulian Pastarmov]

I also don't see a reason for a finer grained policy from an enterprise perspective. Following other recent examples like AutoLaunchProtocolsFromOrigins which is also a contribution from the Edge engineers. I think the best way to continue this discussion is to file it as a bug at crbug.com and go over the details there. 

Best,

Julian

On Tue, Dec 8, 2020 at 5:56 AM Emily Stark <est...@chromium.org> wrote:

--