Socks over ssh

Marcos Dione — Sun, 09 Aug 2015 17:37:21 GMT

Soon I'll be changing jobs, going from one MegaCorp to another. The problem is, my current workplace already has a silly security policy that does not allow you to use IRC or do HTTP against a dynamic DNS/IP (like the one at home), but happily lets you use webmails through which you can send anyone the company's IP without leaving much trace. Furthermore, my next assignment will have stricter Internet policy, so I finally sit down to see alternatives to have more traffic with the less footprint.

As I already mentioned, back home I have ssh listening on port 443 (and the port forwarded from the router to the server), and this worked for a while. Then these connections were shutdown, so I used stunnel on the server and openssl s_client plus some ssh config magic to go over that. This allowed me to use screen and irssi to do IRC and that was enough for a while. This meant I could talk to the communities around the tools and libs we were using.

But now I plan to change the way I do my mail. So far the setup includes using fetchmail to bring everything to that server, then use dovecot and/or a webmail to check from anywhere. But as ports are filtered and I already use 443 for ssh, I can't connect to IMAPS and I don't want to use something like sslh to multiple ssh and https on the same port because it sounds to ohacky, I turned towards SOCKS proxying.

Setting up a SOCKS proxy through ssh is simple. Most of the tutorials you'll find online use putty, but here I'll show how to translate those to the CLI client:

Host home
    Hostname www.xxx.yyy.zzz  # do not even do a DNS req; the IP is mostly static for me
    Port 443
    ProxyCommand openssl s_client -connect %h:%p -quiet 2>/dev/null
    DynamicForward 9050  # this is the line that gives you a SOCKS proxy

Then the next step is to configure each of your clients to use it. Most clients have an option for that, but when not, you need a proxyfier. For instance, even when KDE has a global setting for the SOCKS proxy, kopete does not seem to honor it. These proxifyers work by redirecting any connect(), gethostbyname() and most probably others to the SOCKS proxy. One of the best sources for SOCKS configuration is TOR's wiki, which heavily relies on SOCKS proxies, but right now the proxyfier they suggest (dante-client) does not install on my Debian setup, so I went with proxychains. Its final config is quite simple:

# Strict - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# all proxies must be online to play in chain
# otherwise EINTR is returned to the app
strict_chain

# Proxy DNS requests - no leak for DNS data
proxy_dns

# Some timeouts in milliseconds
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
# defaults set to "tor"
socks5  127.0.0.1 9050

In fact, that's the default config with only one modification: the SOCKS protocol is forced to 5, so we can do DNS requests with its UDP support.

With this simple setup I managed to connect to my XMMP server with kopete, which is already a lot. Next step will be to figure out the mail setup and I can call this done.

Ssl3_Get_Record wrong version number

Marcos Dione — Mon, 02 Dec 2013 08:19:54 GMT

Since I work in MegaCorp I found a new level of security policy; for me this is a low point: I not only can't ssh home; since I changed my DynDNS provider from dym.com to afraid.org, I can't even access my webserver because the proxy denies me access citing: Your request was denied because of its content categorization: "Dynamic DNS Host;Suspicious". So I can access lots of questionable contents using Google cache but not my own photos, fine.

At the beginning, the classical trick of making the ssh server to listen in the port 443 worked fine, but at some point Network Operations managed to close that hole. This change was not communicated, so it's not clear that it was completely on purpose. I once asked for the Network Usage Policy, if it exists, but the unofficial answer was on the lines of «I'm not sure you really want to ask».

So, I managed to pierce the firewall again with a further trick: wrapping ssh traffic in a SSL connection. This makes the traffic look like regular https traffic (remember, the s stands for SSL/TLS) but it encrypts the traffic twice.

Everything was smooth again, until the server crashed due to a lack of power. After I powered it on again, I found that I couldn't connect anymore. This morning I decided to take a couple of minutes to figure out why. The ssh client tells me this:

$ ssh -v -o 'ProxyCommand openssl s_client -connect %h:%p -quiet 2>/dev/null' -p 443 foo.afraid.org
OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Executing proxy command: exec openssl s_client -connect foo.afraid.org:443 -quiet 2>/dev/null
debug1: permanently_drop_suid: 1004
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024
debug1: identity file /home/user/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host

Not much info, really. Form the server side I have this:

SSL_accept: 1408F10B: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket

Nice, a cryptic error message, at least for me. Strange enough, openssl by itself manages to connect alright:

$ openssl s_client -connect foo.afraid.org:443 -ssl3
CONNECTED(00000003)
[...]
SSH-2.0-OpenSSH_6.2p2 Debian-6

That's the ssh server saying hi. After some DDG'ing¹ I find this post in serverfault. The first answer itself is not very helpful, but the second one is actually the OP saying how he solved it. It's telling stunnel to accept any version of SSL client while telling SSL to ignore SSLv2. I don't understand how it fixes it, but it works, yay!

DuckDuckGo is getting better by the day. ↩

.:: Marcos Dione/StyXman's glob ::. (Posts about piercing)

Socks over ssh

Ssl3_Get_Record wrong version number