Public Wi-Fi hotspots can sometimes be crippled to the point of unusability. Here’s how to “fix” them and make them more useful.
One such network I dealt with recently mandated HTTP Strict Transport Security, but used an invalid certificate which (by nature of HSTS) could not be overridden. I couldn’t access any search engine or Gmail. And with every site moving to SSL these days I was having a really hard time accessing anything.
My remote access options were even more limited. Of course SSH, FTP and RDP were explicitly blocked.
It’s important to note that if company policy says you shouldn’t access something then you should respect that. In my case there were people around me connecting to Facebook and Gmail just fine so it was clear this was a technical issue.
Of course nobody on-site is capable of fixing the thing or knows who to call to do so or is willing to do so, so let’s take matters into our own hands.
Hide it in your SOCKS.
Enter the role of the proxy server. A proxy server normally sits at the perimeter of an internal network and handles requests for traffic to and from the outside world. To communicate with this server, applications use the SOCKS protocol. SOCKS can then manipulate the traffic according to the needs of the organization’s security policy and either allow or reject it.
If you consider your individual computer to be its own network, we’re going to install a SOCKS server on it to handle your outgoing traffic. The reason for this is so we can allow your traffic to go out but force it through a channel that the firewall won’t object to.
On your client Linux machine (the one that’s being blocked), you probably have regular unencrypted HTTP access, so download tsocks and edit its configuration:
sudo apt-get install tsocks sudo nano /etc/tsocks.conf
At the bottom of the file, comment out the lines for “server” and “server_port” (add a # to the beginning of those lines). Then add your own lines:
server = 127.0.0.1 server_port = 1080
Congratulations, setting up a basic SOCKS server was that easy.
Now, you need someone or something on the other side of the firewall that you’ll connect to and have it relay your traffic for you.
This can be your home PC or a dedicated server you lease. If it’s your home PC, you need to have a Linux machine with SSHD running and listening on port 443 (port 22 is the default but it’s usually blocked). Your firewall must also have 443 open.
Why port 443? It’s used for secure web traffic, which is usually allowed free passage through most firewalls. It is an obvious choice for a communications channel with the outside.
Otherwise, you can buy an outside friend in the form of an Amazon EC2 instance. You get usage of a dedicated server for a few cents per hour; it’s a negligible cost, especially if you turn it off when you’re done. Create a Linux instance and in the security wizard be sure to open ports 22 (SSH) and 443 (HTTPS) since we’ll be using both.
Configuring sshd to listen to 443
Fire up your instance and connect to it. You’ll need to edit /etc/ssh/sshd_config to make sshd listen on a port you can actually reach from behind the firewall. 443 will almost universally do the trick.
sudo nano /etc/ssh/sshd_config
Under the second line or so where it says “Port 22” add a second line that says:
Then restart sshd:
sudo service ssh restart
Great, so now you have a SOCKS server on your laptop that we’re going to use to shove all HTTP traffic over port 1080. You also have a server on the outside that’s listening on port 443. The next thing to do is connect internal port 1080 to external port 443.
Go back to your laptop. The following command will establish a connection with your outside server on port 443 by way of local port 1080:
ssh -i awskey.pem [email protected] -p 443 -D 1080
The above command executes ssh in interactive mode using keyfile awskey.pem. We’re connecting as “ubuntu” to amazon.ec2.instance.com, at port 443. This much is nothing special; it’s how one connects to any EC2 instance, save the additional step of connecting to a port other than 22.
The -D tells the ssh connection to listen for incoming local connections on port 1080, which also happens to be the port we set up for the SOCKS server…do you see the connection?
(By the way, this would be a good time to make sure you have a firewall up, otherwise anybody around you might be able to connect to your proxy and route their own traffic through your tunnel.)
At this point you’ll see that your connection goes through and you’ll be sitting at a prompt on your remote server. Minimize it but don’t close it; we need it to be running, but we don’t need to do anything with it any further.
At this point, any traffic that you send to localhost at port 1080 is going straight over the encrypted tunnel and seeing the light of day at your server’s location. All that’s left is to tell your applications to put their traffic into the bag for delivery rather than trying to walk out the front door.
If you now go into Firefox, to Preferences / Advanced / Network and select “Choose how Firefox connects to the internet,” you’ll see options for plugging in values pertaining to a SOCKS server. You can put in 127.0.0.1 as a SOCKS v5 server, but do make sure you check “Remote DNS.” If you don’t, Firefox is going to attempt to do its DNS lookups on the network that’s blocking you, which isn’t likely to succeed (and is likely to be recorded, depending on what you’re trying to do). Checking this box will have your outside man handle both your connection and your DNS lookups.
Note: Put 127.0.0.1 in the SOCKS Host field. The other fields should be blank. If you do this wrong, DNS queries will not resolve and no pages will load.
You can do this another way though. Let Firefox stay on “auto-detect proxy settings” or “use system proxy settings” but do make sure “Remote DNS” is checked.
From a new terminal window, use the tsocks command with the network application of your choice to launch it. That application should launch using the SOCKS proxy for its connectivity instead of your default routes, which are blocked. All requests for connectivity (should) be made over the encrypted channel between you and your outside server.
tsocks firefox tsocks filezilla tsocks pidgin
So what did this do?
What we did was set up a SOCKS proxy on your own computer.
We made it so that select applications requesting forbidden internet access should go about it by contacting the SOCKS proxy on your own computer, which disguises that traffic as something that the firewall will allow through.
Once it gets past the firewall, we have a shell waiting on the outside to receive that traffic, extract the smuggled contents and send those contents along to where they were supposed to go.
Best of all? From start to finish, everything is encrypted because it’s being sent over ssh so it’s slightly more secure than using the hotspot as-is.