Opened 6 years ago

Last modified 7 months ago

#5553 new task

prevent protocol leaks; Tor client connection API or protocol review howto

Reported by: proper Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client documentation developer
Cc: Actual Points:
Parent ID: Points: 5
Reviewer: Sponsor:

Description

I am unhappy with the current Torify instructions.

The big bittorrent leak may happen to any application, which has not been explicitly designed for Tor or reviewed by someone. That's why safe use of Tor is at the moment somewhat limited to the few applications designed over Tor (Tor Browser) or reviewed for use over Tor.

Two ideas will follow how to solve this problem. One or another may work as solution. Feel free to propose other/better/easier/faster solutions.

Proposal 1:
Write a howto, how to review an application and protocol for leak free use over Tor. "The protocol/application has to be reviewed." - That is much to vague, even for the application's developer.

For example, would the xchat developers answer "xchat over Tor: do not use dcc/ctcp... it leaks your IP/timezone..."?

What we easily could do for many applications, would be asking the application's developers. But even them could be confused by the question. The paper should define, what a protocol leak is, how to look out for them, how to prevent them.

This would hopefully enable the application developers to answer to the question regarding the protocol leak status. And if they don't want to review their own application, third party contributors could review the protocol.

Proposal 2:
Provide an alternate interface for applications. An alternative to socks. Either an API or libery for developers. i2p does also provide one and loads of applications are build on top of i2p. Why there are not so many applications designed for Tor? Because there is neither an API nor an libery.

Child Tickets

Change History (8)

comment:1 Changed 6 years ago by nickm

Better instructions for how to secure applications for use with Tor would be neat. I think there are some ubuntu folks interesting in writing them.

What functionality should a "libery" provide that SOCKS does not?

comment:2 Changed 6 years ago by proper

I overworked the TorifyHOWTO, added the appropriate warnings and restructured everything, to make the article look more friendly and inviting. To make it more easy for contributors to do the protocol reviews. But there I am stuck and it looks like anyone else as well. No one dares to add anything and to say "this application has been reviewed/tested by me, configured this way, it's safe for use over Tor". - This is why the API / library came to my mind. i2p does not have these kind of leak problems, as the community has been made able, to develop applications on top of the network.

Replying to nickm:

Better instructions for how to secure applications for use with Tor would be neat. I think there are some ubuntu folks interesting in writing them.

Can you provide reference please?

What functionality should a "libery" provide that SOCKS does not?

The programming library should provide all network connectivity functions. I don't know which functions socks provides and if there are any limitations compared to direct connections. It would ensure, that applications "designed for Tor" are explicitly compiled using that library and ensure not establishing any non-Tor connections. Using socks wasn't very reliable in the past. Way too many leaks appeared. Maybe the library idea isn't he most wise idea someone ever had.

Perhaps it's related to You should transport all IP packets, not just TCP packets. "it looks like our best bet is shipping our own user-space TCP stack". #1855

comment:3 Changed 6 years ago by proper

Here are some hints, how difficult it is, to review an application.
https://lists.torproject.org/pipermail/tor-talk/2012-April/024016.html

After digging this topic a lot, I don't think that someone ever reviewed an application so thoroughly, beside Tor Browser and Pidgin.

comment:4 in reply to:  3 Changed 6 years ago by unknown

Replying to proper:

Here are some hints, how difficult it is, to review an application.
https://lists.torproject.org/pipermail/tor-talk/2012-April/024016.html

After digging this topic a lot, I don't think that someone ever reviewed an application so thoroughly, beside Tor Browser and Pidgin.

Hiding IP and preventing visible leakages (such as DNS requests or useragent name) is not enough for successful torifycation. For example, if someone trying to torify download manager (such as wget), then smart adversary can reduce anonimity set with statistic profiling any non-TBB downloaders on the servers side or through intercepting exit node traffic. Wget'll get a different responce than standart TBB or another downloaders to cookies and active elements injection, fonts manipulation on a page, resume downloading, pipelining behaviour, etc. Different applications and different settings brings to different anonimity sets. We need a some bundle with unified set of a popular applications or warning to use manual torifying with limitation (for instance, connecting to trusted personal hidden services only).

comment:5 Changed 5 years ago by nickm

Milestone: Tor: unspecified

comment:6 Changed 5 years ago by nickm

Keywords: tor-client added

comment:7 Changed 5 years ago by nickm

Component: Tor ClientTor

comment:8 Changed 7 months ago by nickm

Keywords: documentation developer added
Points: 5
Severity: Normal
Note: See TracTickets for help on using tickets.