Bisq: Bounty: Investigate solution how to solve blocked Tor connection in China

Created on 11 Jun 2016  Â·  116Comments  Â·  Source: bisq-network/bisq

Bitsquare cannot be used inside China mainland because Tor is blocked by the (not so) great Firewall.

We want to set up a bounty for finding the best technical solution to overcome that problem.
It might be possible to solve by using a VPN, though it would still be a big hurdle for many users (https://forum.bitsquare.io/t/using-bitsquare-in-mainland-china). If we find a way to integrate a VPN inside Bitsquare so the user has no setup costs, that might be an interesting approach.
If VPN does not solve that issue, Tor Bridges or Tors pluggable transports might be solutions.
Please note that we use Tor Hidden Services, so Bitsquare Tor traffic is never leaving the Tor network to the clearnet (via exit nodes), so it is a different use case as usual.

$BSQ bounty network privacy security

Most helpful comment

New to Bisq by way of Dash. I'm based in Mainland China with software testing experience, willing to help testing new builds to get Bisq working in China. I agree that domain fronting using the meek pluggable transport is the most promising approach here.

All 116 comments

I add 1 BTC to this bounty. I was in fact considering this bounty myself but you beat me to it. VPN might not be necessary if Bitsquare is hosted outside China. Tor Bridges or Tor pluggable transport will most likely not work. I tried all these things without success in Wuhan. VPN is throttled back by the Chinese authorities as well.

Got first input from a friend that it should work by extending the config file with Bridges. If that does not work then pluggable Transports should work but that needs inclusion of extra binaries.

@ManfredKarrer I have been in the process of testing modifications of the torr config as well as testing over hyperboria for most of the day. What is required to take this bounty?

@agardener: A solution which works for mainland China. We need some testers there to verify that it works.

If someone in China wants to test bridges in Bitsquare you can use these steps:

  • run Bitsquare (Bitsquare should be running during this entire process)
  • Goto https://bridges.torproject.org and get some fresh bridges
  • choose 'none' on pluggable transports option (for now)
  • open ~/.local/share/Bitsquare/mainnet/tor/torrc in a text edditor and add the bridges that you got from bridges.torproject.org at the bottom of the file, it should look something like:

AvoidDiskWrites 1
ControlPort auto
CookieAuthentication 1
CookieAuthFile /home/bob/.local/share/Bitsquare/mainnet/tor/.tor/control_auth_cookie
DataDirectory /home/bob/.local/share/Bitsquare/mainnet/tor
GeoIPFile geoip
GeoIPv6File geoip6
HiddenServiceDir /home/bob/.local/share/Bitsquare/mainnet/tor/hiddenservice
HiddenServicePort 9999 127.0.0.1:57169
PidFile pid
RunAsDaemon 1
SafeSocks 1
SocksPort auto

UseBridges 1
bridge 63.142.157.162:9001 9C27FABC13D868F94F7377D17C22998683AFCCAD
bridge 107.23.146.44:8443 08D75007901C33900733E2D0CF51B6F196DA2824
bridge 185.22.52.223:443 BA3AACD41D8F7EE69350CC3769BC0C9730049AEB

  • Now we need to restart tor, find the PID by running something like ps -aux|grep torrc or top. You will see a line that looks like (the PID below is 1361):

bob 1361 2.0 3.7 20384 19016 ? S Jun11 0:35 /home/bob/.local/share/Bitsquare/mainnet/tor/tor -f /home/bob/.local/share/Bitsquare/mainnet/tor/torrc __OwningControllerProcess 1319

  • Now we send the SIGHUP signal to Tor in order to reload the config

kill -SIGHUP 1361

  • In order to see if a connection has been made run netstat using one of your bridge IPs

netstat -an|grep 63.142.157.162

  • or view all of your tcp connections

netstat -an|grep tcp

  • Check status of BitSquare window

This is a quick way to get up and testing Bitsquare with bridges, I am happy to provide more support to any users willing to test. Also if we discover that basic bridges do not function I can provide additional configuration information for pluggable transports, but as ManfredKarrer pointed out it will be as simple as including additional binaries. It is not currently state aware as it appears tor is creating a new config every time Bitsquare restarts - I believe this could be fixed by creating a patch that reads torrc and runs controlConnection.setConf.

I can also help build/document other layers(like cjdns or vpn) if needed however if bridges and transports are not working in China any longer I suspect most public(free) networks will also be caught in the same web.

@agardener Thanks a lot!

I think I will do the following to make it as easy for users as possible:
Bitsquare starts up. If Tor connection does not work a screen gets displayed to ask user if he wants to use Bridges. Unfortunately the Brigdes webpage use terrible captchas, maybe i find a way to provide the user directly current addresses, otherwise the user has to do that manually.
After the Bridge addresses are added, Bitsquare restarts and use those addresses in the torrc at the next start. Alternatively a internal restart of tor might be even better.
Do you have an idea how to get the bridge addresses automatically (avodi user to enter captcha and go to webpage but load them form bitsquare)? Probably not possible as it is designed to avoid that, so they cannot get blocked easily....

@agardener Do you have any technical contact inside China who might be available for testing it?

@ManfredKarrer oakpacific?

No problem! Open communications ftw!

@ManfredKarrer I think you have the right idea with allowing the user to set their bridges or alternative connection methods at startup. Socks5 proxies might be another helpful option for example (a user may wish to hide their tor traffic) - this is also defined in the torrc.

Do you have an idea how to get the bridge addresses automatically (avoid user to enter captcha and go to webpage but load them form Bitsquare)? Probably not possible as it is designed to avoid that, so they cannot get blocked easily....

Its intentionally designed to not be easily scraped. I also think collecting a list of bridges and hardcoding them would be counter productive, unless perhaps they were private bridges run by the Bitsquare team as a regular bridge might be stable today but 6 months down the road some of the users could be left in the dark . Having a solution where the user sets their own bridges and transports may provide more stability/decentralization.

I don't know anyone off hand. If no one can test I can try and see if there is a VPS available... not sure how easy that is to find though I have seen availability in hong-kong.

@agardener To run our own bridges might be an interesting option indeed. I could ping them and if they are reachable will use those, otherwise ask the user. I want to make it as easy as possible for users (they are lazy...). Users who want/are willing to run their own bridges are even better, but I assume not many will do that, though I could offer that option as well (plan that also for a private full bitcoin node to connect to instead of seednodes).
I am not sure how quickly I can work on that, have a long list of other stuff, but hope the next 1-2 weeks.

Would you be available to help to set up a bridge?

Having been in China and seen the efficiency of blocking tor also when bridges and pluggable transport is used I have my doubts that any method involving tor inside China will work. Hong Kong is very different and I guess tor is allowed there. A few years ago bridges were supplied to trusted people in China by e-mail who then distributed the adresses. Hopefully tor has been able to solve these issues lately, but China has more than 30 000 people employed to harden their Firewall so it will not be easy. I can mention that I did manage to get Bitsquare to start and find seed nodes over VPN, very very slowly, when I was in Wuhan this March so Chinas deep packet inspection is not perfect. I never got it to run fully though. I don't want to be negative here and I think you should try since this issue is so important. It will be necessary to have a skilled tester in the mainland.

@ManfredKarrer Definitely. I could write the server configuration into some basic anisble playbooks. Not now, but later this week

@meapistol What do you think about private bridges? Think they are likely stand more of a chance?

@agardener Maybe private bridges work. Maybe tor can run over "high quality" VPN. I used 12VPN. I also tried www.vpngate.net which is dedicated to China but their servers did not work at all. They did work a year ago though. Somebody from tor should be able to answer these questions. Unfortunately all my friends in China are not good at this so I cannot ask them. In fact most Chinese are satisfied with their local alternatives, Baidu, Wechat etc.

I think to use private bridges might be a good start. As long Bitsquare is not relevant in China we will probably be under the radar. Later we can improve. Multipe bridges and a more dynamic address allocation might be the next step. More input from Tor devs would be definitely helpful.

@meapistol I think before VPN I would suggest using something like the hyperboria network, setup with internal bridges to the Tor network. This mesh format creates more decentralization. But it maybe hard to integrate into Bitsquare.

@ManfredKarrer I think that relevancy is the biggest thing to note. If Bitsquare becomes 'noticed' I believe it will have to be just as agile as Tor in allowing users to set their connections.

@ManfredKarrer @meapistol I have been involved generally with Tor/mesh R+D and QA for around 10 years. While Im not a programmer per say I may be able to answer questions, or at least research an answer.

@agardener I was assuming you have deep background with Tor/networking stuff :-) Great to have you here!
I have no experience with hyperboria, but as you said that might be an extra challenge to integrate into Bitsquare. Usability (no setup effort for users) is a must-have for Bitsquare if there are any alternative solutions.
And yes I don't assume Bitsquare will get too soon into their radar, so we will have time. Also Bitsquare is not that directly political as other Tor usage, so even when they discover it they might tolerate it.

