Dear future self,

If you are reading this, you are remembering a time when you ran into a really nasty interception proxy¹ and you are looking for a way around it. Do you remember when you were sitting in the Denver International Airport using their free wireless service? And remember how it inserted advertising banners in HTML frames at the top of random web pages as you surfed?

After about a half an hour of this, you started looking for solutions and found that the secure shell client can act as a SOCKS proxy². Using ‘ssh’, you set up a tunnel between your laptop and a server in the office that encrypted and effectively hid all of your network communications from the interception proxy. And if you are reading this again you want to remember how you did it.

Set up the SOCKS proxy

ssh -D 9050 [username]@[remote.server.name]

To refresh your memory, here is an extract from the ‘ssh’ manual page for the -D option:

-D [bind_address:]port

Specifies a local “dynamic” application-level port forwarding. This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address. Whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server. Only root can forward privileged ports. Dynamic port forwardings can also be specified in the configuration file.

Using the SOCKS proxy

Next you need to tell the applications to use the SOCKS proxy. If you are still using a Mac when you are reading this, you’ll probably have it pretty easy. Mac OSX lets you set a proxy system-wide that all well-written Mac applications will use to get their parameters. It is in the “Proxies” tab of the Advanced… network settings. On Mac OSX version 10.5 (Leopard), it looks like the graphic to the right.

If you’re using some sort of UNIX variant, the application may have a setting to use a SOCKS client, or you may need to use the ‘tsocks‘ shim that intercepts the network calls of the application. And, future self, if you are using a Microsoft Windows box right now, please remember how much simpler life was when you used a Mac or Linux desktop. If you find yourself in such a spot, some reader of this blog posting may have left a comment for you below that will help you use a SOCKS proxy with a Windows platform.

Hope this helps. Sincerely,

Self, circa February 2008

Footnotes

1. Version of the “Proxy Server” Wikipedia page when this posting was written
2. Version of the SOCKS Wikipedia page when this posting was written

Mike Teets of OCLC and I teamed up to write an article on Metasearch Authentication and Access Management for this month’s D-Lib Magazine. The first part of the article is a bit of a primer on access management techniques followed by a survey and analysis of access management schemes in use last year. The key part, I think, is the “Recommendations” (access restrictions by IP address plus authenticated proxy servers is the best one can hope for right now) and “Next Steps” (Shibboleth is superior to other access control mechanisms beyond IP/proxy that one might consider, but there is lots of work to be done).

The last paragraph of the article sets out the questions:

In the space between “good enough” (the status quo) and “ideal” (Shibboleth federations) lie many questions for our community. For libraries there are questions like “Are IP address access management and proxy servers sufficient to meet your current and future needs?” and “How much more are you willing to spend on an implementation of a Shibboleth environment?” For content providers: “Are you satisfied with IP address access management and proxy servers for protecting your intellectual property?” and “Can you implement Shibboleth as a common access management system for interaction with metasearch engines (and possibly end-user access)?” And for metasearch service providers: “What kinds of requirements are you willing satisfy?” and “What are you willing to charge?” The NISO Metasearch Initiative Task Group on Access Management encourages the broad community to discuss these questions. NISO is committed to working with the Shibboleth developers to develop practical solutions to the issues raised.

So there are the questions, as best Mike and I can describe. What do you think?