How to use the “meek” pluggable transport
The recently released 4.0-alpha-1 version of Tor Browser includes meek, a new pluggable transport for censorship circumvention. meek tunnels your Tor traffic through HTTPS, and uses a technique called “domain fronting” to hide the fact that you are communicating with a Tor bridge—to the censor it looks like you are talking to some other web site. For more details, see the overview and the Child’s Garden of Pluggable Transports.
You only need meek if your Internet connection is censored so that you can’t use ordinary Tor. Even then, you should try other pluggable transports first, because they have less overhead. My recommended order for trying transports is:
- obfs3
- fte
- scramblesuit
- meek
- flashproxy
Use meek if other transports don’t work for you, or if you want to help development by testing it. I have been using meek for my day-to-day browsing for a few months now.
All pluggable transports have some overhead. You might find that meek feels slower than ordinary Tor. We’re working on some tickets that will make it faster in the future: #12428, #12778, #12857.
At this point, there are two different backends supported. meek-amazon makes it look like you are talking to an Amazon Web Services server (when you are actually talking to a Tor bridge), and meek-google makes it look like you are talking to the Google search page (when you are actually talking to a Tor bridge). It is likely that both will work for you. If one of them doesn’t work, try the other.
These instructions and screenshots are for the 4.0-alpha-1 release. If they change in future releases, they will be updated at https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart.
How to use meek
First, download a meek-capable version of Tor Browser for your platform and language.
Verify the signature and run the bundle according to the instructions for Windows, OS X, or GNU/Linux.
On the first screen, where it says Which of the following best describes your situation?, click the Configure button.
On the screen that says Does this computer need to use a proxy to access the Internet?, say No unless you know you need to use a proxy. meek supports using an upstream proxy, but most users don’t need it.
On the screen that says Does this computer's Internet connection go through a firewall that only allows connections to certain ports?, say No. As an HTTPS transport, meek only uses web ports, which are allowed by most firewalls.
On the screen that says Does your Internet Service Provider (ISP) block or otherwise censor connections to the Tor Network?, say Yes. Saying Yes will lead you to the screen for configuring pluggable transports.
On the pluggable transport screen, select Connect with provided bridges and choose either meek-amazon or meek-google from the list. Probably both of them will work for you, so choose whichever feels faster. If one of them doesn’t work, try the other. Then click the Connect button.
If it doesn’t work, you can write to the tor-dev mailing list, or to me personally at dcf@torproject.org, or file a new ticket.
Comments
Please note that the comment area below has been archived.
Why isnt meek in the
Why isnt meek in the transport search parameter list of bridgedb?
It's because meek doesn't
It's because meek doesn't use "bridges" the same way that other transports do. Instead of going through a bridge with a secret address, you go through a known domain (www.google.com for example) that the censor will be reluctant to block. You don't need to look up any bridge addresses before you get started.
The "bridge lines" for meek really just give the URL of a Tor bridge that is running the meek-server program, and the "front domain" that you hide behind. There is an IP address, but it is meaningless and ignored. If you want to experiment with different front domains (like using www.gmail.com instead of www.google.com), you can try pasting variations on the default bridge lines:
meek 0.0.2.0:1 url=https://meek-reflect.appspot.com/ front=www.google.com
meek 0.0.2.0:2 url=https://d2zfqthxsdq309.cloudfront.net/ front=a0.awsstatic.com
Help me understand the
Help me understand the safety of meek... Connections to Google and Amazon carry a ton of info about their users, and are most likely especially watched under another code-name project of the watchful eye. So why do you offer the Tor users to get especially tracked there on each connection?
You're right that using meek
You're right that using meek means there are more entities who can watch the traffic patterns between you and your first hop. With ordinary bridges it is:
With meek it is:
Of course, none of these entities gets to see your plaintext directly—there is still a Tor encryption layer underneath meek's HTTPS tunnel. But all those entities are in a better position to do timing correlation, for example.
It's important to understand that Amazon/Google don't actually get to see what web sites you browse. What they see is a bunch of encrypted HTTPS POST requests, which they forward to a Tor bridge. Amazon/Google knows that your IP address is using Tor; what we're trying to do is prevent the censor from knowing it.
It's because meek doesn't
It's because meek doesn't use "bridges" the same way that other transports do. Instead of going through a bridge with a secret address,
Meek is a brilliant idea compared to using bridges. According to Snowden, the NSA routinely scans email requests for Tor bridges and then hacks into those requested Tor bridges. I'm sure the Chinese PLA has learned from the NSA using such hacks too.
@ dcf Thanks for the
@ dcf
Thanks for the detailed guide with accompanying graphics on how to use *meek*.
Could you please upload it to a central repository or location where all the other guides are kept? We users don't need to scroll through pages of Tor's blog just to find the guide we're interested in.
I don't know whether detailed guides with illustrations have already been written for the following:
obfs3
fte
scramblesuit
flashproxy
If they haven't been written, would you please prepare one guide for each of the above?
Thanks in advance.
For meek, what you want is
For meek, what you want is at https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart.
There's a guide to using flash proxy at https://trac.torproject.org/projects/tor/wiki/FlashProxyHowto.
Unfortunately I don't think there's a central place with guides on how to use all the pluggable transports. It would be a nice thing to have. For obfs3, fte, and scramblesuit, the process is pretty much the same as with meek, except you choose "obfs3", "fte", or "scramblesuit" on the last screen. If the default bridges don't work, then you need to get some bridges from https://bridges.torproject.org/ (select the matching transport name in the "Do you need a Pluggable Transport?" box).
@ dcf I noticed there are
@ dcf
I noticed there are only two provided *meek* bridges: meek-amazon and meek-google.
It's a well-known fact that Google is routinely blocked in mainland China.
For users in mainland China, would you consider adding the following *meek* bridges?
meek-baidu (www.baidu.com is the de facto search engine in mainland China)
meek-alibaba (www.alibaba.com is the de facto B2C e-commerce site)
meek-taobao (www.taobao.com is the de facto C2C e-commerce site)
meek-xunlei (www.xunlei.com is the de facto bittorrent site)
meek-yahoo
You can see some of the
You can see some of the other services we've considered so far at https://trac.torproject.org/projects/tor/wiki/doc/meek#Webservices.
It's not so trivial to set up a new backend. It requires first for someone to become a customer (of Google, Amazon, etc.) and start paying for bandwidth. Also the service has to support the domain fronting trick, which many CDNs do, but ecommerce sites may not. If your censor is the Great Firewall, then you don't want to use a web service whose servers are in China, because meek only hides your traffic until it reaches the web service. After that, it goes to a Tor bridge.
If you want to see more backends, you can help by testing whether they support domain fronting. There are some examples of Wget commands at https://trac.torproject.org/projects/tor/wiki/doc/meek#Webservices. For example, this command demonstrates domain fronting on Google. We ask for www.google.com, which would normally have the title "Google", but by overriding the Host header, we get back "Google Maps" instead.
$ wget -O - -q https://www.google.com/ --header 'Host: maps.google.com' \
| grep -io '<title>.*</title>'
<title>Google Maps</title>
we need obfs4 it could help
we need obfs4 it could help also against some attacks
Which would be the most
Which would be the most "secure" transport if one was in a country where:
a) access X website gives you death penalty;
b) use Tor gives you death penalty;
c) you ABSOLUTELY HAD to access X website, but didn't want to use regular Tor (see b).
Which transport would provide the best "innocent looking" connection?
Thanks for your work on fghting censorship worldwide!
In my opinion, none of the
In my opinion, none of the transports gives you the degree of unobservability you would want if your life were truly at stake. As always, it is a question of risk and resources. Using Tor is probably safer than not using Tor, and pluggable transports are by design harder to detect that plain Tor traffic. But none of the pluggable transports provides strong protection against an adversary who will hurt you for merely using a circumvention tool. Consider that the censor may be recording all traffic, and even if it cannot detect a circumvention tool today, it may be able to in the future, and punish users retroactively.
I can't pick a best transport, because what's best depends on the situation. Some transports are designed against different kinds of censorship, for example IP blocking versus deep packet inspection. If you want to see what the transports actually look like, I encourage you to browse https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPlugga…. We've tried to remove some of the mystery about what happens when you use a pluggable transport.
Won't using it drive
Won't using it drive additional attention from powerful western government adversaries since we know about PRISM, XKEYSCORE etc? I mean since we know about targeting tor users for surveillance some may want to hide the fact that they're using tor and failing at it may drive additional attention. Is it a proper way of hiding tor usage against spy agencies like NSA collaborating with big US based internet companies? I understand this solution and other types of bridges addresses different threat model (internet censorship in dictatorship countries) but still it's good to think about it.
You are right, it depends on
You are right, it depends on your threat model. One of the assumptions that meek makes is that the intermediate web service (Amazon/Google) doesn't collaborate with the adversary, wittingly or unwittingly. The assumption probably holds in a lot of censorship situations, but it fails when an adversary is able to tap or hack or make a deal with the company in the middle.
We use a big Internet company as the middleman because the censor can block meek just by blocking the web service in the middle. If the service is big and has lots of useful services, then it will be painful for the censor to block it. (We usually call such overblocking "collateral damage" and it is one of the things that helps circumvention.) It's a different blocking resistance strategy than that of Tor bridges (distribute bridge addresses carefully through BridgeDB to prevent the censor from learning all of them) and that of flash proxy (let bridges be easy to block, but create them so fast that the censor can't keep up).
Actually there is a way to
Actually there is a way to tackle the problem of both anonymously connecting to tor and protecting against timing attacks in light of an global observer who has all domestic connections and most internet backbones tapped (ie who can both observe you connecting to tor and deanonymize your clearnet traffic). This method takes into account the post-snowden revelations of the global surveillance apparatus (see picture below). Basically it works like this:
1. Find an encrypted VPN service both headquarted and with (a couple) servers outside of a surveillance state, and outside of your country. Find one with some commitment to privacy even if its only by policy. It will need strong openVPN encryption as well.
2. Either connect via bridges or set in your torrc file (EntryNodes) entry guards who are located in a non-surveillance country one of your vpn's servers are located in.
3. Connect to your VPN.
4. (optional) Fire up your bittorrent client, start downloading something, this will produce cover traffic. Both your tor and bittorrent encrypted VPN packets will be packaged together. This is only a concern if you believe the NSA can use a packet timing attack to decipher a lone Tor stream in a VPN tunnel.
5. Connect to Tor. Your connection will pass encrypted through over tapped cables and end up at the VPN's server located in a non-sigint country and pass directly into the tor network without passing back over a tapped cable. If for instance you were to have a VPN server in denmark and connect to a swiss entry guard, there is a good probability that your connection will route back to new york on its way there. You can test this for yourself by doing a traceroute from you vpn's ip to the guard you want to connect to, if you see it go outside of the country find a new guard or try a different country.
The only weaknesses in this method, provided of course that that using a VPN isnt cause enough for suspicion, is that the country you are utilizing is infact secretly part of the SIGINT program, or will roll over for your parent country. Otherwise there is no way for the NSA to tell that you are connecting to Tor, (and no probable cause to supeona your VPN for records).
You can of course use any of these obfuscation and proxying methods, but none of them take into account a global adversary with a birds eye view who can easily see through them all. The method ive described is the only way to hide ones connection to the network and therefore defeat any attempts at correlating traffic.
http://www.medianama.com/wp-content/uploads/sigint-partners.png
I would be eager to hear any
I would be eager to hear any response the Tor devs may have to these claims and suggestions.
Now we just need screenshot
Now we just need screenshot examples from an OS that isn't completely untrustworthy. Not sure how confident I am with TOR at times when I see a propriety OS used for the example screenshots on a how to for it...
TORs target audience isn't
TORs target audience isn't limited to highly technical users who can make well informed decisions about the software on their computer. Screenshot examples should be targeted towards those who need them to figure out how to get a particular feature to work.
Right. Don't worry, David is
Right. Don't worry, David is a real certified Linux person. You may know him better under his 'nmap developer' hat. He picked Windows for his screenshots a) because many users are on Windows, and b) because the Windows users tend to need screenshots more than the Linux users. I think that's a great choice.
In scramblesuit, can we
In scramblesuit, can we choose any password we desire?
In theory, yes as long as
In theory, yes as long as the password is exactly 160 bits.
There's no real benefit to picking any specific password (as in, I would recommend it be randomly generated) as all current ScrambleSuit implementations expect the password to be in Base32 encoding when passed as an argument, so something that started off being human readable won't be on a bridge line.
how many chharacters are 160
how many chharacters are 160 bits? 160?
can it include numbers and $ymb0l$?
Can it include upper case?
Can it include upper case?
what are the benefits of
what are the benefits of changing the password every now and then? does it encrease security/privacy/crypto resistence?
The only benefit I can think
The only benefit I can think of is that if the adversary you are concerned about happens to already have your bridge IP address/shared secret somehow (eg: A basement full of people all requesting bridges from BridgeDB), then they will need to obtain it again.
However this assumes that they do not have an existing valid session ticket, in which case changing the password does absolutely nothing as k_B is not used for that handshake mechanism (k_sh is used instead).
In general I would discourage doing this sort of thing as it inconveniences existing bridge users (they will fail to bootstrap the moment their session ticket expires, and would need to update the bridge line) for minimalistic gain.
Note: ScrambleSuit is designed to provide obfuscation, not security. Depending on it for the latter would be a bad idea.
Does using a bridge adds an
Does using a bridge adds an extra hop? or does it replace your guard node?
It replaces your guard.
It replaces your guard.
When using goagent, I can
When using goagent, I can create free GAE accounts and use them in goagent. So a question for meek, can I build my own free bridges and use them in Tor browser?
Yes, you can do that. The
Yes, you can do that. The public appid we are running is meek-reflect.appspot.com. The source code for the App Engine component is at https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/…. Instructions for uploading it are at https://gitweb.torproject.org/pluggable-transports/meek.git/blob/HEAD:/…. You will have to put your own appid in https://gitweb.torproject.org/pluggable-transports/meek.git/blob/HEAD:/… (replacing "meek-reflect").
You will have to manually enter a bridge line in your Tor Browser configuration. It will look like:
meek 0.0.2.0:1 url=https://appid.appspot.com/ front=www.google.com
To get the source code, use
git clone https://git.torproject.org/pluggable-transports/meek.git
Can you please to let us
Can you please to let us know Why i can not fill new Bridge scramblesuit into torroc/tor/Data/TorBrowser? when i open Start Tor Browser, that new Bridge scramblesuit has been disappeared, It is only keep old Bridge scramblesuit. This issue is also same for FTE Bridge, i hope to fill new FTE Bridge into torroc/tor/Data/TorBrowser? when old FTE Bridge can not work.
"The meek shall inherit the
"The meek shall inherit the earth." ?
Amen.
Amen.
Hi I want to know what DNS
Hi
I want to know what DNS server does tor use?
And Can I change tor to use my prefer DNS? For example I want it to use 4.2.2.4
i installed tor bridge on my
i installed tor bridge on my server and now what kind of pluggable transport. users can use to connect to my server? all of them ?
By default, a bridge doesn't
By default, a bridge doesn't run any pluggable transports. You have to set it up separately. For obfs3, you can follow these instructions:
For fte, follow
You will know it works when you see a line like this in your tor log:
Registered server transport 'obfs3' at '0.0.0.0:42000