So my plan for the first version:
Setup a private bridge (maybe @ivilata can help here), use that hardcoded for torrc in case normal tor does not succeed.
Find someone in mainland China to test.
If that succeeds the bounty is fulfilled for the first goal.

Later we can improve.

@ManfredKarrer Thanks! I don't mind setting up and running a VPS for a bridge if the costs could be covered(I could share login credentials somewhere for someone to foot the bill). Alternatively if someone can provide ssh access I can start there. Something to note, as I have not done a ton of development in relation to the not-so-GFW it maybe true that it has a live black list. So if our initial bridges are noticed and blocked this may mean we need to move to a new IP before testing pluggable transports. I don't want to loose the bounty, but the sun is shining here and Im afraid most people are probably sleeping in china.

How can @ivilata help?

To answer HostFat's question obfs4 can be tested in much the same way as regular bridges.

I used the information located at the obsf4 github, I tested on debian 8

  • First install go for debian do

aptitude install golang

AFAIK everything else should not be debian specific

  • Now create the $GOPATH

export GOPATH=$HOME/go
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin

  • Then run the go get command to install obsf4, this also install the needed depends

go get git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy

  • After a minute the binary should be ready to use, copy obfs4proxy from ~/go/bin to /usr/local/bin

cp /home/bob/go/bin/obfs4proxy /usr/local/bin/.

  • After this the setup is much the same as normal bridges as posted above, your torrc should look something like (make sure to select obsf4 bridges on bridges.torproject.org):

