IRC over Tor hidden services: client/server tutorial

Last thursday I set up access to one of the Telecomix chat servers via the Tor hidden services. Since I tend to forget stuff very easily, I’ll just scribble down here how I did it.

So, the server which I’m running one out of several IRC-servers on is called solarworks and is on the picture above. It is an old sparc-machine, which means that the version of the Tor software is a bit outdated.

Anyways, Tor is in the standard repositories of Debian Linux, so just do an apt-get install tor tor-geoipdb and it is up and running. On other distributions and operating systems, install is almost as easy. See Tor Project.

Then you want to create a hidden service inside the Tor darknet and make it point to the irc servers. As root, edit the /etc/tor/torrc file. Under the section for location-hidden services you add:

HiddenServiceDir /var/lib/tor/hidden_service/

HiddenServicePort 6667

What you did here was basically to specify one directory (the default one) where the private encryption keys go, then you tell the tunnel to go from port 6667 (default irc) to your local machine on port 6667 (where my IRC-server is listening). A hidden service never leaves the encrypted network, so you don’t actually need SSL. But, it works fine with an SSL enabled port as well (double encryption is double fun).

Then you save and restart Tor with /etc/init.d/tor restart and browse over to /var/lib/tor/hidden_service and run cat on the file hostname.

root@solarworks:/var/lib/tor/hidden_service# cat hostname

hsctwsqfsl7ejbh7.onion* weoq7a4exzcyaasj.onion

There you have the .onion address for the tunnel! Now, other Tor users can go straight to my IRC-server without ever leaving the darknet (thus without exposing oneself to an exit node on vanilla internet). It works similar as the ”local destinations” in the i2p darknet, which of course Telecomix also supports.

Client configuration

As a client you will also need to create a ”client tunnel”. This is equally easy. On the client machine, edit /etc/tor/torrc and under location-hidden services you just add something like:

mapaddress weoq7a4exzcyaasj.onion

This instructs the client machine to connect to the .onion destination via a randomly selected IP-number (choosing is a good way of avoiding conflicts with home routers, which usually use 192.168.x.x-series).

Restart Tor, and then you are done. Just torify you IRC-client of choice, for example torify irssi or torify pidgin and have them connect to an IRC-server on on port 6667, and you will end up on the solarworks machine of the Telecomix network. Once in a channel, you will appear to be coming from localhost, since the tunnel leads from your machine to my machine. Encrypted all the way, and made anonymous through the onion routing of Tor.

Pretty smooth, I would say!

Footnote: Since the time of publication of this post I moved everything to a new server and thus had to create a new hidden service (I’m sure you can export the keys if necessary though). This is why the .onion address has been updated to weoq7a4exzcyaasj.onion (with SSL on 6697). See for a list of servers in the TCX network.

9 reaktioner till “IRC over Tor hidden services: client/server tutorial”

  1. The term ”darknet” is usually reserved for networks where every peer is only aware of the existence of the peers it is connected to, i.e. a friend-to-friend design. The Tor network maintains a public list of peers that other peers can connect to, so it’s not ”dark” in that sense.

    Great guide though!

    An alternative method is to simply run an exit node on the same machine as the regular IRC server. Then users can force their Tor node to connect to the IRC server through that exit node by using the address, where is the name of the IRC server and is the address of the exit node (which in this case should be the same machine). When Tor resolves a domain name that ends in .exit it will only use tunnels that end at the designated exit node.

    A true hidden service is better though since it forces the user to connect using the invisible method.

  2. ANNM: Yes, the term ”darknet” is somewhat unclear in many respects. The first notion of it was in the Microsoft whitepaper on P2P-networks, but after that it has taken somewhat a different meaning I guess. In this post, I use it to describe encrypted networks that do some kind of ”garlic” or ”onion” style routing. Might not be the original sense of the term, but it includes i2p and tor.

    Yes, I read up on what I think you mean as ”exit enclaves”, which is a ”destined” exit node. I am still very new to the tor concept (began learning i2p first).

    Thanks for the comment! all new knowledge is very appreciated on these technologies!

  3. @ANNM The .exit notation is disabled by default as of Tor, due to potential application-level attacks.

    Re darknet or not, a user of Tor hidden services doesn’t know which of the public relays it’s using. And for being public, IP addresses of nodes in a network like i2p are not secret, they are just not published.

  4. Linus:
    Oh, I did not know that. It’s a very convenient trick to use when you’re e.g. logging in on websites that don’t like it when you change IP addresses in the middle of a session. I suppose it can be dangerous for applications where the address is sent as part of the protocol (e.g. HTTP 1.1). That shouldn’t be the case when you use MapAddress and the .exit notation in combination though – is that also disabled by default?

    I did not mean exit enclaves specifically – as I understand it real ExitEnclaves work automatically, i.e. the user doesn’t need to tell his/her node to use the enclave as the exit node for the particular address it’s an ExitEnclave for, it will do so automatically (_if_ the users node has downloaded the part of the node directory where that ExitEnclave is listed). Also, as far as I understand it ExitEnclaves are only ”preferential”, i.e. the users node will use the ExitEnclave as the exit node _if_ it can create a circuit to it, otherwise it will use another exit node. When the user uses the .exit notation explicitly, Tor will simply fail to connect if it can’t create a circuit to the desired exit node. Which may or may not be what you want, depending on whether you care more about usability or potential leaks for this particular connection.

    And regarding potential leaks, there is a (tiny) added risk for users that rely on Tor resolving the .onion domain name instead of mapping it to an IP address using MapAddress – if they at some point forget to use torify when starting their IRC client, it will try to resolve the .onion address using the normal DNS servers (probably at their ISP) and anyone watching that traffic will know that the user is trying to connect to that hidden service. But now we’re at a pretty high paranoia level…

  5. Linus:
    After some experimenting it looks like at least my installed version of torify does _not_ handle name lookups, I simply get an ”unknown host” when I try to connect to an .onion address. And the man page says

    ”torify is a simple wrapper that calls tsocks with a tor specific con‐
    figuration file.
    You should also be aware that the way tsocks currently works only TCP
    connections are socksified. Be aware that this will in most circum‐
    stances not include hostname lookups which would still be routed
    through your normal system resolver to your usual resolving name‐

    usewithtor/torsocks seems to work though.

  6. To me it only works if I torify. But I only have the tor packages installed, not privoxy or vidalia.

    Also I tried out some ssh over tor using the same method, but also here I have to use torify.

    Maybe it is only me doing something wrong…


E-postadressen publiceras inte. Obligatoriska fält är märkta *

Time limit is exhausted. Please reload CAPTCHA.