censorship circumvention / Tor pluggable transports

Development
1

Updated Whonix Configure (Private) (Obfuscated) Tor Bridges documentation and removed pluggable transports that have been deprecated by The Tor Project.

  • removed scramblesuit,
  • and flashproxy

(References for deprecation can be found on the Configure (Private) (Obfuscated) Tor Bridges page.)

Currently supported:

  • obfs3
  • obfs4

Which is not much.

Possibly supported in future:

The Tor Project feature request:
make a deb of meek and get into Debian

Whonix feature request:
install fteproxy by default in Whonix-Gateway when porting to Debian stretch
https://phabricator.whonix.org/T520

The Tor Project feature request:
make a deb of snowflake and get into Debian

Related:

Tickets:

2 Likes
2

meek is important to users in censored area because:

  1. it is the only Tor pluggable transports usable in China
  2. a coming feature that allows users to get Tor Bridges from Tor launcher/anon-connection-wizard relies on it.

However, meek has not been supported neither by Whonix nor by Tails so far. It is very likely because meek has not been packaged in to Debian as a standalone client because of its increasingly high-coupling with TBB.

Related ticket on tor-trac: Make meek-client-torbrowser take the firefox command as a parameter (#12716) · Issues · Legacy / Trac · GitLab

I really would like to do something about it. I will follow up the issue and see what I help with.

2 Likes
3

Exciting news: meek bridges can work in China with a few tiny modifications!

yawning said in Tor ticket #12716:

obfs4proxy as packaged in Debian supports acting as a meek client and has for quite a while.

The implementation of it can be found here:

intrigeri then tested using meek bridges via obfs4proxy in Tails and it worked! However, intrigeri said:

I have no idea if that’s enough to work in China because obfs4proxy’s minimal meek client does not normalize TLS signatures.

The good news is, I tested using meek bridges via obfs4proxy under different ISPs in China, and the approach worked pretty well in those environment.

Use meek bridges via obfs4proxy in Debian8 :

  1. create a Debian8 VM for testing;
  2. add TPO repository for core Tor;
  3. add TPO repository for obfs4proxy (the version in Debian old stable is too low to support acting as a meek client);
  4. sudo apt-get update && apt-get install tor obfs4proxy
  5. Then, edit /etc/tor/torrc as follows:

(I am posting the real bridge info here because the philosophy of meek is collateral freedom, unlike the philosophy of obfs4 which is security by obscurity ):

DisableNetwork 0
UseBridges 1
ClientTransportPlugin obfs3,obfs4,meek_lite exec /usr/bin/obfs4proxy 
Bridge meek_lite 0.0.2.0:2 B9E7141C594AF25699E0079C1F0146F409495296 url=https://d2cly7j4zqgua7.cloudfront.net/ front=a0.awsstatic.com

Notice that it is meek_lite, NOT meek because this is not a real meek client, this is obfs4proxy acting as meek client.

The bridge is used in TBB and the info can be found here: bridge_prefs.js\PTConfigs\Bundle-Data - builders/tor-browser-bundle - Old (2013-2017) build scripts for the Tor Browser Bundle based on gitian-builder

  1. start Tor

TODO:

  1. I have not had it work in Whonix yet. This is very likely because Whonix-gateway automatically filtered the clearnet traffic, including the traffic to AWS.

I tried to use clearnet user according to the documentation, but still got the following error:

[warn] 1 connections have failed:
[warn] 1 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE
  1. I did route my traffic to different ISPs in China when testing because different ISPs have different censorship policies. However, we need more feedback from users in China to know how well this approach work. Maybe ask users for testing?
  2. The version of obfs4proxy package in Debian old stable is 0.0.3, which does not support acting as a meek client. It is really important to get the newer version into Debian because TPO’s repository is censored, not Debian’s. I will report a bug against it.
  3. Document this when it is mature.
  4. Let anon-connection-wizard support meek when it is mature.
4

TODO:

  1. It seems while meek-amazon worked well in censorship circumvention, meek-azure failed to do so. This is strange because both of them are using meek and meek-azure’s server seems not to be censored neither:
    a0.awsstatic.com in China | GreatFire Analyzer
    https://en.greatfire.org/ajax.aspnetcdn.com
    The traffic fee reports of these two servers and the info in Atlas also show no significant difference between meek-amazon and meek-azure. Maybe ask users for testing?
1 Like
5

It is 0.0.7-1.

https://packages.debian.org/stretch/obfs4proxy

Not a problem for Whonix 14?

It’s a DNS resolution issue most likely. /etc/resolv.conf workaround that initrigeri used in Tails should work in Whonix as well. (He mentined it in one of its last posts on this subject that you started.)

(

1 Like
6

Patrick Schleizer:

It is 0.0.7-1.

Debian -- Error

Not a problem for Whonix 14?

Thank you for correcting me this! 0.0.3 is for old stable.

Not a problem for Whonix 14 :slight_smile:

It’s a DNS resolution issue most likely. /etc/resolv.conf
workaround that initrigeri used in Tails should work in Whonix as
well. (He mentined it in one of its last posts on this subject that
you started.)

Thank you for pointing this out, Patrick!

I did not see the complains initigeri described, however. (Most likely
because I didn’t look into the right place):

22: connecting to the meek bridge requires working DNS

( -
Whonix-Gateway Traffic: Transparent Proxying

)

Thank you so much for your instructions, Patrick!

I will test it according to the docs very soon!

1 Like
7

this post https://labs.riseup.net/code/issues/8243#note-12 - /etc/hosts … That’s how he made it work. Should work in Whonix as well. Basically by amending /etc/hosts we can preseed the IP result of DNS lookups. At the price of slower updates than IPs would generally update.

I don’t think we should use the above wiki links by me in production. But anyhow… If you do…

For testing… Login as user debian-tor.

sudo -u debian-tor bash

Check if DNS resolution is functional.

nslookup whonix.org

Perhaps the above wiki links are not even required. Tor is allowed to issue any traffic. Just /etc/resolv.conf on Whonix-Gateway intentionally is dysfunctional. But that’s not so important. We could have functional /etc/resolv.conf for user debian-tor, functional DNS for Tor, but still block DNS for everything else on Whonix-Gateway by default.

1 Like
8

Tested on Whonix13 with obfs4proxy updated to 0.0.7 and Whonix14, both successfully connected to the Tor network. My configuration:

in /etc/hosts added:

## meek_lite specific
93.184.221.200 ajax.aspnetcdn.com
52.222.172.206 a0.awsstatic.com
## End of meek_lite specific

in /etc/tor/torrc added:

DisableNetwork 0
UseBridges 1
ClientTransportPlugin meek_lite exec /usr/bin/obfs4proxy 
Bridge meek_lite 0.0.2.0:2 B9E7141C594AF25699E0079C1F0146F409495296 url=https://d2cly7j4zqgua7.cloudfront.net/ front=a0.awsstatic.com

In both tests, I did the two commands above and I was getting an error:

debian-tor@host:/home/user$ nslookup whonix.org
;; connection timed out; no servers could be reached

I also enabled the Transparent Proxy on Whonix-Gateways following:

And then tried again. But I still got the error.

Did I do something wrong?

https://github.com/Whonix/anon-base-files/blob/master/etc/hosts.anondist

If this is the approach we decided to adopt, I can keep an eye on this and pull request when the IPs are changed.

Please forgive my ignorance, the hostname need to be resolved so that we can connect to the Tor network. Therefore, we can not use send the DNS request over Tor successfully in this case? In other words, we had to send the DNS request for resolving a0.awsstatic.com through clearnet?

Thank you very much for your guidance, Patrick!

9

iry:

Tested on Whonix13 with obfs4proxy updated to 0.0.7 and Whonix14,
both successfully connected to the Tor network. My configuration:

in /etc/hosts added:

meek_lite specific 93.184.221.200 ajax.aspnetcdn.com

52.222.172.206 a0.awsstatic.com ## End of meek_lite specific

in /etc/tor/torrc added:

DisableNetwork 0 UseBridges 1 ClientTransportPlugin meek_lite exec
/usr/bin/obfs4proxy Bridge meek_lite 0.0.2.0:2
B9E7141C594AF25699E0079C1F0146F409495296
url=https://d2cly7j4zqgua7.cloudfront.net/ front=a0.awsstatic.com

Great!

Wondering, is it possible to use IP addresses rather than hostnames in
torrc? So we could avoid editing /etc/hosts.

In both tests, I did the two commands above and I was getting an
error:

debian-tor@host:/home/user$ nslookup whonix.org
;; connection timed out; no servers could be reached

I also enabled the Transparent Proxy on Whonix-Gateways following:
Whonix-Gateway Traffic: Transparent Proxying

And then tried again. But I still got the error.

Did I do something wrong?

No. My mistake. These instructions don’t make sense here.

Go to a non-Whonix VM. Figure out your nameserver settings.

cat /etc/resolv.conf

Got to sys-whonix and replace its /etc/resolv.conf with the settings
from your non-Whonix VM.

Then.

sudo -u debian-tor bash

Then nslookup torproject.org etc. will work. Just now tested.

That gives Tor full DNS access.

https://github.com/Whonix/anon-base-files/blob/master/etc/hosts.anondist

If this is the approach we decided to adopt, I can keep an eye on
this and pull request when the IPs are changed.

Please forgive my ignorance, the hostname need to be resolved so that
we can connect to the Tor network. Therefore, we can not use send the
DNS request over Tor successfully in this case? In other words, we
had to send the DNS request for resolving a0.awsstatic.com through
clearnet?

Correct.

What above - new - instructions do is: allow Tor do resolve DNS using
clearnet with your usual DNS settings that any clearnet VM would be
using. I will think about this more, but I don’t think this has any
disadvantages. Except:

  • when Whonix-Firewall would be broken plus at the same time its fail
    closed mechanism not work
  • and when the user is trying to use Whonix-Gateway as a workstation
  • then the user would be using clearnet

Thank you very much for your guidance, Patrick!

You’re very much welcome! :slight_smile:

2 Likes
10

That was I was thinking about, too. Unfortunately, no, it does not work in that way. I was planning to do a feature request, but then I was yawning saying:

It’s not immediately obvious to me if Azure does any sort of DNS based load balancing. AWS appears to be doing so.

which means, the IP may change dynamically to get the best connection performance? If so, is it still a good idea to use static IP in /etc/hosts?

1 Like
11

I have no idea if that’s enough to work in China because obfs4proxy’s minimal meek client does not normalize TLS signatures.

Yawning replied:

Currently this doesn’t appear to matter much, or at least, if it does, then Nathan hasn’t told me (Orbot uses meek_lite).

So meek_lite works in China!

1 Like
12

Yes, the instructions work!

1 Like
13

Done:

3 Likes
14

https://github.com/Whonix/Whonix/commit/41680a74746d2a69b9ed25bc150ec09a961ff13a

3 Likes
15

This is awesome! I am a big fan of meek and its great to see it land at last.

Something I thought about but I’m not sure how relevant it is: Lets say someone installs wireshark on the gw to do some leak testing. Wireshark tends to autoresolve IPs by querying the installed DNS resolver - which would leak info about sites visited in the WS? So is there a way to control access to the GW DNS resolver (app by app basis) to stop scenarios like this from happening?

2 Likes
16

As long as wireshark does not run as user debian-tor but as user or root, as per Whonix-Gateway firewall default settings, there will still be no DNS access.

Not that I know. We have access control on a linux user account basis.

2 Likes
17

Awesome. Good to know that the user account trick works for this, so we can have our cake and eat it too. Thanks again to you and @iry for making meek for Whonix happen.

2 Likes
18

Getting meek work in Whonix14 is a great UX improvement for user in heavily censored area in my opinion. It means those users do not need any self hacking to connect to the Tor network.

Do you think it is a good idea that I write a brief Whonix Blog post about using meek in Whonix to draw more attention before the release of Whonix14?

I will do some preparation work, too:

  1. Document meek in Whonix Wiki.
1 Like
19

Do you think it is a good idea that I write a brief Whonix Blog post about using meek in Whonix to draw more attention before the release of Whonix14?

Sure. Why not.

1 Like
20

Another TODO:

Since meek(meek_lite) has integrated into Whonix14, and also since anon-connection-wizard is coming, a rewrite of Bridge Wiki page is needed:

Edit: Done.

1 Like