AvoidDiskWrites 1
ControlPort auto
CookieAuthentication 1
CookieAuthFile /home/bob/.local/share/Bitsquare/mainnet/tor/.tor/control_auth_cookie
DataDirectory /home/bob/.local/share/Bitsquare/mainnet/tor
GeoIPFile geoip
GeoIPv6File geoip6
HiddenServiceDir /home/bob/.local/share/Bitsquare/mainnet/tor/hiddenservice
HiddenServicePort 9999 127.0.0.1:57169
PidFile pid
RunAsDaemon 1
SafeSocks 1
SocksPort auto

ClientTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
UseBridges 1

bridge obfs4 195.132.208.182:42679 69C... cert=pGG... iat-mode=0
bridge obfs4 195.132.208.105:43666 108E... cert=EXz8... iat-mode=0
bridge obfs4 212.218.216.127:10575 D2A.... cert=fVvl... iat-mode=0

  • Now we need to restart tor, find the PID by running something like ps -aux|grep torrc or top. You will see a line that looks like (the PID below is 1361):

bob 1361 2.0 3.7 20384 19016 ? S Jun11 0:35 /home/bob/.local/share/Bitsquare/mainnet/tor/tor -f /home/bob/.local/share/Bitsquare/mainnet/tor/torrc __OwningControllerProcess 1319

  • Now we send the SIGHUP signal to Tor in order to reload the config

kill -SIGHUP 1361

  • In order to see if a connection has been made run netstat using one of your bridge IPs

netstat -an|grep 195.132.208.182

  • or view all of your tcp connections

netstat -an|grep tcp

  • Check status of BitSquare window

@agardener Adding obfs4proxy would require that we add that binary, so that would be more effort. Lets start first with the easiest solution and see if we succeed.

