Hotspot Tunneling
by Samjack
Wi-Fi hotspots such as those at your local coffee shop are wonderfully convenient.
They let you get your browsing, email, and IM fix while having a snack and actually socializing with others in person. The problem is that for it to be a good hotspot, anyone needs to be able to use it.
Now you are really "socializing" with the others around you since they can read your email, instant messaging, and see what you are web browsing.
Previous articles in 2600 have touched upon the fundamentals of using SSH (Secure Shell) to solve our little problem. You can check out "Remote Computing Secured" by Xphile in 20:4 as well as "Traversing the Corporate Firewall" by superbeast in 20:2.
The common concept is that of port forwarding.
Use an encrypted SSH tunnel to a destination you reasonably trust and direct your activities through it. This encrypts your easy to read traffic over the exposed link of the wireless until it comes out of the SSH server and looks like normal traffic originating from there. Now our friends in the coffee shop cannot read our email, instant messaging, or web pages unless they control the SSH server or the network it is on.
Port Forwarding
Different kinds of net traffic travel over different TCP/IP ports. SSH is only capable of forwarding TCP (connection oriented) port connections. Fortunately, the three things we want to keep private are TCP based.
There are three types of port forwarding in SSH. These are local, remote, and dynamic. The local and dynamic are what we need to solve our problem. The trick with port forwarding of any type is to think of it relative to the SSH server or client depending on the type of forwarding.
If we web browse a site that tells us what IP we are coming from it will report the IP of the SSH server, not our laptop in the coffee house.
Local Port Forwarding: This makes the SSH client listen on a certain port, then forward the traffic to the SSH server. The SSH server then sends the traffic on to the destination IP and port we specify.
Destination Relative to SSH Server - SSH Command Line Option: -L LocalPort:DestinationIP:DestinationPort
Remote Port Forwarding: This makes the SSH server listen on a certain port, then forward the traffic back to the SSH client. The SSH client then sends the traffic on to the destination IP and port we specify.
Destination Relative to SSH Client - SSH Command Line Option: -R RemotePort:DestinationIP:DestinationPort
Dynamic Port Forwarding: This makes the SSH client listen on a certain port pretending to be a SOCKS4 proxy server. All traffic going to that "proxy" gets sent through the SSH connection to the SSH server. The SSH server then sends the traffic on to the destination such as www.2600.com. The best part is anything that supports SOCKS proxy can use this option. Keep that in mind when we get to our instant messaging client.
Destination Relative to SSH Server - SSH Command Line Option: -D LocalPort
Choosing an SSH Server
We have several options for a trusted SSH server.
We can check for an ISP that allows console login for our account on a *NIX box that has SSH running or we can setup SSH server at home on our high-speed connection.
A good free shell site is at the Free Shell Project: www.hbx.us/shells. (Of course, you have to trust their boxes not to be sniffing all your traffic. Just SSH to nova.hbx.us with login and password of new to set up an account.)
SSH Client
For *NIX users most installations have SSH already installed.
We will need to execute the following command. Windows users may also use this command if they have Cygwin installed (see www.cygwin.com). An explanation of Cygwin is beyond this article.
Let us breakdown the command line:
-l username is where you specify the username to login to the remote SSH server.
-L 25:mailserver:25 tells our SSH client to listen on local port 25 (SMTP), send any traffic to it through the tunnel, and have the SSH server resend it to the desired mailserver on port 25.
-L 110:mailserver:110 tells our SSH client to listen on local port 110 (POP3), send any traffic to it through the tunnel, and have the SSH server resend it to the desired mailserver on port 110.
-D 8000 tells the client to listen on local port 8000 and emulate a SOCKS proxy server. Any traffic will be sent through the tunnel and off to its desired destination from the SSH server.
For Windows users you can also use PuTTY in addition to Cygwin. PuTTY is a GUI program that lets you do things like Telnet, rlogin, and of course SSH. You will find the port forwarding options on the SSH -> Tunnels category tree selection. Make sure to add the ports you enter and then go back and save your configuration on the Session category selection so you can reuse your setup later.
Encrypting the Email, IM, and Web Traffic
Now we have our SSH session to a reasonably trusted server to act as our proxy traffic point.
The session forwards the ports we need to cover our email, IM, and web browsing. We need to go into our actual client programs for those functions and tell them to use the encrypted tunnel.
Note if you use a software firewall on your laptop such as ZoneAlarm you may need to allow your system to let the SSH client listen on ports.
Our email client is easy enough.
Go into your mail client settings and change your SMTP and POP3 server to be localhost. Your email traffic from your laptop to the SSH server will be encrypted if you properly stated your real mailserver in the command line section: -L 25:mailserver:25 -L 110:mailserver:110 replacing the mailserver as your real one. Try sending and receiving some email.
Instant messaging is a little trickier.
Depending on what client you use for IM it may or may not support SOCKS4 proxy. If your client does not you should check into changing over to Trillian from www.ceruleanstudios.com. You can use this one client for all the major IM services such as AOL and MSN. Trillian can then be told to use proxy by going into Preferences -> General -> Proxy.
Check Use Proxy -> SOCKS4 and specify localhost as the proxy server. Now restart Trillian while the SSH tunnel is up and you should get connected.
Web browsing is the easiest.
Just go into your browser options and specify localhost as the SOCKS proxy server. One note: If you use Internet Explorer, you need to go into your Internet Options -> Connection Tab -> LAN Settings -> Use a Proxy -> Advanced.
You must make sure only localhost and port 8000 (port per our example) are specified. All else should be blank or web browsing will not work properly through our SSH tunnel.
The quick and dirty check that your email, IM, and web browsing are going through the tunnel?
Shut down your SSH client, whichever one you chose to use. Then try your apps again. If they fail then you know the tunnel has to be up for them to work. If you are really diligent you could get a buddy to sniff your traffic and see if he gets anything useful.
Hello to whomever hijacked the pay-for-use wireless access system in Dallas/Ft. Worth airport. Setting folks' default IE home page to http://we-know-where-you-live is sure to inspire paranoia. Thanks for proving my point that public wireless cannot be trusted. So, best wishes to everyone in using SSH to cover your plaintext traffic over public wireless.