Intent to Ship: Block HTTP port 554

[Adam Rice]

Contact emails

ri...@chromium.org

Explainer

None

Specification

https://github.com/whatwg/fetch/pull/1148

Summary

Connections to HTTP, HTTPS or FTP servers on port 554 will fail. This is a mitigation for the NAT Slipstream 2.0 attack. It helps developers by keeping the web platform safe for users. Chrome briefly blocked port 554 before, but it was unblocked due to complaints from enterprise users. However, we have now achieved rough consensus at https://github.com/whatwg/fetch/pull/1148 to block 554.

Blink component

Internals>Network

TAG review

Not needed (extension to existing block list)

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Firefox and Safari are already blocking this port, so interoperability risk is not significant. This will inescapably cause problems for developers running servers on port 554. They will have to move to a different port. We strongly recommend using port 80 for HTTP and 443 for HTTPS to avoid the risk of future blocks.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: No signals

Ergonomics

No impact.

Activation

None needed.

Security

This is a security improvement. The main risk is that we will have to block more ports in future.

Debuggability

Not needed.

Is this feature fully tested by web-platform-tests?

No

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5329879744643072

This intent message was generated by Chrome Platform Status.

[Jochen Eisinger]

lgtm1

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

[Daniel Bratell]

LGTM2

Not 100% happy about the enterprise situation, but considering the security implications of keeping it open and that the port is already blocked in other browsers, I'm ok with it.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuidC_qGPLiutomRqhg%3Dkti0wyP84QZ8fmHmKM68B1iajog%40mail.gmail.com.

[Yoav Weiss]

LGTM3

Please make sure the Chrome Enterprise folks are committed to communicate that blocking through their channels, to try and reduce the breakage here.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e9da9280-f385-0c7f-c7e1-42947f10d00a%40gmail.com.

[Mike West]

You've already got LGTMs here, the only thing I would add is that given the drip-by-drip nature of these port restrictions, I wonder when it will become reasonable to invert our list. Skimming through HTTP Archive, for example, ~99.94% of URLs requested are using the default port, and a substantial amount of the rest are specifying well-known ports like 8080, 8443, 444, 8090, 8081, 81, 8000, 443, and so on.

Given that we know there's real risk here, perhaps coming up with a feasible allowlist (with a carveout in devtools and/or enterprise policy) would be a good use of our time?

Query:

```

SELECT
  REGEXP_EXTRACT(url, CONCAT(NET.HOST(url), ":([0-9]+)")) as port,
  COUNT(*) as num,
  count(*) * 100.0 / sum(count(*)) over() as percent
FROM
  `httparchive.requests.2021_02_01_desktop`
GROUP BY
  port
ORDER BY
  num DESC

```

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiYzqAT13x%3DFGgGc9FazJRb%3DyDW%3D1j_UBiEGJ3VdL%3DzyA%40mail.gmail.com.

[Arne Babenhauserheide]

Switching to an allowlist would disrupt the high-security setup for the Freenet Proxy which relies on setting a random 127.x.y.z IP and a random port to prevent snooping on the local service: https://www.draketo.de/politik/random-babcom#use-freenet-as-proxy-secure-against-spying-attacks

[Matt Menke]

One option would be to block ports in the registered port range (1-1023), with specific carveouts.  ~20-25% of the currently blocked ports are not in that range, but most of them are.

[Mike West]

Let's move this piece of the conversation to https://github.com/whatwg/fetch/issues/1189.

Arne: I don't think we'd need to affect proxy configurations, as those are sufficiently insulated from websites to make them difficult tools for attackers to use. But if I'm misunderstanding the mechanism, that issue against Fetch is likely a good place to discuss it.

-mike