Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tor stream isolation #731

Closed
JeremyRand opened this issue Jan 23, 2017 · 22 comments · Fixed by #2081
Closed

Tor stream isolation #731

JeremyRand opened this issue Jan 23, 2017 · 22 comments · Fixed by #2081
Assignees
@freimair

Comments

@JeremyRand
Copy link

As far as I can tell, Bitsquare is not using the stream isolation feature of Tor. Stream isolation separates different identities' TCP connections into separate Tor circuits, which makes it more difficult for wiretappers to correlate identities. It would be great to see Bitsquare implement support for stream isolation to improve privacy.

For some context, please see the IRC conversation from today. The brief upshot is that to implement stream isolation, Bitsquare would need to supply a SOCKS5 username/password that uniquely corresponds to each identity that should stay separated to maintain privacy. For example, maybe the SOCKS5 username/password could correspond to a given trade order. (But please do read the IRC conversation for the full context.)

Cheers.
@ManfredKarrer
Copy link
Member

Thanks for the input!
FYI: @dan-da, @JesusMcCloud

@dan-da
Copy link
Contributor

dan-da commented Jan 23, 2017

good stuff. not sure of priority or how best to implement/separate.

bitcoinj could be modified to use a separate proxy per peer connection, similar to bitcoin-core.

I'm not yet familiar with bitsquare p2p stuff, so dunno what makes most sense there.

will discuss with @ManfredKarrer when he has time.

@dan-da
Copy link
Contributor

dan-da commented Jan 23, 2017

related: I was thinking about maybe adding a "tor only" mode to bitcoinj, so it would only connect to .onion bitcoin peers. It seems like that would help with one of the vectors, for users that choose it.

@JesusMcCloud
Copy link

Hi guys!
I have rewritten the Java-Tor-bindings to try and support pluggable transports and I'm currently in the process of integrating the new code into Bitsquare.
I think stream isolation can be handled fairly transparently. The Apache HTTPClient hack might require some extra fiddling, but I'm sure it can be done as well.
My strategy would be to open new local proxy ports on-demand and use authentication as discussed on IRC.
Ideally, we'll just have to keep track of all the ports and the proxies associated with each port.
I'll report back as soon as i have something for you to test.

@JeremyRand
Copy link
Author

JeremyRand commented Jan 27, 2017 via email

@JesusMcCloud
Copy link

Thanks for the clarification! I actually was not 100% sure.
This way it's even easier to implement. I'll try and have something ready to test in the days to come.

@ManfredKarrer
Copy link
Member

I think it might make sense for the direct messages (take offer, trade, dispute) but not for the broadcast messages (relaying messages in the floodfill network).
A drawback might be that when you are already connected to a peer you would setup a new circuit, which takes sometimes quite a bit of time.
The Trade ID could be used for user/pw.

@JesusMcCloud
Copy link

JesusMcCloud commented Jan 30, 2017 •
edited
Loading

I've pushed my changed into a bitsquare fork integrating the new network layer including stream isolation support. None of this is tested, though, as I simply don't have the time at the moment.

EDIT: Just to clarify: This introduces support, but does not utilise the feature, since I don't know exactly when to enable stream isolation in bitsquare.

@ManfredKarrer
Copy link
Member

@JesusMcCloud Great thanks! I will not have soon time to look at it but will do definitely after our next release!

@JeremyRand
Copy link
Author

JeremyRand commented Feb 6, 2017 via email

@JeremyRand JeremyRand mentioned this issue Feb 6, 2017
Open
@JesusMcCloud
Copy link

Hi Jeremy,

thanks for skimming through the code!
I don't see how the usage of MD5 could be an issue here, but maybe I made some wrong assumptions.
The only reason for using a hash was the fact that it produces a fixed-length output. Proxy auth only allows for a fixed number of characters, and since I have no Idea how Tor behaves, if more than 255 characters are used, I went with a hash.
2¹²⁸ possible streams seemed enough for me, even though this is many orders of magnitude less than all possible valid SOCKS5 auth strings. I never gave collision resistance a thought, since I am having a hard time imagining a scenario where this could be a problem. I didn't even care to have a one-way function in there. My only concern was to have a function in there which takes inputs of arbitrary lengths and produced a (sufficiently long) fixed-length output—I would probable even be fine with some one-way function which is reversible up to 255 characters.
On the other hand, MD5 always looks bad at first sight, so it should probably be avoided in any case.

@JeremyRand
Copy link
Author

JeremyRand commented Feb 7, 2017 via email

@JeremyRand
Copy link
Author

JeremyRand commented Apr 3, 2017 via email

@ManfredKarrer
Copy link
Member

Not from my side. Tor improvements are postponed for a later release as atm the DAO has highest priority for me.

@JeremyRand
Copy link
Author

JeremyRand commented Apr 5, 2017 via email

@JesusMcCloud
Copy link

The main reason for going with jsocks was the simple fact that it flawlessly supported remote DNS lookups.

@JesusMcCloud
Copy link

#971 takes care of the tor-related aspects of this issue.
What remains open, is to feed some connection-specific information (maybe, the destination hidden serviceID?) to Tor. This, however, should just require a single line of code to change.

@JesusMcCloud JesusMcCloud mentioned this issue Nov 5, 2017
Closed
@mrosseel
Copy link
Member

mrosseel commented Nov 5, 2017

At the moment, on every startup a new random UUID is generated as streamId and passed to the new netlayer library (see #971).
If this is sufficient this issue can be closed, otherwise please suggest how to improve this behaviour.

@JesusMcCloud
Copy link

Looking over the IRC logs linked in this issue, the way to go would be to use unique Stream IDs as follows:

if you're making 2 different buy orders, isolate those 2 orders' connections from each other

Using a shared stream ID for all TorSocketss does not help in this context. Unfortunately, I currently don't have the time to think this through.

@ManfredKarrer
Copy link
Member

That would require another API where we can pass the stream ID at each new connection attempt. Better even would be that the library just takes a boolean flag indicating that random stream ID should be used for that connection and the library creates the random id.

@ManfredKarrer
Copy link
Member

ManfredKarrer commented Nov 5, 2017 •
edited
Loading

@JeremyRand: We have @JesusMcCloud 's netlayer library integrated in our develoment branch. In the settings/network there a new "tor network settings" button which opens a popup similar to Tor browsers settings. We use the same default bridges as those are shipped in Tor browser, but of course people can use their custom. If you have time to have a look and help testing would be great. There are still advanced features missing but that's for another release. The most important that pluggable transports are working is achieved.

@JeremyRand
Copy link
Author

There's an unfinished draft on the Tor wiki (which is mostly written by Patrick from Whonix) of best practices for Tor-friendly applications. Grep it for "Set a socks user name for stream isolation" to see some useful notes. In particular, that wiki page recommends using SOCKS authentication info that includes both an identity-specific string (e.g. different for 2 different Bisq buy orders) and a string that is randomly generated when the application starts (which isolates multiple instances of the same application, and makes sure that restarting the application will result in new Tor circuits).

Usually it's not recommended to use a unique SOCKS authentication string per TCP connection (unless they genuinely correspond to different identities), because doing so puts too much load on the Tor network.

@freimair freimair mentioned this issue Nov 28, 2018
Closed
@freimair freimair mentioned this issue Dec 6, 2018
Merged
@freimair freimair mentioned this issue Dec 28, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@freimair freimair

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Stream isolation for Tor freimair/bisq
6 participants
@JeremyRand @freimair @ManfredKarrer @mrosseel @dan-da @JesusMcCloud