When I was in 6th form and I wanted to get SSH access to my own systems I had quite a few issues doing so, Since port 22 was blocked and just about every other port was, For the first year that was fine however since I had learned that port 443 (the one used for SSL) was not only unblocked but not touched at all by anything, You could pass any traffic you wanted into it
So with that I had setup rinetd to redirect port 443 to port 22. Simple.
Worked a treat and had the upshot that SSH can provide SOCKS 5 proxies.
I bought some software called AllProxy and used that to rewrite applications that didn’t support SOCKS5 proxies and then I was able to use all my software on the system as if I was in a non locked down net.
The rather more annoying issue with this was that the year I had returned, Either they had noticed large amounts of traffic going in and out of HTTPS ports that they had rate limited 443, not 100% breaking my setup but it had slowed it down to a very uncool 35kb/s making it very hard to use.
Giving that most of my computing work was done on remote servers I was not really prepared into giving up the convenience of that.
At this point I had looked at all sorts of ways of getting around this. DNS tunnelling was far too slow, and buying a 3G sim for my laptop’s WAN card was pointless since there was no signal in most buildings.
At this point as well I had began probing the HTTP proxy that had been enforcing keyword lockdown and domain lockdown.
It looked like a very simple IP Tables job that was rewriting anything going out into a squid proxy server. This however did mean you could not pipe what every you wanted into port 80 and it would appear out the other end, since it had to be something that squid would understand.
The rate limiting had not been applied to the (filtered) port 80 traffic.
This meant I could download large files, as fast as I wanted. And this soon began to be the only way of obtaining (high speed) net access.
This gave me a idea, If I could open two connections, one normal looking HTTP GET and one plain HTTPS post, I could glue them together, as long as the other end sent HTTP headers to satisfy the squid proxy on the other end, I could then say that it was providing and very large file, while all the upstream traffic from my laptop would go into the 443 port.
A quick prototype was made in C# (If I ever find it again I will post it) and I was off!
It worked fine, I had to bootstrap it with Tor to setup the system in the first place, but once I had gotten the thing up, It stayed put for a while, at times the connection would be terminated for a unknown reason, I never fully debugged the issue but I can assume at some point in the SSH cipher text there was a “bad word” and that triggered the keyword filter that there was on HTTP connections, this printing the “blocked” HTML banner and closing the connection.
This served me very well for my last year.
I have now remade the tool in Google Go and put it on Github
This version of the tool has a few major things that make using it a dream.
###Sessions
There are now sessions meaning the tool can be ran all the time, even start more than one connection at a time.
###Single Port
This is a fairly big one, since it now uses a long polling POST request to do the upstream as well, it has no need to use the SSL port at all, freeing any use of any other port.
This is really nice for people stuck in system’s that MITM SSL traffic.
It also means it will work with subdomains, something the old tool did not. When the old version was running I would have to take down the HTTP server on my VPS to do it. Now you can run this on a subdomain.
##Setup
Make sure you have GoLang 1.1 or above installed then clone the git.
###Server
First go into the server directory
cd server
Fetch the things that are needed to run this first:
go get
then build it
go build
You can then run it, If you want to change the port that it listens on, set the PORT env var by doing (in a normal bash shell) export port=80
then run the server program
./server
###Client
First go into the server directory
cd client
Fetch the things that are needed to run this first:
go get
then build it
go build
Then you can look into the usage of the client by running ./client --help or client.exe --help
You will get this in return
NAME:
Newmarket Client - A Client to the Newmarket HTTP Tunnel server
USAGE:
Newmarket Client [global options] command [command options] [arguments...]
VERSION:
0.9
COMMANDS:
help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
--url, -u 'http://localhost:3000' the URL of the Newmarket server
--port, -p '3001' The port you want to listen on
--version, -v print the version
--help, -h show help
The two things you will want to change here is the --url var to point to your remote server that you will be tunnelling to.
Example usage is
client --url http://test.example.com
then connect on the forwarded port (default is 3001)
ssh -p 3001 localhost
Auth like normal and now you are inside your remote server!
or to use the socks system
ssh -p 3001 localhost -D 127.0.0.1:1236
and set your proxy application to use 127.0.0.1:1236 as your proxy!