Why would a library block non-standard destination ports? …Circumventions…
There are two ways to get online at the library:
- bring your own device → wifi
- 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:
- What is the rationale? What security problem is the library trying to control by blocking uncommon ports?
- 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.
![](https://kbin.burggit.moe/media/cache/resolve/entry_thumb/d5/dc/d5dc1c60a0853effaf0c149b32fa92e2f83e842221466c0c751808ece3e09040.png)
Add comment