Re: [tor-dev] Call for a big fast bridge (to be the meek backend)
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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Call for a big fast bridge (to be the meek backend)
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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Call for a big fast bridge (to be the meek backend)
On 15 September 2014 21:12, David Fifield da...@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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Call for a big fast bridge (to be the meek backend)
On Wed, Sep 17, 2014 at 09:05:39PM -0500, Tom Ritter wrote: On 15 September 2014 21:12, David Fifield da...@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-transportstart=2014-06-20end=2014-09-18transport=obfs3transport=meek#userstats-bridge-transport 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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Call for a big fast bridge (to be the meek backend)
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-server 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 -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Call for a big fast bridge (to be the meek backend)
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-server 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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
