Continue reading]]> Onioncat is an add-on for anonymization networks such as Tor and I2P. It adds real IP layer networking capability to hosts connected through Tor. Hence it is not enough to just refer to the security of Tor (or I2P). This article discusses security Considerations which are specific to Onioncat. Of course, since Onioncat relies on Tor, most security issues which are valid for the Tor network also apply to Onioncat as well but not completely, because it is a totally different use-case.

Onioncat was specifically designed to work with Tor’s hidden services version 2 and therein Onioncat perfectly integrates into. It will and it does work with different systems as well (e.g. Tor hidden services v3, or I2P) but there are some drawbacks. This will also be explained within this article.

Understanding Onioncat

Although it is assumed that the reader is familiar with Onioncat we still try to explain the essential part of Onioncat in brief.

Onioncat uses the hidden service feature of Tor to connect nodes to each other. Those connections are then used to create plain IPv6 connections between these hosts as if they where connected together on a simple Ethernet switch. That is what every VPN adapter does and so does Onioncat. The difference between Onioncat and other VPN adapters (such as OpenVPN) is that, firstly, Onioncat connects through Tor’s hidden services and not through the Internet or any other VPN service, and, secondly, the “VPN” is not privately administered. Everybody can freely join the network.

Onioncat is a virtual network switch with a built-in secure automatic address selection method.

From this we can derive 3 main topics in respect to security:

1. The security of the network itself. This issue is not discussed within this article.
2. Local network security, because Onioncat “simply” is a virtual network switch.
3. The glue between Onioncat and the Tor network.

Local Network Security

As soon as you run Onioncat, you are connected to a network where you do not know who is on the other side and who will connect to your system. In respect to computer security there is no big difference compared to being connected to the Internet.

People who you do not know may access your system.

If you think you are safe because your system is “just” accessible through a hidden service where Onioncat is attached to, be advised that this is a very dangerous assumption! Hidden services may be enumerated by an attacker or one might run a malicious hidden service directory and grep for hidden service descriptors. Or more simple: Running a single Onioncat instance is pretty useless hence you most probably gave away your hidden service’s onion url (777myonionurl777.onion) to somebody else, e.g. your best friend. Unless this best friend isn’t Ed Snowden you can expect that your onion-URL was immediately revealed to the public (because he sent it to his Office365 or Gmail account, stored it on his “secure” smartphone, Dropbox, or whatever). Although this is not a security risk for neither Tor nor Onioncat it lets attackers access your system.

Accessing the system more specifically means that one could try to connect to some well-known ports or even target a port scanner or a security scanner (e.g. Nessus) at your Onioncat IP. Please note that an attacker may try to reveal your anonymity!

Of course, the risk is much lower than in the Internet but there is still a chance. Thus, all rules of security that apply to public network interfaces also apply to your Onioncat-managed virtual tunnel interface. More specifically consider the following:

• Run a firewall!
• Don’t trust IPs from fd87:d87e:eb43::/48 more than others!
• Use encrypted services!
• Use authentication!
• Do not run public (Internet) services on the same host! This may immediately reveal your anonymity!¹ You may also read the article Onioncat In A Highly Secure Environment. It is not new, but you get an idea.

Be as paranoid as you are in the Internet!

Please note that Onioncat is a layer-3 VPN, meaning it is able to forward any IPv6 and IPv4 packets (if enabled with option -4) but not frames of lower layers, e.g. Ethernet frames. Although Onioncat can be configured to use a TAP device (instead of the TUN device), which is a virtual layer-2 device, it still does not forward (nor process received) Ethernet frames. The Ethernet protocol is handled fully locally between the local Onioncat and the kernel even if it looks like if remote hosts are able to do so (e.g. if you capture with Wireshark). Onioncat emulates this locally. This means that an attacker cannot send ARP requests or other Ethernet broadcasts or similar frames. He cannot use Ethernet-based attack methods but he can send any specifically crafted valid IP packet to you.

There may be an additional risk if your system is connected to the public IPv6 network. If you run any process that tries to connect to any Onioncat service within the network prefix fd87:d87e:eb43::/48 but Onioncat is not running for whatever reason, your system will leak IPv6 packets with a destination IP address of the desired Onioncat destination. An eavesdropper could conclude at least that you are using Onioncat. This is because the packets are caught by the default IPv6 route. To prevent this it is suggested to have a firewall rule in place which drops theses packets.

The Glue Between Onioncat And Tor

IP hosts connected² to each other need IP addresses to be able to communicate. Basically, any IP address is valid and it does not matter which one in particular is chosen as long as they are all within the same network prefix and are not duplicate. Although this applies to Onioncat’s network interface³ as well, the IP addresses are well chosen for security reasons.

Tor does only know about hosts names and in respect to hidden services these host names must end with .onion. In contrast, IP packets are addressed by IP addresses and not onion URLs (obviously). To address a hidden service with an IP address some kind of reverse-lookup has to be done. And here comes Onioncat into play.

Onioncat has an IP-based interface to the kernel and an onion-URL-based TCP interface to Tor and it translates between them. If Onioncat receives an IP packet from the kernel, it extracts the destination IP address, converts it to an onion-URL and asks Tor to build a connection. Once the connection is established, Onioncat internally associates this connection with the IP address and starts sending and receiving IP packets with the desired destination address between the kernel and this connection, i.e. the hidden service on the other side.

