Block port 10080?

[Adam Rice]

Safari and Firefox have blocked port 10080. Chrome has not. I am uncomfortable blocking it because it is used significantly more than the other ports we have blocked for the same vulnerability (20 times more the next most common). See https://github.com/whatwg/fetch/pull/1148#issuecomment-792727353 for the latest statistics, or you can lookup the Net.Port.Slipstream histogram if you are a Googler.

I am looking for other opinions for or against blocking this port.

[Adam Rice]

Correction: Safari is not blocking 10080.

[Ryan Sleevi]

For what it's worth, I am supportive of blocking, but I also think the approach called out in https://github.com/whatwg/fetch/issues/1189 is probably the only path long-term to mitigate these risks.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAC_ixdzw8_RgERgMiwmUK8-PJWbjfyex9xS8a7sn%2BEd3z19yfQ%40mail.gmail.com.

[Matt Menke]

If all of those parts are subject to similar attacks, I'm not sure of the utility of just blocking some of them, so I agree with Ryan on blocking 10080.  Since we're stuck supporting cleartext and clear-text-adjacent protocols, I agree about the allowlist as well (For the record, I consider HTTP/1.x over HTTPS clear-text-adjacent)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvYR%2BEXF4P3L5FG2xPFjGhFBBBo69TjaWD9XbGuqoJzzkQ%40mail.gmail.com.

[Adam Rice]

I think I will compromise and block 10080, but also add an enterprise policy equivalent to the --explicitly-allowed-ports command-line option. This is because when the version with the block is released we know a lot of people are going to have a bad day, and we should have a solution prepared for them.

[Ryan Sleevi]

I understand this can be challenging to navigate, especially with enterprise cases.

It does seem like we run the risk of making this policy something folks accidentally depend on, rather than on the Web Platform itself. A result of such flags can make it harder to migrate browsers, as well as harder for developers to understand the Web Platform security and platform primitives.

Is there any thought to making this enterprise policy only useful for port 10080? E.g. so we don't regress existing blocking mechanisms? The difference between the command-line flag and an Enterprise policy is the former is useful for limited, temporary purposes, while the latter makes it easy to build assumptions around and at scale within an organization, and equally easy for software vendors to decide not to provide updated versions of their software, instead opting to simply document organizations set such policies. The more we can limit this (e.g. by time-limiting the policy, by ensuring the policy can only apply to specific allow-listed ports), it seems like the better we can provide a predictable platform with clear targets.

Definitely, though, I can understand not wanting to break folks, and appreciate your sensitivity to that. I'm simply/largely worried about this being another permutation of the Web Platform that ends up causing cross-browser friction, so hoping we can limit it as much as reasonable :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAC_ixdyGtQ-9GcYx6FVnup7PpSV2MS5i-68xtc0LvUPdQXVk%2BQ%40mail.gmail.com.

[Adam Rice]

On Tue, 23 Mar 2021 at 22:55, Ryan Sleevi <rsl...@chromium.org> wrote:

It does seem like we run the risk of making this policy something folks accidentally depend on, rather than on the Web Platform itself. A result of such flags can make it harder to migrate browsers, as well as harder for developers to understand the Web Platform security and platform primitives.

Absolutely. I've had to make a trade-off between security and predictability, and it's not completely satisfying for either.

I've tried to make the description for the policy as clear as possible regarding the risks:

Setting the policy permits bypassing <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph>'s list of restricted ports. The value is a comma-separated list of zero or more ports that outgoing connections will be permitted on.

      Ports are restricted to prevent <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> being used as a vector to exploit various network vulnerabilities. Setting this policy may expose your network to attacks. This policy is intended as a temporary workaround for errors with code "ERR_UNSAFE_PORT" while migrating a service running on a blocked port to a standard port (ie. port 80 or 443).

      Malicious websites can easily detect that this policy is set, and for what ports, and use that information to target attacks.

      Leaving the value empty or unset means that all restricted ports will be blocked.

      This policy is overridden by the "--explicitly-allowed-ports" command-line option when present.

 

Is there any thought to making this enterprise policy only useful for port 10080?

