3

In MDN's proxy example, I have seen that they use 127.0.0.1:65535 as an invalid url (link to the source):

const allow = "DIRECT";
const deny = "PROXY 127.0.0.1:65535";
...
function FindProxyForURL(url, host) {
  if (blockedHosts.indexOf(host) != -1) {
    browser.runtime.sendMessage(`Proxy-blocker: blocked ${url}`);
    return deny;
  }
  return allow;
}

Is there anything special about port 65535? Is it safe to assume that no process will ever listen to that port?

In the documentation of Proxy Auto-Configuration (PAC) files, I did not see a straightforward way to block requests otherwise. For instance, there is DIRECT, PROXY, SOCKS but no REJECT or DENY. I assume that PROXY 127.0.0.1:65535 is the official way to deny requests.

Is it safe to assume that sending requests to 127.0.0.1:65535 will reject them?

Philipp Claßen
  • 41,306
  • 31
  • 146
  • 239

3 Answers3

3

Is it safe to assume that sending requests to 127.0.0.1:65535 will reject them?

No, it's not safe.

It's just the very last port on the local machine. I'm perfectly able to open it without any special privileges and send data to it.

They are simply using it as a valid address but a port that's unlikely to be used. Not the best solution, but probably good enough for example code.

There's no special stipulation and 65535 a valid port for a proxy. If you just happen to run a valid proxy there the example will fail to block.

Xan
  • 74,770
  • 16
  • 179
  • 206
  • Yes, I saw a similar example in the Chrome API, where they redirected all requests to "blackhole". Still, it surprises me that there is no direct way to express your intention. When you say good enough for a example code, do you know if there is a way to make it more robust (for production code)? – Philipp Claßen Aug 18 '17 at 12:39
  • 1
    `proxy` API is probably not the right place to _selectively block_ requests. `webRequest` API is the right tool for it. – Xan Aug 18 '17 at 12:40
  • 1
    Ah, I think you are right. Yes, I remember that there is even a related pull request, which argues that blocking requests is an atypical usage (https://github.com/mdn/webextensions-examples/pull/232). – Philipp Claßen Aug 18 '17 at 12:44
3

Normally "9" is used as the default port for "discard service". 65535 is nothing special but the biggest possible port number. I assume they use it because they believe no one will listen to the port.

However, this approach is not safe because 1) anyone can write a server socket listening to port 65535; and 2) the port number might be randomly allocated to a client as ephemeral port.

Alt Eisen
  • 598
  • 6
  • 9
2

In addition to the other answers, the Discard Protocol (port 9) is the closest equivalent to /dev/null. To quote from the Wikipedia article:

The Discard Protocol is the TCP/UDP equivalent of the Unix filesystem node /dev/null. Such a service is guaranteed to receive what is sent to it and can be used for debugging TCP and/or UDP code requiring a guaranteed reception of payload sent.

On various routers, this TCP or UDP port 9 for the Discard Protocol (or port 7 for the Echo Protocol relaying ICMP datagrams) is also used by default as a proxy to relay Wake-on-LAN (WOL) magic packets from the Internet to hosts on the local network in order to wake up them remotely (these hosts must also have their network adapter configured to accept WOL datagrams and the router must have this proxy setting enabled, and possibly also a configuration of forwarding rules in its embedded firewall to open these ports on the Internet side).

Also blocking requests via the proxy API is not the typical usage. Instead the webRequest API is better suited for blocking requests. There are discussions to change the example.

I assume that explains why there is no explicit support for denying requests in the PAC de facto standard, and why the workarounds of redirecting traffic to unused ports or domains are used.

Community
  • 1
  • 1
Philipp Claßen
  • 41,306
  • 31
  • 146
  • 239
  • 1
    Note that there is a difference between _rejecting_ the connection (as the example seems to rely on) and _silently accepting any input_ (which is, indeed, the `/dev/null` equivalent). It will probably elicit different response/error from Chrome, though of course it will effectively block it. – Xan Aug 18 '17 at 13:03