Tor’s hidden services are designed to have a fully cryptographic integrity. That means that the client of a hidden service (the one who connects to it) can prove that the onion-URL and the connection is really associated with the correct hidden service. That means that an attacker cannot pretend to be a specific hidden service without being detected.⁴

Onioncat translates the IPv6 addresses to onion-URLs and vice versa in such a way that the cryptographic integrity is kept upright. Onion-URLs of hidden services version 2 are 80 bit long numbers which are presented using Base32-encoding. These 80 bits are directly concatenated to the IPv6 address with the once randomly chosen Onioncat prefix fd87:d87e:eb43:::

              |        777myonionurl777.onion
              |                        |
fd87:d87e:eb43:fffe:cc39:a873:6915:ffff|

Because of this technique onion-URLs and Onioncat’s IPv6 addresses can be used interchangeably. They carry the same amount of information. This has two important consequences:

• The cryptographic integrity of hidden services is kept through Onioncat.
• The translation mechanism is self-contained. There is no need for an external lookup mechanism.

How Does The Hidden Service Identify The Client?

As previously discussed the client can cryptographically make sure to be connected to the right destination. That means that the Onioncat which sends the first packet (i.e. it is an outgoing connection) to a desired destination can be sure that it will be connected to the authentic destination Onioncat.

But how does the destination identify the client? I.e. how does the Onioncat with an incoming connection know who initiated the connection?

At first it does not know. It receives IP packets with a source and a destination IP address but these could be hand-crafted by an attacker. The destination address shall be it’s own IP address. This can easily be checked.

To verify the source uni-directional mode was implemented which is enabled by default since 2013. Onioncat takes the source IPv6 address converts it to an onion-URL and connects back trough Tor with an outgoing connection. All outgoing IP packets are then sent through this outgoing connection and not the incoming one.

An attacker can easily forge the source IP address but not the key and the hash of a hidden service. Thus, the attacker will get no answers back as long as Onioncat is running in uni-directional mode.

Uni-directional mode is disable with option -U, i.e. it then operates in bi-directional mode. In this mode Onioncat directly replies on incoming connections and does not request a return-connection through Tor. The advantage of this method is that there is no additional time lost for the connection setup of Tor and that it is not necessary to configure a hidden service at the client side. In the latter case you could let Onioncat generate a random source IP with option -R.

The following diagram shows three different modes of operation. It is assumed that Onioncat A initiates the connection to Onioncat B. The picture shows a) Onioncat B in unidirectional mode, b) Onioncat B in bi-directional mode, and c) Onioncat B in bi-directional mode and Onioncat A with random source IP. In the latter case Tor A does not have to have a hidden service configured. As a consequence in this setup, Onioncat A can never receive (incoming) connections.

Crafting V2 Hash Collisions

But what if somebody manages to generate a valid key which hashes to exactly the same onion-URL? This is what is called a collision. To create a collision with any random onion-URL the birthday paradox applies, thus you need to generate about 2^40 keys to find any of two pairs with the same hash. However, to find a collision for a specific onion URL (meaning targetting your unique service) your still need 2^79 keys for the same probability to find a collision.

But let’s assume Mallory really manages to generate a valid key with a colliding hash to your service? What will happen?

The onion-URL is the unique primary key within the hidden service directory, thus the hidden service descriptor will be overwritten by the last one. As a consquence all hidden service connections will go to Mallory’s hidden service, Mallory’s Onioncat, and Mallory’s honey host.

Now Mallory can capture all your incoming packets. But because you are paranoid and set up all services to use e.g. TLS (as explained above) you immediately identify that something is wrong before you sent any plain text password.

Of course, we could continue the “But what if…” discussion but this is out of the scope of this article. This chapter shall give you an idea about how to think. Secondly, since this type of attack will become feasibly in the future, the Tor project developed version 3 of hidden services.

Onioncat and HSv3

Development does never end. The Tor project implemented version 3 of hidden services. This shall improve the security of hidden services, in particular if we take modern attack techniques and increased computational power into account.

From a user perspective there is not much difference except that the onion-URLs got signifficantly longer. In particular, v3 onion URLs carry 260 bits of information. If you thouroughly read through this article it should now become obvious that this has a significant impact on Onioncat.

Although it is simple to truncate the 260 bits to 80 to fit into the same IPv6 addressing scheme, there is no easy way back to regenerate this lost information to make a long onion-URL from the IP address again. It requires some kind of lookup mechanism and this in turn has some implications:

• The database wherein the lookup is done or the lookup transaction itself may be tampered.
• The database has to be operated by somebody and may be unavailable.
• Onioncat does not work out-of-the-box in this elegant way as it does with HSv2.

One might immediately think on using DNS since this could be done with a simple reverse-lookup, DNS is not the solution. It is a well-known problem that DNS lookups may compromise your anonymity.

The current solution uses a local text file for translation (see Onioncat and HSv3). But again, it does not work out-of-the-box, you have to setup the hosts file on all Onioncats which shall connect to each other.

