There are two ways to get online at the library:

  1. bring your own device → wifi
  2. use the library’s Windows PCs

I needed to grab content from http://$host:$highPortNum/$path…

The connection worked on the library’s own PCs, but kept dying part way into the fetch at very different points on the different repeated attempts.

So I tried a BYOD (laptop) over wifi. This was a non-starter with immediate failure:

$ wget $URL
Connecting to $HOST:$largePort... connected.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.
Retrying.

This behavior breaks many of the Internet radio stations I listen to, as well as more important fetches. The workaround I found was to simply prefix wget with torsocks to go over the Tor network.

Apparently the library’s network decides “this PC is untrusted, so only allow certain ports (e.g. 80)”. Questions:

  1. What is the rationale? What security problem is the library trying to control by blocking uncommon ports?
  2. Are there more clever circumventions than using Tor? Streaming radio over Tor is perhaps a bit needlessly wasteful.

One thought is to configure tor (if possible) to have just one hop, which would give up the needless anonymity in order to put less burden on the tor network. Is that possible? Otherwise, a VPN is the other thought but that has other downsides.

  • kbal@fedia.io
    link
    fedilink
    arrow-up
    1
    ·
    6 months ago

    Places with firewalls just restrictive enough to be annoying like that sometimes try to block well-known VPN providers as well, so you may need to use a less common one or set up your own proxy if Tor isn’t good enough. One simpler way if all you want to do is connect to those few specific servers is to use ssh port forwarding, if you happen to have a shell account somewhere (the use of wget suggests it might be not too unlikely.)

    Given that it’s easily circumvented as you’ve found, I don’t think there’s any legit security reason for institutions to block things like that, but they usually don’t put much thought into it and it seems to happen pretty often. It’s only if they lock things down more tightly that it’d do anything arguably useful, which would presumably be more obvsiously incompatible with their mission in the case of a public library.

    Then again, maybe something else is going on because they haven’t blocked the port completely: It does connect before getting that error.