Should we block port 10080?

[annevk]

As discussed in #1148 Firefox blocks this since November: https://bugzilla.mozilla.org/show_bug.cgi?id=1677940 which went to release end of January.

(See also #1189 for a completely different approach.)

cc @mozfreddyb @youennf @ricea

[ricea]

Summarising what we know so far:

• Port 10080 is used for the Amanda protocol, used by the backup software "Amanda". It sends port numbers in messages from client -> server, and then expects the server to connect back to the client, similar to FTP in PORT mode.
• Amanda originally used UDP, but recent versions prefer TCP.
• Products from Cisco and Juniper can intercept UDP over port 10080, and create dynamic NAT mappings back to the source host.
  • We do not know what proportion of deployed devices have this enabled.
• Linux-based products do not intercept port 10080.
• No known products intercept TCP on port 10080.
• Approximately one in a million requests happen on port 10080.
• It is an attractive port for HTTP because it ends in in "80" and does not require root privileges to bind on Unix systems.
• Both Chrome and Firefox have had reports of people using port 10080.

Did I miss anything?

[ricea]

Additional information:

• VMWare vCenter uses port 10080 by default. There are instructions here to change it: https://kb.vmware.com/s/article/2031371

[ricea]

I adapted the SQL at #1189 (comment) to look only at ports that end in "080". This gives the following results:

port	percent
8080	94.734
6080	1.155
18080	1.045
9080	0.622
48080	0.491
10080	0.369
55080	0.320
4080	0.255
28080	0.199
7080	0.180
38080	0.126
1080	0.122
60080	0.117
3080	0.105
5080	0.075
30080	0.035
2080	0.016
57080	0.012
15080	0.009
45080	0.005
58080	0.005
65080	0.005

Percentages are as a proportion of only the ports that end in "080". 10080 is in 6th place among this set of ports. What this means is subject to interpretation. Usual caveats of using data from the HTTPArchive apply.

[mozfreddyb]

Thanks for summarizing again, @ricea.

Summarising what we know so far:
* Linux-based products do not intercept port 10080.
* No known products intercept TCP on port 10080.

I was originally under the impression that @samyk had found a product that intercepted port 10080. But IIRC he pointed to the linux conntrack module and that clearly looks at UDP only. Are we missing something here, Samy?

Happy to leave 10080 as unblocked (and revert our block Firefox) Adam's summary remains correct.

[ricea]

• Linux-based products do not intercept port 10080.

Looks like I was wrong about this, since nf_conntrack_amanda.c exists. Sorry.

The other items still appear to be correct.

[samyk]

@mozfreddyb Hey there, I don't know of anything that explicitly uses TCP 10080, but I also suspect some software may blindly perform ALG on both UDP/TCP thus was suggesting both for safety. However I do see the value of the 80 within 10080 and how it might be potentially used as an alternate web port so I see the value in leaving the TCP port alone.

[ricea]

Unfortunately, it looks like it is easy to get the client to send arbitrary plaintext with QUIC: https://groups.google.com/a/chromium.org/g/proto-quic/c/KVqeA9q0OAc/m/-NxF0hkqCAAJ

So we have to block port 10080 for UDP at least. I think the option of doing nothing is no longer on the table.

Currently in Chrome blocking a port for only QUIC is not something that's implemented, but I'm sure I could work it out if that's the way we decide to go.

[annevk]

@ricea slightly off-topic, but should port blocking apply to WebTransport then? I've been thinking that we should move it into the obtain a connection section, also to account for Alt-Svc. And then if WebRTC also obtains a connection through Fetch we can squash all these issues in one place.

cc @yutakahirano

[ricea]

@ricea slightly off-topic, but should port blocking apply to WebTransport then?

Yes, definitely.

[ricea]

My current tentative plan is to block 10080 in Chrome but to add an enterprise policy first so that admins can override the block. This means it will take a couple of week and I won't be backporting the block to older versions.

[davidben]

(@vasilvv for WebTransport.)

[ricea]

I've sent an intent to implement and ship a block on port 10080: https://groups.google.com/a/chromium.org/g/blink-dev/c/CNpLNXx2wf0/m/Ehi3cx1YAQAJ

I can retract it if there is disagreement here, but I have convinced myself of the necessity and I would like to move ahead with a block.

[annevk]

That's great. With Chrome and Firefox blocking, anyone want to update the specification and tests?

[youennf]

@ricea, thanks for doing this.
I am updating WebKit at https://bugs.webkit.org/show_bug.cgi?id=224432.
WPT PR at web-platform-tests/wpt#28445.

[annevk]

Thanks @youennf! I created #1214 for the specification.

[ricea]

Belated data about usage of port 10080 from Chrome's stable channel:

Port	Percent
69	0.00%
137	0.00%
161	0.00%
554	0.32%
1719	0.77%
1720	0.69%
1723	0.87%
6566	0.22%
10080	97.12%

The percentages are relative to all ports affected by Slipstream vulnerabilities, so they only represent about a millionth of all requests overall.

There's some bias in the data from the fact we're already blocking all these ports except for 10080.

Incidentally, the block of port 10080 is shipping to stable this week in Chrome version 91.

[MSDNAndi]

Some more port 10080 usage. https://docs.microsoft.com/en-us/windows/uwp/debug-test-perf/device-portal
https://docs.microsoft.com/en-us/windows/mixed-reality/develop/platform-capabilities-and-apis/using-the-windows-device-portal

[NattyNarwhal]

Zend Server defaults to 10080. There's been a lot of reports on mailing lists like Midrange, and certainly calls from clients at work why their Zend sites stopped working when they updated their browser.

[SiliconExarch]

Zend Server defaults to 10080. There's been a lot of reports on mailing lists like Midrange, and certainly calls from clients at work why their Zend sites stopped working when they updated their browser.

Not sure if this is due to running on Zend but I've seen reports of at least one captive wifi deployment being affected meaning Android users running the latest System Webview can't authenticate.

Example

[asiplas]

Zend Server defaults to 10080. There's been a lot of reports on mailing lists like Midrange, and certainly calls from clients at work why their Zend sites stopped working when they updated their browser.

Not sure if this is due to running on Zend but I've seen reports of at least one captive wifi deployment being affected meaning Android users running the latest System Webview can't authenticate.

Example

I can confirm this breaks captive portal (“Guest Wifi”) per the above on the Linksys WRT1900AC – users cannot login after android detects captive portal and pops up native browser.

See also

• https://www.reddit.com/r/HomeNetworking/comments/nyr6il/tcp_port_10080_blocked_by_google_chrome/
• https://stackoverflow.com/questions/27209915/bash-curl-wget-with-linksys-guest-network .