I talked to @ivilata (the dev who joined to work on the Bitsquare network module, he is more experienced with sys admin and network stuff than me...) and he agreed to handle the bridge installation with you. I leave it up to you how to proceed. I assume the VPS costs are < 20 EUR for the period we need it for testing, so no worry I will cover that. After successful test I will run my own bridges (with @ivilata's help).

I need to get a few other things done first, but then I will try to build a version with bridge support. Hope in about 1 week I have that. I might start with some stable bridge addresses and later use our private bridge.

What are the system requirements for such a VPS? I assume they are very low (1GB ram). Do u have a recommendation for a hosting?

@ManfredKarrer OK, no problem.

Sounds good, I would suggest going with a host that provides per minute pricing and multiple regions, instead of getting a single VPS for the month. This way the account balance can be loaded up and if we want to switch hosting region or re-deploy for a new IP there wont be any issues. @ivilata let me know where to start.

OK, in app support will be cool.

Requirements are generally bound by RAM, which is tied to transfer/users/etc. For testing I think all of this usage will be really low and being a private bridge helps. I think we would be safe with starting in the low range(~512mb) working our way up or adding other nodes as required to do so.

I don't have a specific host in mind but there are a few hosts here that provide per minute hosting and with multiple regions: http://www.cryto.net/~joepie91/bitcoinvps.html .

Any testers in China yet?

@agardener Cool!
No I have no testers yet, but at least 2 or 3 contacts who I will ask as soon we have a binary ready for testing. I will release a new Bitsquare version soon and maybe I can directly add it to that version already.

@agardener Is it ok for you that you setup your own VPS and hand over the setup scripts/configuration after testing succeeded so @ivilata can install it on my VPS. If you want I can pay you in advance the estimated costs for VPS, lets say for 1 month.

@ManfredKarrer Sure.

You can use this address 19q8sKjicr4SKzB5FbK85HiqqJoRWvEUiS. What ever you send I will forward to the hosting services, I think it will cost about 0.0057 per hour.

Thats $0.0057USD not btc btw!

Do you have a OS preference other than debian?

What about transforming all Bitsquare instances into hidden tor-bridges as well?
We could make sure they wouldn't be registered at the torproject and wouldn't be blocked by GFW either. This would require some sort of bootstrap-list of nodes; which you probably have already anyway.

My only concern is that these bridges could be used to access other services as well, but you have the same issue when running a centralized bridge for Bitsquare

@SjonHortensius The only problem with this is the amount of setup involved. Tor relays and bridges require an exposed external port. If users can't run their own instance of Tor then how are they going to manage port forwarding on their router? It could be an option for power users, but I suspect they would choose to run a different binary for this process like you pointed out above.

Either way public bridges can be subject to this kind of abuse. Having them unlisted may help as well as being rate limited.

@agardener To setup a private bridge requires a couple of lines of configuration (BridgeRelay 1/ PublishServerDescriptor 0/ ExitPolicy reject), so it's not that hard. It does not require a different binary.
The NAT/open port is a valid problem, but you only need a couple of nodes (in theory you could even reimburse them with a small percentage of the trades) to make this work. Also, it doesn't stop the project from also running a few of these to to make sure you always have some online.

To have more bridges would be good but I fear that most users are not willing/able to deal with the NAT config. Though I could add a program arg where you specify your own torrc file for experts who want to run Bitsquare's Tor node as bridge.
But how to deliver the list of available bridges to the peers? Any out of band solution which works automatically, would get detected easily and blocked, and others would require users interaction, like multiple captchas. Would be cool to find a way to piggyback on a "too big to block" service and users in need can find that easily. Maybe we can tweet the bridge addresses on a chinese Twitter clone?
Maybe a good use case for Steganography? Cat and dog images carrying bridge addresses.

@ManfredKarrer is solving this necessary for the bounty? I thought you were going to hardcode into binary.

While china is not the top country, user count is relatively stable for the last few years
https://metrics.torproject.org/userstats-relay-country.html?start=2013-03-16&end=2016-06-14&country=cn&events=off

@agardener Yes for the bounty we only need to succeed that a chinese user (mainland) can user Bitsquare. A hardcoded bridge is sufficient for that. Was just thinking for future improvements...

So regarding the statistics it seem teh blockage is not too successful.

Maybe, if it doesn't connect to Tor, it can try to connect directly to this page:
https://bridges.torproject.org/bridges?transport=obfs4
And then (without even showing the page to the user), asking him to solve the captcha.
Then Bitsquare will grab automaticaly the bridges from the list, and will ask the user to restart the app.

If Bitsquare isn't able to connect to the page, then it can show a message where it asks to enter a list of bridges in a large editbox, and suggesting to the user to find a way to connect to the page or sending an email to [email protected]. (EDIT: the email gives an automatic answer with the list of bridges)

I am wondering if the https://bridges.torproject.org/bridges is accessible in China?

For anyone who can't reach that URL these bridges worked earlier today

ClientTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
UseBridges 1

bridge obfs4 194.132.209.182:42679 69CBC731FD77DC2200E3C1FC333018A0D078C446 cert=pGGWgWF3gbi2Wzlmuj33qcF5NkGMddgyY64vIR3ug2/Fxf26KlvIsgeaoWsXL4ReN+jmXQ iat-mode=0
bridge obfs4 194.132.209.105:43666 108E3F93A2E9A772D4EABF4DA88688D2066885AF cert=EXz8iDqbZbD6Xw1kHnbTN5vm61IkXiZrCL1FotLto/0ipObtD4dM03jq+v8oJJDEqJ6cLQ iat-mode=0
bridge obfs4 216.218.216.197:10575 D2A4BA27287EFDCBC80AA00B254C815E4607DA6F cert=fVvl+tPWVdpicYjUiyYnBWV27q9lgzvyRK9FiLwfQMIqY6e5Yl8oOqOC7pZ1nkdWxdy8aA iat-mode=0

ManfredKarrer commented 4 hours ago
I am wondering if the https://bridges.torproject.org/bridges is accessible in China?

need vpn

@wujinxing are you able to use bridges as described here?

Here is a set of fresh, regular bridges

bridge 63.142.157.162:9001 9C27FABC13D868F94F7377D17C22998683AFCCAD
bridge 107.23.146.44:8443 08D75007901C33900733E2D0CF51B6F196DA2824
bridge 185.22.52.223:443 BA3AACD41D8F7EE69350CC3769BC0C9730049AEB

@agardener
Sent 0.01 btc (tx 8f8eb2ee8439256b5babb88d96c3680c773f1f79d8c89dca7a4ce8cd3ef71579)
Re OS preference: Leave it up to you

@agardener Please don't c/p hidden bridge-ips here; you're ruining the torproject's efforts to keep them hidden from censors; and thus usable from China.

I'm not sure if anyone is working on this but I just started a POC hidden bridge (on OpenBSD) that will run for 1 month; @wujinxing can you test this bridge-config? It has only been running a couple of minutes so shouldn't be blocked yet.

bridge 37.97.198.227:443 A8EE038D5973A934E2E6C298C348FAA99823235E

If you add this to ~/.local/share/Bitsquare/mainnet/tor/torrc and killall -SIGHUP tor, bitsquare should be able to connect through this bridge

@SjonHortensius thanks for the input but I think you may of misunderstood bridges. Bridges are not hidden, they are simply guarded by a captcha. Unlike the main relay system which is kept together in huge lists passed out by the directory servers, bridges can be passed around by email, chat, whatever keeps them from gathering in huge lists ( huge lists are easier to block). TBH whether they are posted here or sent in a plain text email from the torproject they have just as much possibility of being gathered up and blacklisted by Chinese efforts.

Thanks for setting up a node, I imagine the more bridges to test with the better. Though upon testing your node I believe you have a configuration error, I was unable to establish a connection.

Here is a bridge for testing in Montreal, Canada, @wujinxing @HostFat

UseBridges 1
bridge 158.69.102.94:443 C2FA8AE17D5115B493CC694C0D9851FD4166B11D

I tested this earlier and everything appears to work as normal.

I also will setup an obfs4 bridge for testing based on comments on connect-ability. It seems to be an easy upgrade and adds a ton of protection.

Please try the regular bridge above first. Pluggable transports require additional efforts in maintaining dependencies so testing obfs4 should only be done if basic bridges do not work. Thanks!

If the above bridge configuration does not work please test with

ClientTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
UseBridges 1
bridge obfs4 51.254.227.32:54196 78296345F588B887B2DB5E19B1A7822371E251A7 cert=oUQpVflxYnzPj42WWRMc1swgP+YW4p0D+dy/wZ3rlLh0HtXHh4qalb8XRPePylFypkwxDA iat-mode=0

This bridge is running in france and was tested earlier

please follow this post if you need help installing obfs4proxy

@agardener I still did not had time to work on it, but my plan is to use a static bridge address and if that fails let the user enter any bridge address, so in best case the user dont need to do anything.

@agardener I implemented the bridge support. I just want to wait for another bugfix and then I provide binaries for chinese testers to see if it works.

I try first normal tor connection, if that fails, we use hard coded default bridge addresses, if that fails as well we show a popup where the user can add custom addresses. Those will be persisted and used in follow up startups.

Maybe you can add also advise to check at this link:
https://bridges.torproject.org/bridges?transport=obfs4

And also these instruction:

Another way to get bridges is to send an email to [email protected]. Please note that you must send the email using an address from one of the following email providers: Riseup, Gmail or Yahoo.

Many users don't now about them.

I added a link to https://bridges.torproject.org/bridges
But transports would require some extra effort (binaries). We want to try frist the easiest solution with bridges, if it does not work transports will be the next step.

I implemented support for Tor bridges and would need some chinese (mainland) testers who can help testing it. I want to release soon (weekend?) a new version and it would be great if we could test that feature first to see if it works.
If anyone is availabe please let me know which OS you have (osx, win 32, win 64, linux 32, linux 64) so I know which binary I need to build for the test.

Neither bitsquare.io nor nucleo.io seem to be accessible from the mainland.
We will check if it is possible to upload binaries to some chinese version of dropbox.

@meapistol that might be an issue; but shouldn't stop you right now; the binaries can be downloaded from github; check out https://github.com/bitsquare/bitsquare/releases

Yes. And the Chinese can open nucleo.io/downloads. He misspelled.

@meapistol just in case you try, the binaries necessary for the test are not available for download via the release page. Can you let us know what operating system you need binaries built for? @ManfredKarrer wants to do some test builds asap.

I am trying to find out which os he uses. It seems to be Windows though. The download speed is horribly slow there. We will try some other (upload) way.

It is now in China in two places, Wuhan and Beijing. Both managed to download from nucleo.io/downloads. Bitsquare stalls after some time and they use Windows 64 bit in Beijing, OS X (64-bit) in Wuhan. Maybe the versions on nucleo are not Tor-bridges ready?

@meapistol!!! Thanks so much for testing. I think you are correct, @ManfredKarrer needs to upload new binaries for you to test. Thanks for providing operating system info!

@meapistol
Yes the versions at http://www.nucleo.io/downloads/ had already Tor bridge support.
I just created new binaries for OSX and Win64 and uploaded it to https://bitsquare.io/download/dev-test/ (and removed the old files from nucleo.io).

Wondering if I should upload it to GH as pre-release versions, but fear other people will use those not well tested dev versions as well and then we get too much mess.
So please don't share/distribute the https://bitsquare.io/download/dev-test location, as I prefer to have only a few testers who will update quickly if required, otherwise it takes too much time for me to test before giving it to the public.

I don't see anything at: https://bitsquare.io/download/dev-test
I might need to put them somewhere else in case the Chinese cannot reach https://bitsquare.io

You are so fast :-) I made a mistake in my first upload, uploading the correct version atm. In 1 minute its there.
EDIT: Its uploaded now