I think that a solution should be built into Onioncat, or Tor, or both. But unfortunately I don’t have any solution ready, just some ideas. You’re welcome to think about this!

Conclusion

Security is not something absolute. The level of security which should be chosen depends mainly on the use-case. If you use Onioncat as some kind of VPN (as I do) to be able to connect to all your services even if they are behind a firewall and/or an uplink with dynamic IP addresses, you may choose a lower level of security as if strong anonymity is a requirement because you are residing in some problematic regime.

There are some attacks against hidden services. Although hidden service enumeration seems impractical because of the huge address space of hidden services (even with v2) and the low speed of Tor⁵ there is still a chance of your onion-URL/IPv6 address being leaked.

Tor offers authentication for hidden services but this is not yet implemented into Onioncat. Or more specifically I did not pay any attention to it, yet. It probably should be on the task list. But keep in mind that Onioncat development is a one-man show. Don’t hesitate to join the project

Naturally, best practice network security should be applied.

Because of the effort and the risk which comes with HSv3 in respect to Onioncat, I personally stick to HSv2 for now.

Continue reading]]> Onioncat ist written in a portable manner, thus it runs on almost all operating systems, even on Windows. This document describes how to run Onioncat on a Windows 10 installation together with the Tor browser bundle.

The Windows part of the code was already written in 2008, hence Onioncat on Windows is nothing new. This document is here to meet recent versions of Windows, Tor, and Onioncat.

Preface

If you read this article you probably know what you are doing, aren’t you?

Windows is not the type of operating system which is known for its good security. Onioncat is solely used in conjunction with Tor or I2P, both being anti-surveillance tools. If you intend to use Onioncat you are probably in a situation where security matters and you should consider to use a system which is designed for such circumstances, e.g. Tails, or some other Linux distributions which are much more transparent than Windows.

If you don’t know how to use these other systems but you really need high security you should probably seek advice from somebody near you.

If you’re still happy with Windows go ahead and read on.

Prequisites

Onioncat needs a tunnel device which is a virtual Ethernet adapter. Windows does not natively support such an adapter but OpenVPN includes the necessary driver. Hence you need to download and install OpenVPN from here https://openvpn.net/community-downloads/. Choose the right Windows version. During the setup procedure you can choose the components to install. You can leave the default settings but actually you just need the “TAP Virtual Ethernet Adapter”.

Download and install Tor. It seems that Tor for Windows can only be downloaded as the Tor Browser Bundle but that doesn’t matter. Download and install it from here: https://www.torproject.org/download/. Before running the Tor browser we have to configure it which is explained in the next step.

Download the precompiled Windows 10 files of Onioncat from here: https://www.cypherpunk.at/ocat/download/Windows/. Unzip the archive. The file contains two EXE files and a DLL. Copy these three files to C:\Windows\System32 (note: if you don’t like that, you can keep the files where ever like).

Configure Tor

Before starting the Tor browser (which will start a local Tor node) we need to configure a hidden service.

Open the “File Explorer” and navigate to the folder “This PC > Desktop > Tor Browser > Browser > TorBrowser > Data > Tor”. The folder contains the configuration file of Tor named torrc.

Right-click it, chose “Open with” and select the Notepad. Make sure that the Tor browser is not running because otherwise it will overwrite the file after you edited it. The Notepad will open the file and show its contents. Copy the following lines into it. They configure two hidden services for Onioncat.

HiddenServiceDir TorBrowser\Data\Tor\onioncat_hsv2
HiddenServiceVersion 2
HiddenServicePort 8060 127.0.0.1:8060
HiddenServiceDir TorBrowser\Data\Tor\onioncat_hsv3
HiddenServiceVersion 3
HiddenServicePort 8060 127.0.0.1:8060

Save the file and close the Notepad. Now you can start the Tor browser (there should be an icon on your desktop) and click on “Connect”.

After it started successfully, again go to the File Explorer to the same directory (“This PC > Desktop > Tor Browser > Browser > TorBrowser > Data > Tor”). Two additional folders should have appeared: “onioncat_hsv2” and “onioncat_hsv3”. Navigate into “onioncat_hsv2”, there’s a file named “hostname”. Open it with the Notepad (right-click -> “Open with” -> “Notepad”). The file contains the onion ID of your v2 hidden service, e.g. 2e6c3gboyngav2rq.onion. Keep the file open, you will need this string in the next step.

Configure and Run Onioncat

Now we create a shortcut to run Onioncat. Right-click on the desktop, then “New->Shortcut” and either browse to the ocat.exe (which you copied to C:\Windows\System32\ocat.exe) or just paste the path to it into the text field: C:\Windows\System32\ocat.exe (adjust the path if you keep it somewhere else on your hard drive). Then click “Next” and “Finish”.

Your shortcut icon appears on the desktop. Now right-click on it again and choose “Properties”. The properties window will open. We need to add some command line arguments to Onioncat in the “Target” field: -t 9150 -U 2e6c3gboyngav2rq.onion. Copy the .onion name from the “hostname file” we opened above. Finally, the entry should look like this:

C:\Windows\System32\ocat.exe -t 9150 -U 2e6c3gboyngav2rq.onion