There will inevitably be more ports to block in future, and it would be very inefficient to add a new pref every time. In addition, we may need to backport a port block. Adding an enterprise policy touches so many files that backporting it would be impractical.

 

E.g. so we don't regress existing blocking mechanisms? The difference between the command-line flag and an Enterprise policy is the former is useful for limited, temporary purposes, while the latter makes it easy to build assumptions around and at scale within an organization, and equally easy for software vendors to decide not to provide updated versions of their software, instead opting to simply document organizations set such policies.

In practice, people change the Chrome shortcut to include the --explicitly-allowed-ports command-line option. See for example https://superuser.com/questions/188006/how-to-fix-err-unsafe-port-error-on-chrome-when-browsing-to-unsafe-ports (and many other pages with similar advice). So effectively it becomes permanent. While it's easier to roll out an enterprise policy at scale, it's also easier to undo it once the problem is fixed.

Hopefully the description I wrote is scary enough that software vendors expecting enterprises to use it will get at least some push back.

 

The more we can limit this (e.g. by time-limiting the policy, by ensuring the policy can only apply to specific allow-listed ports), it seems like the better we can provide a predictable platform with clear targets.

We could split restricted ports into "old restricted ports" that can't be unblocked and "new restricted ports" that can, but I don't think it would be worth the code complexity, and it would be meaningless unless we changed "--explicitly-allowed-ports" at the same time, which we can't, because people have been using it as a workaround for years.

You'll also find a bunch of pages recommending using Firefox's equivalent about:config setting. This cat is already out of the bag.

[Ryan Sleevi]

On Wed, Mar 24, 2021 at 2:13 AM Adam Rice <ri...@chromium.org> wrote:

On Tue, 23 Mar 2021 at 22:55, Ryan Sleevi <rsl...@chromium.org> wrote:

It does seem like we run the risk of making this policy something folks accidentally depend on, rather than on the Web Platform itself. A result of such flags can make it harder to migrate browsers, as well as harder for developers to understand the Web Platform security and platform primitives.

Absolutely. I've had to make a trade-off between security and predictability, and it's not completely satisfying for either.

I've tried to make the description for the policy as clear as possible regarding the risks:

Setting the policy permits bypassing <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph>'s list of restricted ports. The value is a comma-separated list of zero or more ports that outgoing connections will be permitted on.

      Ports are restricted to prevent <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> being used as a vector to exploit various network vulnerabilities. Setting this policy may expose your network to attacks. This policy is intended as a temporary workaround for errors with code "ERR_UNSAFE_PORT" while migrating a service running on a blocked port to a standard port (ie. port 80 or 443).

      Malicious websites can easily detect that this policy is set, and for what ports, and use that information to target attacks.

      Leaving the value empty or unset means that all restricted ports will be blocked.

      This policy is overridden by the "--explicitly-allowed-ports" command-line option when present.

 

Is there any thought to making this enterprise policy only useful for port 10080?

There will inevitably be more ports to block in future, and it would be very inefficient to add a new pref every time. In addition, we may need to backport a port block. Adding an enterprise policy touches so many files that backporting it would be impractical.

Happy to help with implementation, but there are several strategies we've found have worked out well here - e.g. an explicit allowlist of port blocks that this policy is allowed to override, which are merged with the actual port block.

 

E.g. so we don't regress existing blocking mechanisms? The difference between the command-line flag and an Enterprise policy is the former is useful for limited, temporary purposes, while the latter makes it easy to build assumptions around and at scale within an organization, and equally easy for software vendors to decide not to provide updated versions of their software, instead opting to simply document organizations set such policies.

In practice, people change the Chrome shortcut to include the --explicitly-allowed-ports command-line option. See for example https://superuser.com/questions/188006/how-to-fix-err-unsafe-port-error-on-chrome-when-browsing-to-unsafe-ports (and many other pages with similar advice). So effectively it becomes permanent. While it's easier to roll out an enterprise policy at scale, it's also easier to undo it once the problem is fixed.

I can understand random advice on Stackoverflow, but I think you're underestimating the complexity tradeoff for Enterprises. Yes, individual users may do this, but the significance of an enterprise policy like you're proposing makes it very easy to do this for hundreds of thousands of users at once, and without any friction or visibility that it may be a bad idea. These policies then slowly accrete over time, creating not a Web Platform, but an Enterprise-Specific Platform, that makes it difficult to help push the web forward.

 