The expected behaviour is following:
User tries to connect normally via Tor. If Tor is blocked it will fail, then it will try to use the hard coded bridge addresses. If that fails as well a popup will be displayed where he can enter custom bridge addresses. In the settings/network he can also activate/deactivate bridges and if activated add addresses.

If all works correctly I will improve a bit with better feedback and icons indicating the bridge connection.

Does not work so far in Wuhan, Yang will try later in his house with a different IProvider. Should he simply wait without clicking away the popup if the initial connection fails?

There is a startup timer popup after 4 minutes. Yes he can click that away and keep ti running to see if it needs more time. Need to increase the timeout if bridges are used.

Maybe he can send me the log files.
Location of the data directory:
Mac OSX: /Users/username/Library/Application Support/Bitsquare
Linux: /home/username/.local/share/Bitsquare
Windows XP: C:\Documents and Settings\usernameApplication Data\Bitsquare
Windows Vista or 7: %appdata%/Bitsquare

Something to think about if testing obfs4 or from another IP... I noticed you added a large selection of bridges to bitsquare I guess some of these must of been from bridges.torproject.org. I'm guessing that if the gfw saw a connections to many _known_ bridge addresses it might be smart and enable a block for the unknown private address automatically. Oh how I wish there was a node for me to test on in China.

