Intent to Ship: Block HTTP port 554

Skip to first unread message

Adam Rice

Mar 8, 2021, 4:32:43 AM3/8/21
to blink-dev

Contact emails





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 to block 554.

Blink component


TAG review

Not needed (extension to existing block list)

TAG review status

Not applicable


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


No impact.


None needed.


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


Not needed.

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


Link to entry on the Chrome Platform Status

This intent message was generated by Chrome Platform Status.

Jochen Eisinger

Mar 8, 2021, 4:41:17 AM3/8/21
to Adam Rice, blink-dev

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
To view this discussion on the web visit

Daniel Bratell

Mar 8, 2021, 5:20:12 AM3/8/21
to Jochen Eisinger, Adam Rice, blink-dev


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.

Yoav Weiss

Mar 8, 2021, 5:24:44 AM3/8/21
to Daniel Bratell, Jochen Eisinger, Adam Rice, blink-dev
Please make sure the Chrome Enterprise folks are committed to communicate that blocking through their channels, to try and reduce the breakage here.

Mike West

Mar 8, 2021, 5:40:39 AM3/8/21
to Adam Rice, Daniel Bratell, Jochen Eisinger, blink-dev, Yoav Weiss
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?

  REGEXP_EXTRACT(url, CONCAT(NET.HOST(url), ":([0-9]+)")) as port,
  COUNT(*) as num,
  count(*) * 100.0 / sum(count(*)) over() as percent
  num DESC


Arne Babenhauserheide

Mar 8, 2021, 11:33:12 AM3/8/21
to blink-dev,, Daniel Bratell, Jochen Eisinger, blink-dev,, Adam Rice
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:

Matt Menke

Mar 8, 2021, 4:18:02 PM3/8/21
to blink-dev, Arne Babenhauserheide,, Daniel Bratell, Jochen Eisinger, blink-dev,, Adam Rice
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

Mar 9, 2021, 2:48:53 AM3/9/21
to Matt Menke, Arne Babenhauserheide, Adam Rice, blink-dev, Daniel Bratell, Jochen Eisinger,
Let's move this piece of the conversation to

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.


Reply all
Reply to author
0 new messages