Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add { 548, 'afp' } to the blocked bad ports #694

Closed
toyoshim opened this issue Apr 10, 2018 · 11 comments
Closed

Add { 548, 'afp' } to the blocked bad ports #694

toyoshim opened this issue Apr 10, 2018 · 11 comments
Labels
security/privacy There are security or privacy implications topic: port blocking

Comments

@toyoshim
Copy link

Chrome team is discussing to disallow port 548.
Can we have the 548 in the bad port list, https://fetch.spec.whatwg.org/#port-blocking ?

Also any other reason not to disallow other well-known < 1024 ports except for http/https ?
I guess it's just for possible compatibility breakage, but it would be great if we can disallow them eventually.

@annevk annevk added the security/privacy There are security or privacy implications label Apr 10, 2018
@annevk
Copy link
Member

annevk commented Apr 10, 2018

According to Wikipedia AFP also uses 427. Is that being considered? Can you share the issue number?

I think the main reason we have a blocklist is compatibility, but I haven't seen recent data about usage of non-HTTP ports < 1024 by web sites. That would be interesting.

cc @whatwg/security

@annevk
Copy link
Member

annevk commented Apr 17, 2018

See also #544.

@annevk
Copy link
Member

annevk commented May 25, 2018

@toyoshim @tyoshino any updates here? Would love to address outstanding security issues.

@mikewest
Copy link
Member

FYI: @tyoshino is no longer working on Blink. We miss him, but I don't think he's working on web things at the moment.

I talked with our metrics folks a while back about collecting port information. They weren't thrilled about adding a histogram with 64k buckets to get exact numbers, and I didn't come up with a better proposal. Blocking 548 and 427 seems fine. Blocking all ports under 1024 seems likely to not be fine. I wonder if our metrics folks would be unhappy with 1k buckets?

@annevk
Copy link
Member

annevk commented May 25, 2018

Thanks, I meant to ping @yutakahirano, who gave me access to the private issue due to another discussion.

I guess we should proceed with 427 and 548 then and hope nothing breaks (or not too much).

@mikewest
Copy link
Member

Since we can't write WPT for it (as we don't have access to any ports below 1024), no tests will break! Which means it's web-compatible.

annevk added a commit that referenced this issue May 25, 2018
Also remove some obsolete comments.

Fixes #694.
@annevk
Copy link
Member

annevk commented May 25, 2018

Created a PR for this. Haven't filed bugs and such quite yet though so that'll likely have to wait for next week. @toyoshim I added you to the Acknowledgments section with the name you use on GitHub. Let me know if that needs changing somehow.

@yutakahirano
Copy link
Member

@mikewest
Blocking 548 and 427 seems fine. Blocking all ports under 1024 seems likely to not be fine. I wonder if our metrics folks would be unhappy with 1k buckets?

I think it's good to force preflight for port-specified requests.

@annevk
Copy link
Member

annevk commented May 28, 2018

@yutakahirano that's an interesting idea, but probably best tracked in a separate issue. Could you file one?

@ricea
Copy link
Collaborator

ricea commented May 28, 2018

@yutakahirano I'm afraid it's not web compatible. At one time running a second server on port 81 was fashionable. I doubt any of those servers will ever be updated to support CORS.

@yutakahirano
Copy link
Member

@annevk: sounds good.

I'm fine with blocking 548 and 427.

annevk added a commit that referenced this issue May 31, 2018
This blocks ports used for the Apple File Protocol (427, 548) and thereby fixes #694, and blocks another IRC port (6697) as discussed in #482 and shipped by Chrome.

Tests: web-platform-tests/wpt#11249.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security/privacy There are security or privacy implications topic: port blocking
Development

No branches or pull requests

5 participants