--------------------------------------------------------------- poum.niij.org

Proof of concept implementation of tor2tcp.

Also available as hidden service via u75jkrt3umu2c7pn.onion:{25,443,465,587}

Clone config files: $ git clone http://ghom.niij.org/repos/tor2tcp-sample.git


Purpose ---------------------------------------------------------------------

Say for example you have a website that you feel comfortable having online
via a public domain name, but you do not feel comfortable having it hosted
on the location of its clearnet IP because $reason (for example you are The
Pirate Bay). Or you want to store all your e-mail in an undisclosed location.
This configuration enables the transferring machine to know as little as
possible about the actual hosting machine (because it's really a .onion)
while using very little resources (i.e. a VPS with 128MB RAM for little
$currency/$timeframe) on the transparent proxy machine and even less time to
set it up.


tl;dr && wtf? ---------------------------------------------------------------

tor2tcp attempts to:

* Have arbitrary internet facing services that actually connect you to a
  hidden service
* Enable TLS handshakes with a hidden service from the regular internet,
  enabling safe transport
* Handle connections via tiny VPS (128MB RAM) proxy machine with no access to
  information at all, except for configuration files and public ssh keys


Lightning talk at 30c3 ------------------------------------------------------

I presented this project at 30c3, a recording of it is available from CCC
(skip to 1:41:05) with a mirror on Youtube. Feel free to take a look at my
slides as well.


Incoming connections --------------------------------------------------------

1.2.3.4 is the IP of our example VPS. The following bits enable us to forward
incoming connections to our hidden service.

For torrc:

  TransPort 1.2.3.4:80
  MapAddress 1.2.3.4 duskgytldkxiuqc6.onion
  Tor2webMode 1 # when ./configure --enable-tor2web-mode

For multiple ports, in our case https and smtp related ports, we can redirect
traffic via iptables:

  iptables -t nat -A PREROUTING -p tcp -d 1.2.3.4 --dport 443 -j REDIRECT --to-ports 80
  iptables -t nat -A PREROUTING -p tcp -d 1.2.3.4 --dport 25 -j REDIRECT --to-ports 80
  iptables -t nat -A PREROUTING -p tcp -d 1.2.3.4 --dport 465 -j REDIRECT --to-ports 80
  iptables -t nat -A PREROUTING -p tcp -d 1.2.3.4 --dport 587 -j REDIRECT --to-ports 80


Receiving E-Mail ------------------------------------------------------------

At Aaron Swartz Hackathon NYC I successfully tested establishing a TLS
encrypted connection with a hidden service from the clearnet: Web, and now
also Mail. There is nothing special about that setup, it is identical to
setting up a hidden service based web and mailserver.


Sending E-Mail --------------------------------------------------------------

Since we don't want to be **** SPAM ****, we need to send all our mail via
the incoming transparent proxy machine. We don't want to turn our proxy into
a mail relay as we want to avoid having any data on that machine (like a mail
queue or logs). To do this in an anonymous fashion, we can use a torified ssh
SOCKS5 tunnel, and redirect Postfix' traffic to that tunnel.

  tmux new-session -d 'torsocks autossh -D 1080 doge@1.2.3.4'

autossh helps us keep the connection to our transparent proxy open, enabling
us to leave the setup unattended, while tmux is just in there because for
some reason backgrounding autossh did not work properly for me.

To be able to make that SOCKS5 tunnel into a transparent proxy, we can use
redsocks. The Debian standard settings worked just fine for me, as they
expect a SOCKS5 proxy to be open at 127.0.0.1:1080.

The last issue that remains is, Postfix chokes on TCP based DNS requests, and
Tor does not yet support MX record lookups, so we need a way to tunnel our DNS
requests as well. dns-tcp-socks-proxy comes in handy here. My dns_proxy.conf
looks like this:

  socks_port = 1080
  socks_addr = 127.0.0.1
  listen_addr = 127.0.0.1
  listen_port = 53
  set_user = nobody
  set_group = nogroup
  resolv_conf = resolv.conf
  log_file = /dev/null

And resolv.conf:

  213.73.91.35
  85.214.20.141
  8.8.8.8
  8.8.4.4

After all of that is up and running, we an finally redirect Postfix' traffic
(including DNS) through our torified SOCKS5 tunnel:

  iptables -t nat -A OUTPUT ! -o lo -p tcp -m owner --uid-owner postfix -m tcp -j REDIRECT --to-ports 12345
  iptables -t nat -A OUTPUT ! -o lo -p udp -m owner --uid-owner postfix -m udp --dport 53 -j REDIRECT --to-ports 53
  iptables -t filter -A OUTPUT -p tcp -m owner --uid-owner postfix -m tcp --dport 12345 -j ACCEPT
  iptables -t filter -A OUTPUT -p udp -m owner --uid-owner postfix -m udp --dport 53 -j ACCEPT
  iptables -t filter -A OUTPUT ! -o lo -m owner --uid-owner postfix -j DROP

And that's it! This should work for other services like XMPP as well. That
needs further testing though.


TODO ------------------------------------------------------------------------

* Test receiving mail via .onion
  * Authenticate .onion origin via DKIM signature of the hidden service key?
  * Revelant literature
* Seperate certificate for .onion
* Stress testing (maybe a RPi as proxy would be sufficient small scale
  mailservers?)


SSL Certificate Fingerprints ------------------------------------------------

Depricated since the move to Let's Encrypt.


Credits ---------------------------------------------------------------------

* Abel Luck for inspiration!
* MacLemon for brain bounces
* ra for co-discovery of incoming connection setup
* Aaron Swartz Hackathon (NYC) for getting me to work on it again


Contact ---------------------------------------------------------------------

m  niij  org / 4096R/6CAC71020AF5D60D
(Fingerprint: 0AA7 9AE2 D160 71DF 98AD  3B07 6CAC 7102 0AF5 D60D)


-----------------------------------------------------------------------------