Yes I wanted to use private only, but I don't have time to setup servers for that now and @ivilata is on holiday for 2 weeks. So I wanted to have just a quick test with public ones and if we see it works to use then a set of private ones. If they test fails I can make another version with your server if it is still running.
But anyway if the hard coded fails, then the user can add custom ones. We can pass over your address to the testers to use as well.

I never modified the bridges that I posted a week ago, AFAIK they should be running fine. There is enough balance in the account to run 3-4 bridges for a couple weeks if need be. I can regenerate IPs if there is worry that the current ones are blocked.

Yang Liu (Wuhan) will test at home soon and I think he will send logfiles to Manfred. Let us hope it works. For this testing I think Bitsquare should immediately try bridges unless it involves too much work.

I don't know if it is a big deal with Bitsquare, however in a high threat scenario hardcoding both the bridge nodes and onion nodes would probably allow the bitsquare team ( or anyone with access to their nodes ) to do timing attacks. Meaning they could log incomming packets on bridges and landing packets on onions, then compare. I can't recall if this attack has been specifically applied to onions but it has certainly been carried out on exits.

I don't think this is a problem for development and testing, its fun to find ways Tor can fail us. Normal Tor functionality is the best option for most(?) users so I think defaulting to bridges might not be good over the long term.

@meapistol: Do you mean for non-Chinese users as well? Or just to avoid trying to connect via normal tor for Chinese users? For the latter: Once bridge addresses are used (after first time failed with normal tor) it will use bridges for the next start instead trying first normal tor. I could offer also program args or a fal in a config file, but I think for most users the current solution is more convenient (unless it does not open up issues as a node tries to connect to tor and then the GFW targets that user).

@agardener: I think a high threat scenario is not likely as long as Bitcoin is legal. And if not, then it would be too dangerous to use Bitsquare anyway (trade peer as undercover attacker gets your bank details in the trade). I think also that bridges are like exit nodes a bottleneck resource and we should only use it when needed. As we use tor hidden services we never exit to clearnet anyway...

Another topic: I am not sure how much time I can dedicate atm for going on with solving that issue. I have a few important bug fixes to do and need to start working on the Bitsquare SyncoNotes (prev. called Bitsquare DAO, but as TheDAO has killed the term, I dont use that anymore :-)).
So if the bridge solution does not work, I fear I need to postpone further work from my side. Of course if anybody else like to help (requires skills on the Java and UI side) they are welcome.
If you like I can offer you (@agardener) to pay out my 1 BTC from the bounty as I trust you that you will support us once resources are available (when @ivilata is back to install the bridge servers, if bridge solution works, or to go on with the next step with pluggable transports). Regarding the other 1 BTC from @meapistol I leave it to him how to proceeed (as the bounty is not really completed yet).

Thanks! I'll certainly stay subscribed to this issue and bring any knowledge that I can. Bitsquare is really promising, I am glad to help where I can!

I'll provide a btc address shortly, cheers!

Here's an address that can be used, thanks!
1BSt5cCGAAPSkBARp66h58GN9hYXDT7nM5

:dancer: @meapistol @ManfredKarrer thank you! :dancer:

I am here to get this working.

@meapistol You sent the 1 BTC to my address, let me know an address where I can send u back.

1F1Hzw1rMarnmQbgrWiyWQT97u6BeKHQFZ

I watched some talks over the weekend and stumbled upon this gem, it's quite recent

Several years ago, the Great Firewall of China was silently upgraded to find and block circumvention servers that employ encryption to defeat deep packet inspection. The system is now used to block protocols such as Tor, SoftEther, and SSH. In this talk, we will give an overview of how this system works, and how it can be circumvented.

From their research, its probably safe to assume that default bridge relays will be blocked because of China's active probing techniques and deep packet inspection. Obfs seems more likely to work because it uses a preshared key and the handshake parameters are scrambled.

Also it might be worth investigating the meek transport which uses content delivery networks like amazon, google, etc to handle bridge connections. This way the gfw would have to block the entire CDN to block one bridge, which maybe isn't possible because of business needs.

@agardener Thanks a lot!
The meek approach sounds most promising. To fight on the technological level alone will be an never ending arms race, but to bring in economic elements (blocking CDN will be to problematic) is interesting.

Hello, this also works for both breaking China firewall as well as circumventing DPRK (California / New York) restrictions which are periodically encountered:
1) How Tor (Including Bridges) Can Be Blocked in China, and How obfsproxy can be used as an evasion technique https://arxiv.org/pdf/1204.0447v1.pdf
Details on obfsproxy: https://www.torproject.org/projects/obfsproxy.html.en
2) See also http://www.cs.kau.se/philwint/static/gfc/ for some additional information.
3) More suggestions https://flossmanuals.net/bypassing-censorship/ch011_get-creative/
See also Freegate https://en.wikipedia.org/wiki/Freegate / Dynaweb http://en.minghui.org/html/articles/2015/2/19/148697.html
4) This review of circumvention tools and methods may also be helpful, from Freedomhouse:
https://freedomhouse.org/sites/default/files/inline_images/Censorship.pdf

