Intent to Implement and Ship: Block HTTP port 10080

410 views
Skip to first unread message

Adam Rice

unread,
Apr 8, 2021, 12:18:17 AM4/8/21
to blink-dev, net-dev

Contact emails

ri...@chromium.org

Explainer

None

Specification

https://fetch.spec.whatwg.org/#bad-port

Summary

Connections to HTTP, HTTPS or FTP servers on port 10080 will fail. This is a mitigation for the NAT Slipstream 2.0 attack. It helps developers by keeping the web platform safe for users.



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 involved in the discussion to block the port, so interoperability risk is not significant. Firefox has already shipped a block. This will inescapably cause problems for developers running servers on port 10080. 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: No signal Minor incremental change, so not asking for official position.

Web developers: Positive (https://twitter.com/TypeSong/status/1379603571193249793)

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

Flag name



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6510270304223232

This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Apr 8, 2021, 12:36:10 AM4/8/21
to Adam Rice, blink-dev, net-dev
LGTM1

Thanks for protecting our users!

Are the Chrome Enterprise folks in the loop here?

On Thu, Apr 8, 2021 at 6:18 AM Adam Rice <ri...@chromium.org> wrote:

Contact emails

ri...@chromium.org

Explainer

None

Specification

https://fetch.spec.whatwg.org/#bad-port

Summary

Connections to HTTP, HTTPS or FTP servers on port 10080 will fail. This is a mitigation for the NAT Slipstream 2.0 attack. It helps developers by keeping the web platform safe for users.



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 involved in the discussion to block the port, so interoperability risk is not significant. Firefox has already shipped a block. This will inescapably cause problems for developers running servers on port 10080. 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: No signal Minor incremental change, so not asking for official position.

Would be good to at least make WebKit folks aware that we're blocking this, by e.g. filing a bug and looping in the right folks on their end.
 

Web developers: Positive (https://twitter.com/TypeSong/status/1379603571193249793)

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.


I think this was brought up before, but have we considered moving to an allow-list model?
 


Debuggability

Not needed.



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

No

Flag name



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6510270304223232

This intent message was generated by Chrome Platform Status.

--
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_ixdy%3D-0AVmWRnwc-AfrHaHB70NvpEuM_2dpP5qVF7HkgXpg%40mail.gmail.com.

Adam Rice

unread,
Apr 8, 2021, 12:54:17 AM4/8/21
to Yoav Weiss, blink-dev, net-dev
Are the Chrome Enterprise folks in the loop here?

Yes, I gave them the heads-up. I am working on an enterprise policy to provide a temporary escape hatch.
 
Would be good to at least make WebKit folks aware that we're blocking this, by e.g. filing a bug and looping in the right folks on their end.

Yes, I have pinged the thread at https://github.com/whatwg/fetch/issues/1191 to let other browser vendors know I am planning to move forward. So they are in the loop.

  I think this was brought up before, but have we considered moving to an allow-list model?  

Chris Harrelson

unread,
Apr 8, 2021, 1:36:29 AM4/8/21
to Adam Rice, Yoav Weiss, blink-dev, net-dev
LGTM2

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_ixdwBGuKba_L-jqHOSPPfCGQPgpmHcQsrcvBj8B5NzthbQQ%40mail.gmail.com.

TAMURA, Kent

unread,
Apr 8, 2021, 3:18:03 AM4/8/21
to Adam Rice, Yoav Weiss, blink-dev, net-dev
LGTM3




--
TAMURA Kent
Software Engineer, Google


Kinuko Yasuda

unread,
Apr 8, 2021, 11:04:00 AM4/8/21
to TAMURA, Kent, Adam Rice, Yoav Weiss, blink-dev, net-dev
Non-owner LGTM, thanks for moving this forward!

Reply all
Reply to author
Forward
0 new messages