Hopefully the description I wrote is scary enough that software vendors expecting enterprises to use it will get at least some push back.

 

The more we can limit this (e.g. by time-limiting the policy, by ensuring the policy can only apply to specific allow-listed ports), it seems like the better we can provide a predictable platform with clear targets.

We could split restricted ports into "old restricted ports" that can't be unblocked and "new restricted ports" that can, but I don't think it would be worth the code complexity, and it would be meaningless unless we changed "--explicitly-allowed-ports" at the same time, which we can't, because people have been using it as a workaround for years.

You'll also find a bunch of pages recommending using Firefox's equivalent about:config setting. This cat is already out of the bag.

I definitely appreciate this view, but I think our experience with policies has shown otherwise. Yes, Firefox's about:config offers very powerful capabilities to fork the platform; however, these as well do not scale to the degree you're proposing adding (i.e. they're quite difficult to manage at enterprise scale here)

Happy to help on a CL, since I think this may end up just being a few lines more than a naive policy. 

[Adam Rice]

On Wed, 24 Mar 2021 at 23:49, Ryan Sleevi <rsl...@chromium.org> wrote:

Happy to help with implementation, but there are several strategies we've found have worked out well here - e.g. an explicit allowlist of port blocks that this policy is allowed to override, which are merged with the actual port block.

I've thought about this more, but having a setting which works for some ports and not others is only going to cause confusion and unhappiness. We should respect the user's ability to make their own security trade-offs.

 

I can understand random advice on Stackoverflow, but I think you're underestimating the complexity tradeoff for Enterprises. Yes, individual users may do this, but the significance of an enterprise policy like you're proposing makes it very easy to do this for hundreds of thousands of users at once, and without any friction or visibility that it may be a bad idea. These policies then slowly accrete over time, creating not a Web Platform, but an Enterprise-Specific Platform, that makes it difficult to help push the web forward.

In practice large enterprises are just going to push a script to everyone's computer to add the command-line option to the shortcut. Which is a lot harder to undo.

[Ryan Sleevi]

Thanks for the perspective Adam.

It sounds like there are some product decisions to make, and I can appreciate we're coming at this from different perspectives. I'll follow-up off-list, so we can try to resolve these directional differences and circle back here.

[Adam Rice]

After discussing this off-list we agreed on an approach which limits the ports that can be unblocked via the policy, and also limits the time that each port can be unblocked, while providing clear guidance to admins to avoid confusion.

[max savor]

 think I will compromise and block 10080, but also add an enterprise policy equivalent to the --explicitly-allowed-ports command-line option. This is because when the version with the block is released we know a lot of people are going to have a bad day, and we should have a solution prepared for them.

Does this enterprise policy equivalent exist yet because i cannot find it in the ADMX.

[max savor]

I'm using the ADMX from 

MAJOR=91

MINOR=0

BUILD=4472

PATCH=77

But I cannot find a way to open this port for a specific server.   We use Zend severs on AS400's for some data which use 10080 as a default port.  It's all internal only so i would prefer to just whitelist a server rather than have the port open to all but we dont want to deploy short cut with a flag if we can avoid it because we will end up with multiple chrome short cuts over time. 

[Adam Rice]

The name is "ExplicitlyAllowedNetworkPorts". See

https://chromeenterprise.google/policies/#ExplicitlyAllowedNetworkPorts

It might have been good to allow exceptions for specific servers, but it would have required more profound changes.

Anyway, this is supposed to be a temporary measure to give people time to transition to a standard port. If the policy was too useful then people wouldn't be motivated to stop using it.

[Fabrizio Alberti]

Me too. Any eta on updates ADMX templates? 

[Fabrizio Alberti]

I don't agree. If you are using some application server, and you need for example tomcat to go in the administration interface, you can use 10080 port directly in tomcat, without using any Webserver and JkMount mechanism to place a webserver in front to Tomcat. 

Is correct prevent piracy attack but must be also correct override this behavior, with some policy like Google permit. The only lack is actually missing updated ADMX to reflect, and we need to distibuite a GPO with a Registry key to override.