Option -t 9150 is used to tell Onioncat the SOCKS port of Tor. By default this is 9050 but with the Tor browser bundle it was change to 9150. Option -U tells Onioncat to use bidirectional mode (instead of unidirectional). This increases the speed of the connection setup and it may be easier in combination with v3 hidden services (Read Onioncat and Tor hidden services v3 for more information.).

Click “Ok” and start Onioncat simply by double-clicking the shortcut icon. A command window will open and Onioncat will output a bunch of messages like the following:

Test Setup

Tor is running, Onioncat is running, you are ready to test the setup. Actually you need a second Onioncat node somewhere. Of course, a single Onioncat instance doesn’t make much sense

Try to ping another running Onioncat node. Get its IPv6 address and open a command window (type cmd in the Windows search bar on the bottom of the screen and press enter). Now enter the command ping followed by the IPv6 address of the target node. It may take a while (a few seconds) until the first pings will get replied.

C:\Users\dummy> ping fd87:d87e:eb43:4506:3bbb:9faf:5877:4319
 Pinging fd87:d87e:eb43:4506:3bbb:9faf:5877:4319 with 32 bytes of data:
 Request timed out.
 Reply from fd87:d87e:eb43:4506:3bbb:9faf:5877:4319: time=249ms 
 Reply from fd87:d87e:eb43:4506:3bbb:9faf:5877:4319: time=361ms 
 Reply from fd87:d87e:eb43:4506:3bbb:9faf:5877:4319: time=263ms 
 Ping statistics for fd87:d87e:eb43:4506:3bbb:9faf:5877:4319:
     Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
 Approximate round trip times in milli-seconds:
     Minimum = 249ms, Maximum = 361ms, Average = 291ms

Continue reading]]> This is a new version of the Garlicat-HOWTO which I wrote about 10 years ago in November 2009. Actually, this original HOWTO still applies but, anyway, I rewrote it to match the software versions of today, August 2019. This document is based on the I2P router version 0.9.41 and Onioncat 0.2.7, both running on a recent Debian Linux 9.9 system.

This HOWTO explains how to connect two systems named onioncat-A and onioncat-B together using Garlicat and I2P. Of course, the setup is not limited to two hosts, you can connect as many as you like.

What is Garlicat?

Garlicat is Onioncat with a few configuration changes, i.e. Garlicat uses different port numbers and IPv6 addresses than Onioncat but everything else is the same. This difference is made to be able to run Tor and Onioncat, and I2P and Garlicat in parallel on the same host. Hence, everything that applies to Onioncat also applies to Garlicat. The terms can really be used interchangeably.

What is Onioncat?

Onioncat is a VPN adapter which is designed to connect through Tor/I2P to other Onioncats. Thus you can build a VPN between systems based on anonymization networks. No surveillor will be able to monitor your traffic dependent on the strength of your Tor/I2P node and its network.

Preqrequisites

