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](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/), 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.