Also, doubt, question, and analyze everything you see here.

It is worth to read: My Experience With the Great Firewall of China by Marc Bevand 14 Jan 2016
http://blog.zorinaq.com/my-experience-with-the-great-firewall-of-china/

What is the status of this issue?

Nobody is working on it atm. It requires obfusc4 and/or meek.

In case someone wants to test a rewritten tor wrapper with support for pluggable transports:

  1. get bridges (be sure to select pluggable transports if required)
  2. save the lines you obtained into a file
  3. download this runnable jar which contains demo code for the rewritten tor wrapper
  4. java -jar jtor.jar -b <file containing bridge lines> -p <hidden service port>

This starts a hidden service and connects to it. Ideally everything should take less than two minutes and exit al by itself. Even if it just hangs after some time, it still means it works as long as the output say that a hidden service is ready at some point.
If it works, i'll submit a patch to integrate it into Bitsquare.

Great thanks! @dan-da, @mrosseel: Can anyone of you have a look to it?

I'm getting the following error (I'm on a mac):

Exception in thread "main" java.lang.RuntimeException: Unsupported OS
at org.berndpruenster.jtor.mgmt.OsData.actualGetOsType(OsData.java:66)
at org.berndpruenster.jtor.mgmt.OsData.getOsType(OsData.java:42)
at org.berndpruenster.jtor.mgmt.JavaTorContext.getTorExecutableFileName(JavaTorContext.java:129)
at org.berndpruenster.jtor.mgmt.TorContext.(TorContext.java:49)
at org.berndpruenster.jtor.mgmt.JavaTorContext.(JavaTorContext.java:42)
at org.berndpruenster.jtor.mgmt.JavaTorManager.(JavaTorManager.java:44)
at org.berndpruenster.jtor.demo.Demo.main(Demo.java:33)

@mrosseel could you please re-download and retry?
It should be fixed now

EDIT: bridges can be omitted as well. in this case direct connections to the tor network will be used.

Hidden Service XXXX on 1234 is ready => seems to be working.
Of course I'm not in China ;)

There's also an untested(!) patch integrating the tor wrapper into bitsquare in case anyone is interested in trying it out.
Someone with more knowledge about the bitsquare internals would need to add ways to pass bridge configurations configuration to the wrapper.

@JesusMcCloud Thanks a lot! Unfortunately I will not have time soon to look myself into it.
FYI: I added bridge support in an earlier version and we tested in China but it did not help.

This post might be helpful:
http://blog.zorinaq.com/my-experience-with-the-great-firewall-of-china/

China is now starting to block VPN also.

br,
-mep

On 26 Jan 2017, at 21:02, Manfred Karrer notifications@github.com wrote:

@JesusMcCloud Thanks a lot! Unfortunately I will not have time soon to look myself into it.
FYI: I added bridge support in an earlier version and we tested in China but it did not help.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Does i2p integration sounds too crazy? i2p is faster, (theoretically) safer and not blocked in China (nor anywhere else, afaik).

No i2p integration is not really planned because of too much effort to change all and I doubt it is faster as it has more hops. The anonymity set is much smaller and it is less peer reviewed than Tor.
There is a solution for Tor with plugable transports, we just did not have the resources to implement it.

@JesusMcCloud Did you try this (the obfsproxy thing to evade the blockage)? See Section 6.1, page 15 of the paper linked above.

That, plus fiddling around with the secure web proxy with packet size randomization which was mentioned in here, should do it.

Another thing I've been wondering is if there is a way to do this that would utilize television or radio signal, technically not internet. Bitcoin has already been broadcast over both unlicensed MURS and also over television (DVB-T). It would be a short hop from those accomplishments to have bitcoin related information broadcast over DTMB, which is TV standard for China. The added benefit of broadcasting over DTMB (besides that it would not be internet...) is that you could also test it in Macau or Hong Kong, before proceeding to China and Cuba.

By the way, side note: since a lot of people have been talking about Venezuela lately (and about bitcoin users there), the TV standard in Venezuela is ISDB-T.

@ABISprotocol please read through the previous comments about this issue. There is a solution (including obfs4proxy and other pluggable transports), it is just not integrated yet.

@ManfredKarrer Currently, bridges.torproject.org is unreachable from inside China, but I think I might have a solution to make it all work and automated up to the point of the user having to enter a CAPTCHA. I couldn't find any modified source code that already integrates Tor bridges into bitsquare, and all the links you provided earlier don't have anything uploaded to them anymore. Neither could I find a repository branch that is working on this issue. Would you kindly reupload the modified source code so that I won't have to reinvent the wheel?

It was part of the master branch until 0.4.9 I guess. But it did not help so we removed it. It needs Meek/Obfusc4 but we have not start working on that. If you are experienced in that get in touch.

This is the thing I gather? @ahf

