New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Task

Blocking:
issue 882536
issue 593759



Sign in to add a comment
link

Issue 619087: Deprecate the PacHttpsUrlStrippingEnabled policy

Reported by eroman@chromium.org, Jun 10 2016 Project Member

Issue description

M52 has a policy "PacHttpsUrlStrippingEnabled" which defaults to False for Chrome OS enterprise users, and True elsewhere:

https://cs.chromium.org/chromium/src/components/policy/resources/policy_templates.json?sq=package:chromium&dr=C&l=8586

We want to remove the policy in favor of the feature being always enabled (PacHttpsUrlStrippingEnabled = True), without an option to override.
 

Comment 1 by pbond@chromium.org, Jun 23 2016

Labels: Enterprise-triaged Hotlist-GoodFirstBug

Comment 2 by eroman@chromium.org, Jun 23 2016

To be clear, this bug is about figuring out *when* to deprecate it, and how to safely remove any consumers of it (transitioning them to the new default behavior).

The policy itself was just introduced in M52 and hasn't even gone out yet at this time.

(Might not be the best first bug).

Comment 3 by eroman@chromium.org, Aug 26 2016

Cc: cyrusm@chromium.org atwilson@chromium.org dskaram@chromium.org
Labels: -Enterprise-triaged Enterprise-Triaged
Owner: dskaram@chromium.org
Status: Assigned (was: Available)
David, can you find an owner for this?
Thanks!

Comment 4 by eroman@chromium.org, Feb 10 2017

Ping

Comment 5 by atwilson@chromium.org, Feb 13 2017

Cyrus/David - I'm concerned about the current implementation of this policy, as it means Pac stripping is disabled for *all* managed devices.

Here's what I'd propose as the first step of a deprecation strategy:

1) We update DMServer to set this policy (disable stripping) on all current EDU domains.
2) Update policy_templates.json to remove the "enterprise default" (so we will start stripping PAC urls except for the domains specified in #1)

...and we wait to see what breaks. This has the advantage of not breaking any existing EDU customers, but *new* customers will get the stripping functionality while they are doing their initial deployment so they can shake out any issues. It also makes enterprises more secure by doing stripping for non-EDU customers.

Cyrus/David, WDYT? I don't have a great plan for fully deprecating this policy, since we have no way of telling who might break if we remove the policy. But at least we can lock down the set of domains that don't have Pac stripping to the current set of EDU customers.

Comment 6 by dskaram@chromium.org, Feb 13 2017

SGTM. If anything breaks on Enterprise side and we need to pull an emergency brake, we can always manually set the policy for an affected domain. We followed a similar route with SHA1 root deprecations as that was also a niche policy which we didn't really want to surface UI for but wanted to keep an emergency brake at hand.

Comment 7 by atwilson@chromium.org, Jul 3 2017

Cc: binzhao@chromium.org
Bin, WDYT about making the change in DMServer described in comment #5?

Comment 8 by eroman@chromium.org, Dec 19 2017

Any update on this? It has been over a year, and we are still running Chrome OS with a known security/privacy vulnerability...

Comment 9 by eroman@chromium.org, Apr 4 2018

Is anyone working on this?

Other browsers have also followed suite and disabled paths in PAC, so the compatibility risk seems low.

If there is no-one planning to do a rollout for this, can I just flip the default in code for Chrome OS so we can make progress towards deprecating this?

Comment 10 by atwilson@chromium.org, Apr 9 2018

Cc: dkalin@google.com
Owner: naveenv@chromium.org
Naveen, it's your call. We originally set this policy for managed cros devices for fear of breaking enterprise deployments.

I'd be nervous of just flipping it on the client as it might take devices offline - would love to hear from you and Dennis around the feasibility of the path I outline in comment #5.

Comment 11 by eroman@chromium.org, Jun 13 2018

Labels: Security_Impact-Stable

Comment 12 by eroman@chromium.org, Aug 31

What is the status of the rollout?

We need to remove support for this.

Comment 13 by atwilson@chromium.org, Sep 3

+1 - I suspect Naveen isn't seeing these bugs, perhaps you should start an email thread on it instead.

Comment 14 by eroman@chromium.org, Sep 10

Blocking: 882536

Comment 15 by atwilson@chromium.org, Sep 13

Cc: -dskaram@chromium.org -binzhao@chromium.org naveenv@chromium.org
Owner: poromov@chromium.org
Sergey, would like to remove the enterprise default for this policy (in policy_templates.json), and set the supported-on flag to m74.

Comment 16 by bugdroid1@chromium.org, Sep 14

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0aec57f9714aba3ae2b0a9ba8a05268a5013d046

commit 0aec57f9714aba3ae2b0a9ba8a05268a5013d046
Author: Sergey Poromov <poromov@chromium.org>
Date: Fri Sep 14 13:03:22 2018

Start deprecation of PacHttpsUrlStrippingEnabled policy

This change removes enterprise_default for PacHttpsUrlStrippingEnabled,
that was set to "False" and now all users should have it set to "True".
Long-term security-wise the behavior should be that URLs are always
stripped for Pac proxies, i.e.as the policy set to "True".

We are keeping ability to change the policy in server-side configuration
to "False" in case customers will be broken by the change.

Otherwise, the policy is going to be deprecated in M74.

Bug: 619087
Change-Id: I29db0211ced988b0fde5efaf3ce7863466bffb6e
Reviewed-on: https://chromium-review.googlesource.com/1224449
Commit-Queue: Sergey Poromov <poromov@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#591330}
[modify] https://crrev.com/0aec57f9714aba3ae2b0a9ba8a05268a5013d046/components/policy/resources/policy_templates.json

Comment 17 by poromov@chromium.org, Sep 14

Labels: Merge-Request-70

Comment 18 by sheriffbot@chromium.org, Sep 15

Project Member
Labels: -Merge-Request-70 Merge-Review-70 Hotlist-Merge-Review
This bug requires manual review: M70 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 19 by poromov@chromium.org, Sep 17

Labels: -Merge-Review-70
Decided to keep the change in M71+ only.

Comment 20 by poromov@chromium.org, Sep 19

Labels: -Hotlist-Merge-Review -Pri-2 -Hotlist-GoodFirstBug M-75 Pri-1
Changing labels so that next action is scheduled for M75 release.

Comment 21 by poromov@chromium.org, Today (10 hours ago)

Labels: -Type-Bug Type-Task

Sign in to add a comment