Both systems have to have a working I2P installation, an installed Onioncat 0.2.7, and of course a working Internet connection. Open your I2P router console (usually at http://localhost:7657/) and check the version in left upper corner of the screen.
Then check Onioncat, run ocat -h on the command line. It will output the current version. You can install Onioncat either with your package manager or you can compile and install the latest version of Onioncat from here: https://www.cypherpunk.at/ocat/download/Source/current/ (unpack it, run ./configure, make, and sudo make install, as usual).

Make sure that your system has the ifconfig command installed. Simply run ifconfig as root and see what happens. If it says “ifconfig: command not found” then most probably it is not installed. Modern Linux distributions switched to a different set of network commands (ip) instead, but ifconfig can still be installed. On Debian-based systems ifconfig is found within the net-tools package (install with apt-get install net-tools).

Configure I2P

Onioncat is a client and a server at the same time, meaning that you can connect (as a client) to other Onioncats but you can also accept (like a server) incoming connections from other Onioncats. Hence you have to configure a client and a server tunnel in the I2P router console.

Create Server Tunnel

Open the I2P router console of host onioncat-A at http://localhost:7657/. Scroll down to the bottom of the left sidebar and click on “LOCAL TUNNELS” (http://localhost:7657/i2ptunnelmgr) which will bring up the I2P tunnel manager. Within the box “I2P HIDDEN SERVICES” on the right lower corner select “Standard” and click “Create”. This will bring up the new screen “NEW SERVER SETTINGS”.

Now fill in a name (e.g. “gcat-server”), a description, choose to start it automatically and most importantly set port number 8061.

Scroll down to the bottom of the page and click “Save”. This will bring you back to the tunnel manager and your new Garlicat tunnel shall be listed in the “I2P HIDDEN SERVICES” box. Note the Base32-encoded string shown behind “Destination”. Copy this string to a text file and make a remark for host onioncat-A. We will need this in a later step.

Create Client Tunnel

Now scroll down to the bottom of the “I2P CLIENT TUNNELS” box. Select “Socks 4/4a/5” and click “Create”. Enter a name (e.g. “gcat-client”), a description, choose to start automatically and most importantly enter port number 9051. Finally scroll down and click save.

The I2P router will now try to bring up these tunnels and after a while they should show up in the left side bar under “LOCAL TUNNELS” with a green star.

Now create a server and a client tunnel on the second host onioncat-B in exactly the same way. Don’t forget to note the Base32-encoded destination string. This string is the unique address of your server tunnel within the I2P network. Onioncat will use this address to connect as a client to the server side.

Compile Hosts File

Garlicat needs to translate IPv6 addresses to I2P destinations (.b32.i2p) to be able to connect properly. This translation is done with a simple text file, known as “the hosts file”.

On the command line of host onioncat-A run Garlicat with option -i and the I2P destination address of its own server tunnel (the destination address of the gcat-server tunnel of I2P on onioncat-A):

gcat -i qp3q7cytpx47py64sglsqxtrelq6mwexv2qaigxve3f3qy5milla.b32.i2p

Garlicat will output an IPv6 address, in this case fd60:db4d:ddb5:41af:526c:bb86:3ac4:2d60. Copy this IPv6 address followed by the destination address to your text file. Do the same with the second destination and copy it into the same text file. You can add comments starting with # into the file for better readability. Do the same with the onioncat-B address. Finally, you should end up with a file which looks similar to this (Please note that the IP adress and the destination address are on a single line and not on two separate lines (…web page formatting issue…)!):

# onioncat-A
fd60:db4d:ddb5:41af:526c:bb86:3ac4:2d60 qp3q7cytpx47py64sglsqxtrelq6mwexv2qaigxve3f3qy5milla.b32.i2p
# onioncat-B
fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50 xy2aq6iod6sh6nivnttnb35qxg2ohdljofqba34dhjid3ktk4hsq.b32.i2p

Now copy this file to all of your hosts (which is onioncat-A and onioncat-B in this example) to a specific location, e.g. into your I2P installation directory to /home/<your_username>/i2p/hosts.gc.

Run Garlicat

Now we are ready to run Garlicat. On each host run it with its own destination address as an argument, e.g. on host onioncat-A we start Garlicat as root (e.g. with sudo) with the following command (in one line):

gcat -B -U -g $HOME/i2p/hosts.gc qp3q7cytpx47py64sglsqxtrelq6mwexv2qaigxve3f3qy5milla.b32.i2p

Option -B keeps Garlicat running in the foreground which may be convient for the installation and testing procedure. If -B is omitted, Garlicat will fork to the background and the log messages are written to the syslog.

Side note: Option -g $HOME/i2p/hosts.gc sets the path for the hosts file to be used. If this option is omitted, Onioncat will do the lookup in the system hosts file (/etc/hosts). Option -U disables the unidirectional mode. Although this is not necessary in this setup, with this option the time of connection setup is reduced.

Test the Setup

To test the setup open a new shell on one of your systems. You should be able to ping the other host with the ping6 command:

$ ping6 fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50
 PING fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50(fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50) 56 data bytes
 64 bytes from fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50: icmp_seq=2 ttl=64 time=7304 ms
 64 bytes from fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50: icmp_seq=3 ttl=64 time=6280 ms
 64 bytes from fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50: icmp_seq=4 ttl=64 time=5256 ms
 64 bytes from fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50: icmp_seq=5 ttl=64 time=7314 ms
 64 bytes from fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50: icmp_seq=6 ttl=64 time=6291 ms
 64 bytes from fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50: icmp_seq=7 ttl=64 time=5267 ms

The tunnel setup may take a while (serveral seconds) thus the first few pings may be lost. If this works you can now work with these hosts as with any other VPN, e.g. ssh to it:

eagle@onioncat-A:~$ ssh fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50
 The authenticity of host 'fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50 (fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50)' can't be established.
 ECDSA key fingerprint is SHA256:544ApVFmA1+J2zMNp58zD9aDS2PE8M0s6ly7fo+drqA.
 Are you sure you want to continue connecting (yes/no)? yes
 Warning: Permanently added 'fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50' (ECDSA) to the list of known hosts.
 eagle@fd60:db4d:ddb5:6f8:33a5:3da:a6ae:1e50's password: 
 Linux onioncat-B 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11) x86_64
 The programs included with the Debian GNU/Linux system are free software;
 the exact distribution terms for each program are described in the
 individual files in /usr/share/doc/*/copyright.
 Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
 permitted by applicable law.
 You have new mail.
 Last login: Tue Aug 20 09:28:37 2019 from 192.168.122.1
 eagle@onioncat-B:~$ 

Continue reading]]> For security reasons the Tor project introduced hidden services version 3 (HSv3) which facilitate stronger cryptography to comply with modern needs for security. Onioncat was developed with version 2 of hidden services which are still in place work as expected. Unfortunately HSv3 do not integrate smoothly into the OnionCat concept but nevertheless, with a few additional steps Onioncat still will run perfect with these new HSv3 services.

This HowTo explains how to setup three systems to connect to each other using HSv3. It does not explain technical details, why everything is done in such a way, it simply shall be a step by step procedure to success.

In the following explanation there are three hosts, named onioncat-A, onioncat-B, and onioncat-C which may be any system anywhere in the Internet. This Howto was based on a clean Debian Linux installations but it shall work straight forward on any other system.

Prerequisites

Make sure the systems are properly connected to the Internet.

Tor’s hidden services where implemented into Tor starting with version 0.3.2. Make sure you have at least this version of Tor installed (run tor --version). If you have an older version on your system but you still want to use HSv3 you have to upgrade your Tor installation. Either use your package manager or download, compile, and install the latest version of Tor from https://dist.torproject.org/ .

Although the necessary feature was implemented into Onioncat many years ago, a tiny bug which came up recently prevented it from working correctly. You need to have Onioncat version 0.2.4 or higher on your system for HSv3 to work properly. Make sure you have at least 0.2.4 installed (run ocat -h to see installed version). Use your package manager to upgrade or download, compile, and install the latest version of Onioncat from https://www.cypherpunk.at/ocat/download/Source/current/ .

Make sure that your system has the ifconfig command installed. Simply run ifconfig as root and see what happens. If it says “ifconfig: command not found” then most probably it is not installed. Modern Linux distributions switched to a different set of network commands (ip) instead, but ifconfig can still be installed. On Debian-based systems ifconfig is found within the net-tools package (install with apt-get install net-tools).

Configure Tor

All of yoour Tor client (which are intended to be used with Onioncat) needs to have a hidden service configured.
Edit the Tor configuration file which typically is found at either /etc/torrc or /usr/local/etc/torrc and add the following three lines to each of the three systems (onioncat-a, onioncat-b, and onioncat-c)

HiddenServiceDir /var/lib/tor/onioncat_hsv3
HiddenServiceVersion 3
HiddenServicePort 8060 127.0.0.1:8060

Now run or restart Tor.

Note: Make sure that Tor connects properly to the Tor network. It typically outputs the following text into its logfile if everything is fine: “Bootstrapped 100% (done): Done“.

Compile Onioncat Hosts File

Now we need to create a hosts file. This is a list of your onion hostnames and the according Onioncat ipv6 addresses. It is a single file which can be shared (meaning copied to) between these three hosts. Because of we setup three hosts, the hosts file contains three lines.

On host “onioncat-a” change into the designated hidden service directory of Tor which is /var/lib/tor/onioncat_hsv3 (e.g. cd /var/lib/tor/onioncat_hsv3). We need root permission to do so. Within the directory we find a file named “hostname”. Display the contents of the file (e.g. cat hostname). It contains a string like this: qr4sshhsbcqfyircxqmi77j5pmgcki4keh5f6kybschqjb7xmas3siqd.onion. This is the unique onion name of the hidden service on host onioncat-a. To find the associated IPv6 address run Onioncat with option -i and this hostname as argument: ocat -i qr4sshhsbcqfyircxqmi77j5pmgcki4keh5f6kybschqjb7xmas3siqd.onion. It will output an IPv6 address which in this case is fd87:d87e:eb43:908f:487:f760:25b9:2203.
Create a new empty text file and add a line containing the IPv6 address followed by the hostname. You can add additional hostnames for your personal convenience if you like and you can add descriptive comments starting with a #.
Lookup the hostname and IPv6 address on each of the three systems and add the names and IP addresses to the same text file (the hosts files). Finally you should end up with a file like this (please note that there is no linebreak after the IP address, i.e. there’s just a single line after each comment):

# onioncat-a
fd87:d87e:eb43:908f:487:f760:25b9:2203 qr4sshhsbcqfyircxqmi77j5pmgcki4keh5f6kybschqjb7xmas3siqd.onion onioncat-a
# onioncat-b
fd87:d87e:eb43:6862:da73:63ad:fa91:f203 jbhu6id5htvwx3kahz6o2ms32bms75fbxjhyy2uonbrnu43dvx5jd4qd.onion onioncat-b
# onioncat-c
fd87:d87e:eb43:d1bf:d1c6:8553:559a:fe03 o3cjd437sxzfzobqn7g2ppy3b4j

Copy this file to each of the three hosts, e.g. into the Tor configuration directory at /etc/tor/hosts.oc (or /usr/local/etc/tor/hosts.oc).

Run Onioncat

Now we are ready to run Onioncat. On each host run Onioncat with its own onion hostname as an argument, e.g. on host onioncat-a we start Onioncat as root with the following command (in one line):

ocat -H -g /etc/tor/hosts.oc -U -B qr4sshhsbcqfyircxqmi77j5pmgcki4keh5f6kybschqjb7xmas3siqd.onion

Option -B keeps Onioncat running in foreground which may be convient for the installation and testing procedure. If -B is omitted, Onioncat will fork to the background and the log messages are written to the syslog.

Side note: Option -H enables hostname lookup which is required for the HSv3 lookup in a hosts file. Option -g /etc/tor/hosts.oc sets the path for the hosts file to be used. If this option is omitted, Onioncat will do the lookup in the system hosts file (/etc/hosts). Option -U disables the unidirectional mode. Although this is not necessary in this setup, with this option the time of connection setup is reduced.

Test the Setup

To test the setup open a new shell on one of your systems. You should be able to ping each of the three hosts with the ping6 command:

$ ping6 fd87:d87e:eb43:d1bf:d1c6:8553:559a:fe03
 PING fd87:d87e:eb43:d1bf:d1c6:8553:559a:fe03(fd87:d87e:eb43:d1bf:d1c6:8553:559a:fe03) 56 data bytes
 64 bytes from fd87:d87e:eb43:d1bf:d1c6:8553:559a:fe03: icmp_seq=2 ttl=64 time=315 ms
 64 bytes from fd87:d87e:eb43:d1bf:d1c6:8553:559a:fe03: icmp_seq=3 ttl=64 time=350 ms
 64 bytes from fd87:d87e:eb43:d1bf:d1c6:8553:559a:fe03: icmp_seq=4 ttl=64 time=313 ms
 ^C
 --- fd87:d87e:eb43:d1bf:d1c6:8553:559a:fe03 ping statistics ---
 5 packets transmitted, 3 received, 40% packet loss, time 4035ms
 rtt min/avg/max/mdev = 313.864/326.645/350.502/16.890 ms

$ ping6 fd87:d87e:eb43:6862:da73:63ad:fa91:f203
 PING fd87:d87e:eb43:6862:da73:63ad:fa91:f203(fd87:d87e:eb43:6862:da73:63ad:fa91:f203) 56 data bytes
 64 bytes from fd87:d87e:eb43:6862:da73:63ad:fa91:f203: icmp_seq=3 ttl=64 time=570 ms
 64 bytes from fd87:d87e:eb43:6862:da73:63ad:fa91:f203: icmp_seq=4 ttl=64 time=593 ms
 64 bytes from fd87:d87e:eb43:6862:da73:63ad:fa91:f203: icmp_seq=5 ttl=64 time=618 ms
 64 bytes from fd87:d87e:eb43:6862:da73:63ad:fa91:f203: icmp_seq=6 ttl=64 time=539 ms
 ^C
 --- fd87:d87e:eb43:6862:da73:63ad:fa91:f203 ping statistics ---
7 packets transmitted, 4 received, 42% packet loss, time 6041ms
 rtt min/avg/max/mdev = 539.112/580.280/618.032/29.220 ms

Please note that the first few pings may be lost because of the time Tor needs to create the circuit through the Tor network. Once the connection is open there should be no dataloss. The connections are close be Onioncat after two minutes of inactivity.

Continue reading]]> It was almost exactly 10 years ago that we started to run our OnionCat SVN repository for managing the source code.

As of today, the 9th of January 2018, the OnionCat source repository has moved to Github at https://github.com/rahra/onioncat.

This also solves the mailing list problem. To be honest, the mailing list never really worked reliably, just occasionally. All issues can now be discussed directly on Github within the issue tracker.

Continue reading]]> You operate your own server running some web services, a mail submission service, an IMAP service, of course ssh for maintenance and several other services? But unfortunately you cannot reach any ports except 80 and 443 as soon as you are somewhere in a public Wifi because of firewall restrictions? Then OnionCat is your friend

This article explains how to evade a firewall to access your own services in the Internet.

Public Wifis typically have at least port 80 and 443 open otherwise they would be useless. And this is actually a requirement for this setup.

Kmail Sample Config.

Let’s assume that you run your own server (my.server.org) somewhere in the Internet running IMAP on tcp port 143 and a mail submission service on tcp port 587. On your notebook you have your favorite email client which is already configured to access these services directly (on my.server.org).

Now you are somewhere connected to a public Wifi but unfortunately you neither can check nor send mails because 143 and 587 are closed.

The Setup

On your server (my.server.org) setup Tor and OnionCat as well as on your notebook. As a result your server¹ has an OnionCat IPv6 address on the tunnel device. The address is something like fd87:d87e:eb43:1234:5678:9abc:def0:1234.

You are now already able to access your server from your client, e.g. with ssh.

winnie:~% ssh fd87:d87e:eb43:xxxx:xxxx:xxxx:xxxx:xxxx
X11 forwarding request failed on channel 0
Last login: Tue Dec 15 09:12:05 2015 from forzand
FreeBSD 10.1-RELEASE-p   (GENERIC) #0: Mon Nov  2 12:17:28 UTC 2015

Welcome to FreeBSD!

psara:~%

Now make an entry into your /etc/hosts file as shown below. With this you don’t have to reconfigure your email client (and other clients accessing your server at its hostname). The system automatically looks up the hostname within the hosts file before it makes a DNS lookup.

fd87:d87e:eb43:1234:5678:9abc:def0:1234 my.server.org

That’s all. It will be a little bit slower as usual but nevertheless you can access your services

Continue reading]]> This article is about how to compile and run OnionCat on Android. Unfortunately, there is no Android app which simply enables it, due to the lack of programming power.¹ But if you are familiar with compiling projects and using ADB and the command line, this should be no big deal for you. Here’s how it works!

Root Your Phone

A requirement is that you Android smartphone is rooted since OnionCat accesses the tunnel device and configures an IPv6 address. Please do not ask how to root your phone! Please have a look at xdadevelopers instead.

Install Android NDK

You have to install the Android NDK. Go to developer.android.com/ndk and download and install it according to the instructions found on this page. Please do not forget to set the environment variable ANDROID_NDK properly. The best place to do this is .bashrc or .zshrc (or whatever shell you use). In my case this is

ANDROID_NDK=/home/eagle/android/android-ndk-r9d

Download OnionCat

Download the latest OnionCat package from www.cypherpunk.at/ocat/download/Source/current, extract the package and cd into it.

$ tar xfz onioncat-0.2.2.r569.tar.gz
$ cd onioncat-0.2.2.r569

Download the android_configure shell script into the previously extracted build directory of OC. This is a simple script which sets up the environment for cross-compilation and finally runs OnionCat’s native configure script. Run the script with

$ sh android_configure

Now simply run make.

$ make

This will compile OnionCat and finally produce an ARM 32 bit binary. You’ll find the executable file in src/ocat. ARM may not be the right platform for your smartphone. You’ll find the type of CPU in Settings->About Phone->CPU. If it is different you have to adjust the android_configure script accordingly (enivronment variables ANDROID_PREFIX and SYSROOT).

Copy OnionCat to Your Phone

Copy the executable to your Android phone. A good place for it is e.g. /system/bin. Make sure that it is executable. The best way to do the following tasks is either on the adb shell or directly within a terminal on your smartphone (or tablet). ADB (the Android Debug Bridge) is part of the Android SDK. Most Linux distros also have a package for it. I assume that you copied the ocat executable to your sdcard. Now run the adb shell, copy the file, and make it executable.

$ adb shell
shell@kumquat:/ $ su
root@kumquat:/ # cp /sdcard/ocat /system/bin
root@kumquat:/ # cd /system/bin
root@kumquat:/system/bin # chmod 755 ocat
root@kumquat:/system/bin #

 Finally test if the OnionCat executable is fine by simply starting it without any options. It should output a short help message.

root@kumquat:/system/bin # ocat
onioncat 0.2.2.r571 (c) Bernhard R. Fischer (OnionCat mode)
usage: ocat [OPTIONS]
-a create connect log at "$HOME/.ocat/ocat_connect_log" (default = 0)
-b daemonize (default = 1)
-B do not daemonize (default = 0)
-h display usage message
[...]

Install Orbot

Now install Orbot from F-Droid or GooglePlay and start the app. Go into the Settings and enable Hidden Service Hosting and choose 8060 to be the Hidden Service Port. Finally close the app and restart it. Connect Orbot to the Tor network by long-pressing the push button in the middle of the app. It will first turn yellow and then green if it’s ready.

Orbot will create the hidden service which is necessary for OnionCat. You can find the Onion Hostname (Onion ID) either in the Orbot Settings under Onion Hostname or on the command line in the appropriate data directory:

root@kumquat:/ # cd /data/data/org.torproject.android/app_data/hs8060
root@kumquat:/data/data/org.torproject.android/app_data/hs8060 # cat hostname
xxxxxxxxxxxxxxxx.onion
root@kumquat:/data/data/org.torproject.android/app_data/hs8060 #

This is your unique Onion Hostname of your Android phone. You are now ready to start OnionCat.

Run OnionCat

Make sure that there is a device node for the tunnel interfaces under /dev/tun.

root@kumquat:/ # ls -l /dev/tun
ls: /dev/tun: No such file or directory
1|root@kumquat:/ #

If this fails as show above you have to insert tun kernel module.

root@kumquat:/ # modprobe tun
root@kumquat:/ # ls -l /dev/tun
crw-rw—-    1 system       vpn            10, 200 Sep  5 21:16 /dev/tun
root@kumquat:/ #

Now you are ready to run OnionCat with the following command. Of course, you have to insert your correct Onion Hostname.

root@kumquat:/ # ocat -T /dev/tun -r -B xxxxxxxxxxxxxxxx.onion
Sat, 05 Sep 2015 21:17:26.358 +0200 [0:main      :  info] onioncat 0.2.2.r571 (c) Bernhard R. Fischer (OnionCat mode)
Sat, 05 Sep 2015 21:17:26.380 +0200 [0:main      :  info] IPv6 address fd87:d87e:eb43:xxxx:xxxx:xxxx:xxxx:xxxx
Sat, 05 Sep 2015 21:17:26.380 +0200 [0:main      :  info] TUN/TAP device tun0
Sat, 05 Sep 2015 21:17:26.381 +0200 [0:main      :  info] starting packet forwarder

Now test it. The best way is to ping6 some other OnionCat host of which you know that it is up.

root@kumquat:/ # ping6 fd87:d87e:eb43:744:208d:5408:63a4:ac4f
PING fd87:d87e:eb43:744:208d:5408:63a4:ac4f(fd87:d87e:eb43:744:208d:5408:63a4:ac4f) 56 data bytes
64 bytes from fd87:d87e:eb43:744:208d:5408:63a4:ac4f: icmp_seq=5 ttl=64 time=387 ms
64 bytes from fd87:d87e:eb43:744:208d:5408:63a4:ac4f: icmp_seq=6 ttl=64 time=275 ms
64 bytes from fd87:d87e:eb43:744:208d:5408:63a4:ac4f: icmp_seq=7 ttl=64 time=253 ms
64 bytes from fd87:d87e:eb43:744:208d:5408:63a4:ac4f: icmp_seq=8 ttl=64 time=250 ms
64 bytes from fd87:d87e:eb43:744:208d:5408:63a4:ac4f: icmp_seq=9 ttl=64 time=269 ms

If this works you are ready to use the OnionCat VPN. All OnionCat destination addresses will automatically be routed through your OnionCat and OrBot respectively.

Have phun and don’t hesitate to contact me!