The only reliable way to connect to Tor without VPN from China is the meek-amazon pluggable transport. This has been the case for a long time. Bridges don't work for longer than a couple weeks before they are blocked, and are difficult for the average user to obtain without VPN. Happy to test if someone integrates meek-amazon and meek-azure into Bitsquare.

@CR0CKER: Thanks a lot for the info and your offer to help testing. As soon we have resources to work on it we will come back to you.

New to Bisq by way of Dash. I'm based in Mainland China with software testing experience, willing to help testing new builds to get Bisq working in China. I agree that domain fronting using the meek pluggable transport is the most promising approach here.

Just some information. I got Bisq to work in Wuhan, China, using 12VPN (https://12vpn.net/) first and then starting another VPN to my job inside 12VPN followed by Bisq. It worked for at least a week until I left China. Using one VPN did not work.

I've been able to connect to the network by changing the below files:
C:\Users\NT_USER_NAMEAppData\Local\Bisq\app\Bisq.jar\torrc:
ControlPort auto
CookieAuthentication 1
DisableNetwork 1
AvoidDiskWrites 1
PidFile pid
RunAsDaemon 1
SafeSocks 0
_SOCKSPort 9050
Socks5Proxy 127.0.0.1:1080_

C:\Users\NT_USER_NAMEAppData\Local\Bisq\app\Bisq.jar\socks.properties:
_port = 9050
proxy = 127.0.0.1:9050_

The main idea here is using a socks5 or http or https proxy provided by VPN or ShadowSocks. I'm running on the Windows.
Hope these configuration can be moved to outside or there will be some UI or documentation.

@hanzac: Why you could not connect by default? Is Tor blocked in your country? If not maybe a firewall or blocking ISP was the reason?

@ManfredKarrer Yes. Tor is blocked and I need to use proxy to connect to Tor network.

Thanks @hanzac
I have add Socks5Proxy 127.0.0.1:1080 to C:\Users\NT_USER_NAME\AppData\Local\Bisq\app\Bisq.jar\torrc:,and it is working with shaodowsocksR.
can not connect tor network resolved .

@ManfredKarrer
My country blocked Tor network ,but Tor bridge obfs4 is working.
and the bisq not working default mode.

@hanzac, Tor is blocked in my country, i follow kdaye's method , just add Socks5Proxy 127.0.0.1:1080 to C:\Users\NT_USER_NAMEAppData\Local\Bisq\app\Bisq.jar\torrc, and i can't connect to Tor network . Do I need to modify SOCKSPort 9050 in C:\Users\NT_USER_NAMEAppData\Local\Bisq\app\Bisq.jar\torrc and C:\Users\NT_USER_NAMEAppData\Local\Bisq\app\Bisq.jar\socks.properties:?

If anyone wants to work on pluggable transports integration for Bisq, here is the lib from @JesusMcCloud : https://github.com/JesusMcCloud/netlayer/
That would need to be integrated in bisq and replace the current tor libs. And would need a lot of testing of course...

FYI.
I could use bisq in China with a VPN set up on my US based VPS.

@seanlis, Hi, dude, can you tell me how to connect Bisq use US vps. I have a virtua machine on amazon cloud, and use shodowsocks as a VPS, but i can't to connect Bisq in China.

I have solved my problem with a VPN , thanks!

@taylorshuang you forgot open the local port(1080) for Bisq ,yep?_

@taylorshuang I modified C:\Users\NT_USER_NAMEAppData\Local\Bisq\app\Bisq.jar\socks.properties, because I make tor to serve at 9050 port.

@hanzac, OK, Thanks. It is good idea to directly buy a VPN and no need modify any.

each time I launch bisq-desktop.bat, the following file will be re-create
C:\Users\usernameAppData\Roaming\Bisq\btc_mainnet\tor\torrc
C:\Documents and Settings\usernameAppData\Roaming\Bisq\btc_mainnet\tor\torrc

It prevent I add proxy setting in the torrc file, how to make it re-use exist torrc file and not refresh it?

@raidsan It is not supported yet but planned.
See https://github.com/JesusMcCloud/netlayer/issues/7

@raidsan @ManfredKarrer torrc overrides are supported, using an existing tor is also (basically) working (see JesusMcCloud/netlayer#7).
If you just need to add something to your torrc, you can user torrc overrides are the way to go (though I'm not sure how Bisq handles it).
If you want to use an external tor instance, check JesusMcCloud/netlayer#7

bisq on Linux:
I can't connect bisq network from china, Tor bundle work well through meek-amazon,
But meek-amazon of bisq can't work?

I came across this thread in a random search, you might be interested in the various options of using different transports (and some self-managed bridge options) over at https://www.pluggabletransports.info/

We support pluggable transports. You can enable it either in the settings/network or when the app cannot connect for 4 min. it will show up a popup.

MacOS:
cp Bisq-x-x-x-.jar /yourDirectory
jar xvf Bisq-x-xx-.jar
mv torrc
// add Socks5Proxy 127.0.0.1:1080
jar uf Bisq-x-xx-.jar torrc

Was this page helpful?
0 / 5 - 0 ratings