Why I won’t be implementing Tor detection code in LibOnionRoute

Some days ago I was discussing some things with someone (name omitted on purpose) and came again to the subject of making software access a running Tor automatically before attempting to use LibOnionRoute. I haven’t paid too much attention to this subject as is not something of high priority to me, but I think is worth considering given the push. This is something that appeared before at tor-dev discussion list. Anyways thinking about it I came to some conclusions that weren’t quite clear to me until now.

I won’t be making something to let software connect automatically to a running Tor. Why? Security. Let me elaborate on that. When we talk about anonymity software we talk about pretty sensitive code on security. And… There is nothing that Tor can do for an application who wants to access the Internet anonymously that LibOnionRoute can’t, and if it is the case then LibOnionroute should be enhanced/fixed. Think about the previous statement twice.

Ok let’s see the scenario with an example. Let’s suppose you want to make your browser (use your favorite software here, irc, chat..) access the Internet using the network of routers. It goes tries to find a running Tor or launches the process… easier said than done. Well it finds out something listening at port 1080. The browser is not sure it is Tor or a plain socks proxy listening at localhost or just that little worm who sneaked into the computer. Nobody ever needed administrative rights to open a listening port there…

We have a problem here. Now how can you know you are anonymous? Can the browser know? Maybe accessing a hidden service and verify is reachable? Or several for that matters. That trick could save the day to some extent. You can never be sure a little trojanized Tor was listening executed by another user with non administrative rights. We don’t even have to go that far. Just a bouncer that dumps the traffic it relays between a normal Tor configured to listen in another port and voilà. The attack would take seconds for someone with bare computers knowledge. You could download such thing from the internet in seconds and architect the attack.

This Tor detection could be developed more. I could find a Tor installation somehow and verify it. Maybe get the process, look for the binary name and check some detached digital signature out of the binary (if readable) to verify it is some Tor release. Again this is easier said than done. Is also hardly platform independent. Who would be in charge of signing Tor binaries? Me? That looks more like a Tor project duty. They don’t seem too interested into a library so this is likely a no go.

And then after that check what if an attacker terminates the running Tor and later launches the trojanized version? We would have to do the check anytime the connection is dropped. I don’t know maybe could be done securely but looks like too much of a hassle.

Now if Tor is not installed the application just goes ahead, loads a dynamic library and connects. Now it is sure. After all, normally only someone with administrative privileges can install a system wide library. If the computer was penetrated then you will never be safe no matter what. See the point? Why spend the trouble of locating a running Tor in the first place? Configure the firewall to let it listen at localhost or some other interface? Step through all configuration files. Isn’t that too much trouble to get.. The very same?

Updatability? Today many things can be updated, even the computer BIOS and the CPU microcode! Why a library not protected by the OS would be a problem? Maybe an auto-updater could be developed/used. It could download updates using the network of routers to avoid leaking library usage. LibOnionRoute could be reused here to download the new copy ;) . Maybe verifying a digital signature to make sure people doesn’t gets trojanized updates even in the case the download source is penetrated.

There is still another reason not discussed here? Sure, why not? is a diverse world and it could be the case. Maybe the library is not up to date with some security fix or something else. In such case the application could be configured manually to use a running Tor.

What I think an application should do however is to try to load a system wide library and if it’s version is higher than a local copy then try to use it instead. If not possible then use the local copy. An API call to easily verify version as in openssl or libevent could come handy.

In any case I don’t mean Tor as it is, is something not useful. I don’t want to be misinterpreted and I am not looking to proof that. I use plain Tor all the time. I run routers and I publish hidden services with Tor as well. I don’t think people are going to stop using Tor at all, as the library just fills a completely different niche. There is also lots of software that doesn’t links today with the library and there is no other way to use it anonymously except with Tor or analogous software. That can vary in the future to some extent but I don’t expect all the software accessing the Internet to link with LibOnionRoute. That is something Tor can do. Besides is the reference implementation.

If anybody reading this post diverges, please feel free to comment with arguments. I would like to consider different points of view.

PD: This article was published long ago it was stored in a backup copy.

We are back online

Sorry for the off-line time folks. There was a problem at our hosting company. We commanded to close one server and they destroyed the wrong one containing several websites. There were no fresh backups. Fortunately most of the data was stored locally. Over time we’ll be posting everything back on-line. However your previous comments are gone. Now this website is hosted at sourceforge.net to ensure better handling. Our hosting company services have turned really bad over time. Is not the same as one year ago so we are going to rent servers in another company in the future. They even place outdated software that reached EOL long ago at the virtual CD drive! No wonder when the problem happened they took me to escalations department right away. There was no escalation, only mishandling from their side. Sourceforge limitations are high so maybe the website gets moved once again if it turns to be harder to maintain here. LibOnionRoute development has not ceased at all. There are lots of new bugfixes coming from Tor repositories and some comming from me. The library is more tested now. I left it work for several days trafficking data including connection loss. It runs very stable now and properly delivers commands in order from multi-threaded software. I will be publishing also sort of wget clone running over Tor network. Very limited in features but handy to quickly download content from .onion pseudodomains (websites hosted as Hidden Services). Hope you enjoy and provide enhancements to support more parts of the HTTP protocol in the future like redirections, gzip, deflate, SSL/TLS, chunked transfer… Hopefully it will make .onion publishing more popular. Specially due recent Snowden events and all the espionage and privacy invasion being done on the Internet. I suspect USA is not the only country doing that. Another new is that now I have a faster Internet connection over 3G running 24 hours (earlier was over sloooow modem) so that means I can backup website content easier. I also will be publishing content to GiT and GitHub. A developer from Tor is going to provide me a hand in that area. It doesn’t means we are endorsed or promoted by Tor however. I am also looking for help form the Unix side. If you know about C, Unix library development and want to cooperate please let me know.