The meek pluggable transport is currently running on the bridge I run, which also happens to be the backend bridge for flash proxy. I'd like to move it to a fast relay run by an experienced operator. I want to do this both to diffuse trust, so that I don't run all the infrastructure, and because my bridge is not especially fast and I'm not especially adept at performance tuning.
All you will need to do is run the meek-server program, add some lines to your torrc, and update the software when I ask you to. The more CPU, memory, and bandwidth you have, the better, though at this point usage is low enough that you won't even notice it if you are already running a fast relay. I think it will help if your bridge is located in the U.S., because that reduces latency from Google App Engine.
The meek-server plugin is basically just a little web server: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/meek-...
Since meek works differently than obfs3, for example, it doesn't help us to have hundreds of medium-fast bridges. We need one (or maybe two or three) big fat fast relays, because all the traffic that is bounced through App Engine or Amazon will be pointed at it.
My PGP key is at https://www.bamsoftware.com/david/david.asc if you want to talk about it.
David Fifield
On 16/09/14 03:12, David Fifield wrote:
The meek pluggable transport is currently running on the bridge I run, which also happens to be the backend bridge for flash proxy. I'd like to move it to a fast relay run by an experienced operator. I want to do this both to diffuse trust, so that I don't run all the infrastructure, and because my bridge is not especially fast and I'm not especially adept at performance tuning.
All you will need to do is run the meek-server program, add some lines to your torrc, and update the software when I ask you to. The more CPU, memory, and bandwidth you have, the better, though at this point usage is low enough that you won't even notice it if you are already running a fast relay. I think it will help if your bridge is located in the U.S., because that reduces latency from Google App Engine.
The meek-server plugin is basically just a little web server: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/meek-...
Since meek works differently than obfs3, for example, it doesn't help us to have hundreds of medium-fast bridges. We need one (or maybe two or three) big fat fast relays, because all the traffic that is bounced through App Engine or Amazon will be pointed at it.
My PGP key is at https://www.bamsoftware.com/david/david.asc if you want to talk about it.
As an extension, how about putting multiple bridges behind the reflector? Tor does not yet pass the bridge fingerprint to PTs, but we could hack it up along the lines of:
Bridge meek 0.0.2.0:1 $FINGERPRINT1 fpr=$FINGERPRINT1 url=https://meek-reflect.appspot.com/ front=www.google.com Bridge meek 0.0.2.0:1 $FINGERPRINT2 fpr=$FINGERPRINT2 url=https://meek-reflect.appspot.com/ front=www.google.com
meek-client would pass fpr to the reflector, who would select the bridge it connects the client to.
(This is basically what I have in mind for #10196 for flashproxy.)
X
On 15 September 2014 21:12, David Fifield david@bamsoftware.com wrote:
Since meek works differently than obfs3, for example, it doesn't help us to have hundreds of medium-fast bridges. We need one (or maybe two or three) big fat fast relays, because all the traffic that is bounced through App Engine or Amazon will be pointed at it.
A horrible idea Isis and I came up with was standing up two or more tor servers with the same keys, on an anycast-ed IP address. I'm not sure how the meek backend works, but if it's not set up already to support round-robining, you would likely be able to trick it into doing some by duplicating keys and doing DNS round-robining or other networking-layer tricks.
-tom
On Wed, Sep 17, 2014 at 09:05:39PM -0500, Tom Ritter wrote:
On 15 September 2014 21:12, David Fifield david@bamsoftware.com wrote:
Since meek works differently than obfs3, for example, it doesn't help us to have hundreds of medium-fast bridges. We need one (or maybe two or three) big fat fast relays, because all the traffic that is bounced through App Engine or Amazon will be pointed at it.
A horrible idea Isis and I came up with was standing up two or more tor servers with the same keys, on an anycast-ed IP address. I'm not sure how the meek backend works, but if it's not set up already to support round-robining, you would likely be able to trick it into doing some by duplicating keys and doing DNS round-robining or other networking-layer tricks.
I'm really not too worried about capacity. Any single fast-ish bridge will do for the kind of numbers we're seeing now. Even the current bridge is more than enough for the time being. I'm just trying to make the point that it's a different threat model: it's not helpful to have hundreds of people running relays the way it is with obfs3.
Currently in the bundles we're not setting a bridge fingerprint, so relays wouldn't have to share a key. You *would* have to make sure that the same client always gets forwarded to the same relay, because your logical Tor stream gets segmented into multiple HTTP requests and it takes some bookkeeping on the relay side to reassemble them.
But we're a long way from needing to think about round-robining. One good relay, of capacity similar to what the default obfs3 bridges have, would cover us well into the future, I reckon, even if there were a big increase in meek users. Look at the user graphs: https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&a... We're still a long long way from being limited by relay capacity. We'll be worried about how to pay CDN fees long before relay capacity becomes an issue.
A more reasonable reason to have more than one backend relay is if you worry about that relay getting owned or its operator going rogue. That's a reasonable thing to think about. It's really easy to use a different bridge for each CDN, at least, and I think we'd do that before doing anycast tricks.
David Fifield
On 18/09/14 03:31, David Fifield wrote:
Currently in the bundles we're not setting a bridge fingerprint, so relays wouldn't have to share a key.
This is something to be *fixed*, not to build future components on top of.
Previously you mentioned that "the user could set their circuits to 4 hops" but I think this is a hack of a solution and we can do better, by authenticating the Bridge.
In both flashproxy/meek, we're already authenticating the facilitator/reflector, so why should we treat the Bridge any differently?
X
On Thu, Sep 18, 2014 at 02:02:42PM +0100, Ximin Luo wrote:
On 18/09/14 03:31, David Fifield wrote:
Currently in the bundles we're not setting a bridge fingerprint, so relays wouldn't have to share a key.
This is something to be *fixed*, not to build future components on top of.
Previously you mentioned that "the user could set their circuits to 4 hops" but I think this is a hack of a solution and we can do better, by authenticating the Bridge.
I really disagree with you here :( I don't understand your point of view. Let's try and assume good faith.
Do you remember a couple of days ago, when I had to separate the tor processes for flash proxy and meek because the metrics were getting mixed up? That would have been *impossible* to do if there were hardcoded fingerprints out there in bundles. And how I recently put out a call for someone else to run the meek bridge? How is that transition supposed to work if changing the fingerprint means we suddenly and inexplicably break every existing client installation?
The answer surely isn't "make sure the bridge's private key never changes" and it isn't "anticipate every possible eventuality indefinitely into the future."
Can you explain what you don't like about four hops? To me it feels like the right thing. It wouldn't just be for meek, you know, but for all bridge circuits (including ordinary plain-vanilla bridges). When you're using a bridge you treat the first hop as unauthenticated and unencrypted, as if it were a SOCKS proxy or third-party VPN or any other circumvention proxy. You treat the first hop as not chosen by you, because it's not: even with BridgeDB you're just pasting in some bytes the web site chose for you. After your first circumvention hop, then you add your own three hops, notably including your own chosen guard. bridge → guard → middle → exit
David
On 18/09/14 16:41, David Fifield wrote:
On Thu, Sep 18, 2014 at 02:02:42PM +0100, Ximin Luo wrote:
On 18/09/14 03:31, David Fifield wrote:
Currently in the bundles we're not setting a bridge fingerprint, so relays wouldn't have to share a key.
This is something to be *fixed*, not to build future components on top of.
Previously you mentioned that "the user could set their circuits to 4 hops" but I think this is a hack of a solution and we can do better, by authenticating the Bridge.
I really disagree with you here :( I don't understand your point of view. Let's try and assume good faith.
Do you remember a couple of days ago, when I had to separate the tor processes for flash proxy and meek because the metrics were getting mixed up? That would have been *impossible* to do if there were hardcoded fingerprints out there in bundles. And how I recently put out a call for someone else to run the meek bridge? How is that transition supposed to work if changing the fingerprint means we suddenly and inexplicably break every existing client installation?
Practically you are right, but this is only because of the weird dynamics of these particular PTs, namely that there is only one bridge that everyone relies on. This is not an ideal situation, and we should deploy more bridges.
If we had 10 meek PTs and everyone had 3 meek Bridge lines, your original problem wouldn't be a problem. Or at least, it would be solve in the same way as everything else - if your obfs3/fte bridge goes down, you go to BridgeDB and ask for another bridge line, or whatever other channel you used to get that line in the first place.
The answer surely isn't "make sure the bridge's private key never changes" and it isn't "anticipate every possible eventuality indefinitely into the future."
Can you explain what you don't like about four hops? To me it feels like the right thing. It wouldn't just be for meek, you know, but for all bridge circuits (including ordinary plain-vanilla bridges). When you're using a bridge you treat the first hop as unauthenticated and unencrypted, as if it were a SOCKS proxy or third-party VPN or any other circumvention proxy. You treat the first hop as not chosen by you, because it's not: even with BridgeDB you're just pasting in some bytes the web site chose for you. After your first circumvention hop, then you add your own three hops, notably including your own chosen guard. bridge → guard → middle → exit
What I don't like about "4 hops" is that it is actually "5 hops". In meek you have the reflector, and in flashproxy you have the proxy. I think it would be better to get this down to 4 actual hops.
You raise a good point about the first hop not being chosen (generally) by the user. This is partly a quirk with the design of Bridges. In a censored area, you have to go through the Bridge to even download the consensus, so the client then only picks 2 other hops. Then your Bridge pretty much acts as a Guard.
However, with meek/flashproxy, we have something else that bypasses the censorship (the reflector/flashproxy). To go along with your "SOCKS/VPN proxy" scenario, ideally what would happen is, the client goes through the reflector/flashproxy to download the consensus, then picks 3 more hops from the consensus that are authenticated.
You didn't pick this design for meek/flashproxy because it was a security risk to allow flashproxies to connect to arbitrary IPs, and it would be a lot of effort to implement code that restricts these connections only to allowing downloading of the consensus / connecting to IPs in the consensus. So you put another Tor Bridge beyond that, which already implements this logic, and restrict connections only to this Bridge. But it means we have to have 5 hops instead of 4 hops.
I do understand your arguments though, I just think it is better to have (4-real-hops and slightly extra work when a Bridge goes down) rather than (5 hops all the time).
X
On 09/18/2014 12:06 PM, Ximin Luo wrote:
On 18/09/14 16:41, David Fifield wrote:
On Thu, Sep 18, 2014 at 02:02:42PM +0100, Ximin Luo wrote:
On 18/09/14 03:31, David Fifield wrote:
Currently in the bundles we're not setting a bridge fingerprint, so relays wouldn't have to share a key.
This is something to be *fixed*, not to build future components on top of.
Previously you mentioned that "the user could set their circuits to 4 hops" but I think this is a hack of a solution and we can do better, by authenticating the Bridge.
I really disagree with you here :( I don't understand your point of view. Let's try and assume good faith.
Do you remember a couple of days ago, when I had to separate the tor processes for flash proxy and meek because the metrics were getting mixed up? That would have been *impossible* to do if there were hardcoded fingerprints out there in bundles. And how I recently put out a call for someone else to run the meek bridge? How is that transition supposed to work if changing the fingerprint means we suddenly and inexplicably break every existing client installation?
Practically you are right, but this is only because of the weird dynamics of these particular PTs, namely that there is only one bridge that everyone relies on. This is not an ideal situation, and we should deploy more bridges.
If we had 10 meek PTs and everyone had 3 meek Bridge lines, your original problem wouldn't be a problem. Or at least, it would be solve in the same way as everything else - if your obfs3/fte bridge goes down, you go to BridgeDB and ask for another bridge line, or whatever other channel you used to get that line in the first place.
Sorry for resurrecting this thread; but it seems like there are two challenges here - one is meek's more centralized setup - I see meek as a uniquely powerful option among many to increase the cost of censorship. Were it the only transport, I'd be concerned.
Separately, however, the concept of treating the bridge node as an untrusted entry point to the "normal" 3-hop tor network strikes me as a valuable change. If the role of the bridge was to only provide an encrypted, uncensored, path, does this enable different types of bridges that would not be safe in the model where the bridge is also the first hop?
Cheers, Jon
The answer surely isn't "make sure the bridge's private key never changes" and it isn't "anticipate every possible eventuality indefinitely into the future."
Can you explain what you don't like about four hops? To me it feels like the right thing. It wouldn't just be for meek, you know, but for all bridge circuits (including ordinary plain-vanilla bridges). When you're using a bridge you treat the first hop as unauthenticated and unencrypted, as if it were a SOCKS proxy or third-party VPN or any other circumvention proxy. You treat the first hop as not chosen by you, because it's not: even with BridgeDB you're just pasting in some bytes the web site chose for you. After your first circumvention hop, then you add your own three hops, notably including your own chosen guard. bridge → guard → middle → exit
What I don't like about "4 hops" is that it is actually "5 hops". In meek you have the reflector, and in flashproxy you have the proxy. I think it would be better to get this down to 4 actual hops.
You raise a good point about the first hop not being chosen (generally) by the user. This is partly a quirk with the design of Bridges. In a censored area, you have to go through the Bridge to even download the consensus, so the client then only picks 2 other hops. Then your Bridge pretty much acts as a Guard.
However, with meek/flashproxy, we have something else that bypasses the censorship (the reflector/flashproxy). To go along with your "SOCKS/VPN proxy" scenario, ideally what would happen is, the client goes through the reflector/flashproxy to download the consensus, then picks 3 more hops from the consensus that are authenticated.
You didn't pick this design for meek/flashproxy because it was a security risk to allow flashproxies to connect to arbitrary IPs, and it would be a lot of effort to implement code that restricts these connections only to allowing downloading of the consensus / connecting to IPs in the consensus. So you put another Tor Bridge beyond that, which already implements this logic, and restrict connections only to this Bridge. But it means we have to have 5 hops instead of 4 hops.
I do understand your arguments though, I just think it is better to have (4-real-hops and slightly extra work when a Bridge goes down) rather than (5 hops all the time).
X
On Thu, Sep 18, 2014 at 08:41:20AM -0700, David Fifield wrote:
On Thu, Sep 18, 2014 at 02:02:42PM +0100, Ximin Luo wrote:
On 18/09/14 03:31, David Fifield wrote:
Currently in the bundles we're not setting a bridge fingerprint, so relays wouldn't have to share a key.
This is something to be *fixed*, not to build future components on top of.
Previously you mentioned that "the user could set their circuits to 4 hops" but I think this is a hack of a solution and we can do better, by authenticating the Bridge.
I really disagree with you here :( I don't understand your point of view. Let's try and assume good faith.
Do you remember a couple of days ago, when I had to separate the tor processes for flash proxy and meek because the metrics were getting mixed up? That would have been *impossible* to do if there were hardcoded fingerprints out there in bundles. And how I recently put out a call for someone else to run the meek bridge? How is that transition supposed to work if changing the fingerprint means we suddenly and inexplicably break every existing client installation?
The answer surely isn't "make sure the bridge's private key never changes" and it isn't "anticipate every possible eventuality indefinitely into the future."
Can you explain what you don't like about four hops? To me it feels like the right thing. It wouldn't just be for meek, you know, but for all bridge circuits (including ordinary plain-vanilla bridges). When you're using a bridge you treat the first hop as unauthenticated and unencrypted, as if it were a SOCKS proxy or third-party VPN or any other circumvention proxy. You treat the first hop as not chosen by you, because it's not: even with BridgeDB you're just pasting in some bytes the web site chose for you. After your first circumvention hop, then you add your own three hops, notably including your own chosen guard. bridge → guard → middle → exit
Mike talked to me about this and made me understand that adding a fourth hop is not sufficient to prevent certain attacks. In other words, you need to TLS to be good, because Tor's current crypto doesn't have a per-hop MAC. Namely, https://trac.torproject.org/projects/tor/ticket/14937#comment:17 .
So we'll add fingerprint for the meek bridges after all. Upgrading or migrating bridges will require more care, basically the same as what exists for obfs3 etc. now (when you want to change a bridge, you need to keep the old one running for a while in order to give people time to upgrade, and in case of a major error like private key disclosure, just accept that many users will be cut off when you change the fingerprint).
David
On Wed, 17 Sep 2014 21:05:39 +0000, Tom Ritter wrote: ...
A horrible idea Isis and I came up with was standing up two or more tor servers with the same keys, on an anycast-ed IP address.
I don't think anycasted IPs work well with TCP, considering route flapping.
Andreas
On 2014-09-18 07:42, Andreas Krey wrote:
On Wed, 17 Sep 2014 21:05:39 +0000, Tom Ritter wrote: ...
A horrible idea Isis and I came up with was standing up two or more tor servers with the same keys, on an anycast-ed IP address.
I don't think anycasted IPs work well with TCP, considering route flapping.
Actually, it works quite fine and it is how quite a large amount of services are serving users around the world.
Route Flapping does not happen that often, at least not often enough that it impacts TCP.
Getting a provider to provide an anycasted prefix though, is likely more problematic than actually getting the code out there and running on a significant enough number of hosts that it matters.
Greets, Jeroen
On Mon, Sep 15, 2014 at 07:12:23PM -0700, David Fifield wrote:
The meek pluggable transport is currently running on the bridge I run, which also happens to be the backend bridge for flash proxy. I'd like to move it to a fast relay run by an experienced operator. I want to do this both to diffuse trust, so that I don't run all the infrastructure, and because my bridge is not especially fast and I'm not especially adept at performance tuning.
All you will need to do is run the meek-server program, add some lines to your torrc, and update the software when I ask you to. The more CPU, memory, and bandwidth you have, the better, though at this point usage is low enough that you won't even notice it if you are already running a fast relay. I think it will help if your bridge is located in the U.S., because that reduces latency from Google App Engine.
The meek-server plugin is basically just a little web server: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/meek-...
A couple of other requirements have shown themselves in helping set up a meek-server relay.
The first is that it has to be a 0.2.5.x version of tor. This is so that the ExtORPort option will be supported. The ExtORPort option is needed in order to collect statistics on pluggable transports (see #4773). One of the lines you will have to add to torrc is: ExtORPort auto If your tor does not support the option, you will see in the log: [warn] Failed to parse/validate config: Unknown option 'ExtORPort'. Failing.
The second requirement is that the relay needs to have either BridgeRelay or DirPort set. If neither of these options is set, the relay will not be a directory cache, and clients will not be able to bootstrap past "20%: Asking for networkstatus consensus." As I understand it, #12538 will make it so that every relay is a directory cache, but it is not committed yet.
I'll check back privately with the people who offered to run a relay and check if setting these options is okay.
David Fifield
-
Andreas Krey -
David Fifield -
Jeroen Massar -
Jon Camfield -
Tom Ritter -
Ximin Luo