Get meek working in Tor Circuit Display
It's difficult to recognize a meek bridge in a Tor circuit description from the control port. But we need to do this in order to show the meek bridge in the tor circuit display.
Activity
I don't think this is about meek. I think it's about bridges that aren't in the consensus, or something. I get the same "Unknown country (IP unknown)" when using a vanilla bridge from https://bridges.torproject.org/.
If I tcpdump the control port while using meek, I see stuff like: ("starman" is the meek-azure bridge)
250 OK 250+circuit-status= ... 174 BUILT $A2C13B7DFCAB1CBF3A884B6EB99A98067AB6EF44~starman,$0AABE1DB1FE4CB90E81BE9ED1124A5044ECD4A26~SZCZYBELSKI0000,$49952F1CF9A50637D15BBC848055EFD75CF62EEF~BellumAmericana BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2015-02-19T01:44:20.169994 SOCKS_USERNAME="www.ietf.org" SOCKS_PASSWORD="0" ... getinfo ns/id/A2C13B7DFCAB1CBF3A884B6EB99A98067AB6EF44 552 Unrecognized key "ns/id/A2C13B7DFCAB1CBF3A884B6EB99A98067AB6EF44" ... getinfo ns/id/0AABE1DB1FE4CB90E81BE9ED1124A5044ECD4A26 250+ns/id/0AABE1DB1FE4CB90E81BE9ED1124A5044ECD4A26= r SZCZYBELSKI0000 Cqvh2x/ky5DoG+ntESSlBE7NSiY Ucl4bz8JbN73P8hw2lgofTq0xk0 2015-02-18 10:17:19 5.196.20.85 9001 9030 ...With a bridge from BridgeDB, I get the same "Unrecognized key" error:
224 BUILT $FB812B43099590F6E561886D8E41D30B605846BC~WonderLANd,$FEDE31337E4E19E06B97D282F08B0A0E8B9C5526~csUniHB,$49952F1CF9A50637D15BBC848055EFD75CF62EEF~BellumAmericana BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2015-02-19T01:49:33.059979 SOCKS_USERNAME="trac.torproject.org" SOCKS_PASSWORD="0" ... getinfo ns/id/FB812B43099590F6E561886D8E41D30B605846BC 552 Unrecognized key "ns/id/FB812B43099590F6E561886D8E41D30B605846BC"
I opened #14948 (moved) to help the next user of control-spec.txt not get confused here.
Thanks everyone for your help here. Sorry I wasn't very clear about my problem in the ticket description.
For background, the tor circuit display works roughly as follows:
- When a stream is created, get the ID for the circuit it is using.
- Read a circut-status and extract the IDs for the nodes in the circuit we want to display.
- Look up current bridges and if a node matches, then mark it as a bridge.
- Get the IP address for each node using ns/id/* or the bridge conf line, if available.
- Request the country code for each IP address.
- Display the country and IP address for each node in the circuit, or the country and bridge type if it's a bridge.
(I hope I've fixed the problem David observed in the vanilla bridges in my patch for #13882 (moved).)
For meek, my problem is that I have neither an IP address nor a node ID. The bridge conf line provides two URLs (meek server and front), but the circuit-status shows a node ID for the meek bridge instead (such as
$A2C13B7DFCAB1CBF3A884B6EB99A98067AB6EF44~starman). So is there a general way to identify this node ID as meek, and perhaps find a corresponding IP address?Trac:
Status: new to needs_informationReplying to arthuredelstein:
Thanks everyone for your help here. Sorry I wasn't very clear about my problem in the ticket description.
For background, the tor circuit display works roughly as follows:
- When a stream is created, get the ID for the circuit it is using.
- Read a circut-status and extract the IDs for the nodes in the circuit we want to display.
- Look up current bridges and if a node matches, then mark it as a bridge.
- Get the IP address for each node using ns/id/* or the bridge conf line, if available.
- Request the country code for each IP address.
- Display the country and IP address for each node in the circuit, or the country and bridge type if it's a bridge.
(I hope I've fixed the problem David observed in the vanilla bridges in my patch for #13882 (moved).)
For meek, my problem is that I have neither an IP address nor a node ID. The bridge conf line provides two URLs (meek server and front), but the circuit-status shows a node ID for the meek bridge instead (such as
$A2C13B7DFCAB1CBF3A884B6EB99A98067AB6EF44~starman). So is there a general way to identify this node ID as meek, and perhaps find a corresponding IP address?meek isn't doing anything differently in this respect than, say, obfs3. How does the circuit display show obfs3 bridges (not the default ones, but some from https://bridges.torproject.org/bridges?transport=obfs3)? I tried it just now and I got the same "Unknown country (IP unknown)". I think this problem exists for pluggable transports in general.
Don't worry about the url and front. Those are transparent from Tor's point of view. It might be nice to surface them in the UI someday, but as far as Tor's concerned they're just an exotic way of reaching the bridge. They don't affect the Tor-layer circuit.
Replying to dcf:
Replying to arthuredelstein:
Thanks everyone for your help here. Sorry I wasn't very clear about my problem in the ticket description.
For background, the tor circuit display works roughly as follows:
- When a stream is created, get the ID for the circuit it is using.
- Read a circut-status and extract the IDs for the nodes in the circuit we want to display.
- Look up current bridges and if a node matches, then mark it as a bridge.
- Get the IP address for each node using ns/id/* or the bridge conf line, if available.
- Request the country code for each IP address.
- Display the country and IP address for each node in the circuit, or the country and bridge type if it's a bridge.
(I hope I've fixed the problem David observed in the vanilla bridges in my patch for #13882 (moved).)
For meek, my problem is that I have neither an IP address nor a node ID. The bridge conf line provides two URLs (meek server and front), but the circuit-status shows a node ID for the meek bridge instead (such as
$A2C13B7DFCAB1CBF3A884B6EB99A98067AB6EF44~starman). So is there a general way to identify this node ID as meek, and perhaps find a corresponding IP address?meek isn't doing anything differently in this respect than, say, obfs3. How does the circuit display show obfs3 bridges (not the default ones, but some from https://bridges.torproject.org/bridges?transport=obfs3)? I tried it just now and I got the same "Unknown country (IP unknown)". I think this problem exists for pluggable transports in general.
As I mentioned, I think #13882 (moved) fixed this problem for most pluggable transports, including obfs3. To test it, you'll need to build the master branch of torbutton.git and install the xpi into Tor Browser. I just tested bridges from https://bridges.torproject.org/bridges?transport=obfs3 and I get, for example "Sweden (Bridge: obfs3)". Most transports, including obfs3, have the IP address and fingerprint in the bridge conf line, so I'm just using that (in the latest patch). So my question is how to identify an entry-node fingerprint as a meek node, given that I don't have a fingerprint and IP from the bridge conf. Somehow, the meek code must be converting url/front into a fingerprint, correct?
Thanks for your help, David!
Replying to arthuredelstein:
As I mentioned, I think #13882 (moved) fixed this problem for most pluggable transports, including obfs3. To test it, you'll need to build the master branch of torbutton.git and install the xpi into Tor Browser. I just tested bridges from https://bridges.torproject.org/bridges?transport=obfs3 and I get, for example "Sweden (Bridge: obfs3)". Most transports, including obfs3, have the IP address and fingerprint in the bridge conf line, so I'm just using that (in the latest patch). So my question is how to identify an entry-node fingerprint as a meek node, given that I don't have a fingerprint and IP from the bridge conf. Somehow, the meek code must be converting url/front into a fingerprint, correct?
It's tor that learns the fingerprint (and true IP) when it connects to the bridge. meek-client is pretty ignorant of the Tor protocol flowing through it. The url/front is just used to set up the "transport layer" that Tor uses to connect to the bridge. Once tor has a channel to the bridge, it finds out the IP and fingerprint somehow. (NETINFO cell maybe? I dunno.)
So what you do is get the fingerprint from the control port, then find a bridge line with a matching fingerprint, and peek at the transport name in the bridge line? And it doesn't work for the meek bridge lines because they don't have a fingerprint?
I don't know a good way to solve it. Maybe what armadev said in comment:7. It seems like the control port ought to know what transport you are using.
Maybe as a special-case workaround, you can say, if there's only one bridge line configured, then you can match it even if it doesn't have a fingerprint.
Replying to dcf:
Replying to arthuredelstein:
As I mentioned, I think #13882 (moved) fixed this problem for most pluggable transports, including obfs3. To test it, you'll need to build the master branch of torbutton.git and install the xpi into Tor Browser. I just tested bridges from https://bridges.torproject.org/bridges?transport=obfs3 and I get, for example "Sweden (Bridge: obfs3)". Most transports, including obfs3, have the IP address and fingerprint in the bridge conf line, so I'm just using that (in the latest patch). So my question is how to identify an entry-node fingerprint as a meek node, given that I don't have a fingerprint and IP from the bridge conf. Somehow, the meek code must be converting url/front into a fingerprint, correct?
It's tor that learns the fingerprint (and true IP) when it connects to the bridge. meek-client is pretty ignorant of the Tor protocol flowing through it. The url/front is just used to set up the "transport layer" that Tor uses to connect to the bridge. Once tor has a channel to the bridge, it finds out the IP and fingerprint somehow. (NETINFO cell maybe? I dunno.)
So what you do is get the fingerprint from the control port, then find a bridge line with a matching fingerprint, and peek at the transport name in the bridge line? And it doesn't work for the meek bridge lines because they don't have a fingerprint?
Right.
I don't know a good way to solve it. Maybe what armadev said in comment:7. It seems like the control port ought to know what transport you are using.
Probably displaying the full bridge line would be ideal for meek, although for most other transports, most of that information would be redundant.
Maybe as a special-case workaround, you can say, if there's only one bridge line configured, then you can match it even if it doesn't have a fingerprint.
I could do that, but it seems like it might be a little error-prone, in the case where multiple circuits are hanging around.
Replying to arthuredelstein:
Replying to dcf:
Is my understanding correct, that for each meek target bundled with Tor Browser, there is a single meek server with a unique, unchanging fingerprint? In that case, I could simply hard-code a list of these fingerprints. Does that make sense to you?
It happens to currently be the case that each meek backend has a dedicated bridge with a unique fingerprint, but please do not rely on that. We have had to change them before—for example, all of meek-google, meek-amazon, and meek-azure used to run over a single bridge, before we sitched them out to separate bridges—and we wouldn't have had to do that without a lengthy deprecation period if we had hardcoded the single bridge's fingerprint in people's bundles.
It's like what happened to some of the default obfs2 bridges a while back, when they were affected by Heartbleed. The operator generated new keys, but had to keep the old bridges running with the old keys for a long time, because there was no way to update clients with the old fingerprint hardcoded. With meek we have an extra layer of virtualization because the bridge line is not tightly coupled to the backing bridge.
The first bridge hop (even for vanilla bridges) is really an untrusted, unauthenticated hop. That's the reason I think we should use four hops for bridge circuits. The first hop is a leap of faith, and then you choose and authenticate your next three hops. Check this old thread: https://lists.torproject.org/pipermail/tor-dev/2014-September/007511.html
Replying to dcf:
Replying to arthuredelstein:
Replying to dcf:
Is my understanding correct, that for each meek target bundled with Tor Browser, there is a single meek server with a unique, unchanging fingerprint? In that case, I could simply hard-code a list of these fingerprints. Does that make sense to you?
It happens to currently be the case that each meek backend has a dedicated bridge with a unique fingerprint, but please do not rely on that. We have had to change them before—for example, all of meek-google, meek-amazon, and meek-azure used to run over a single bridge, before we sitched them out to separate bridges—and we wouldn't have had to do that without a lengthy deprecation period if we had hardcoded the single bridge's fingerprint in people's bundles.
What I had in mind is strictly for display in the UI, and wouldn't affect the ability to connect to servers with new fingerprints. On the other hand, it will be definitely much better to implement something like comment:7. For now I will leave this ticket unfixed until we find a robust solution.
It's like what happened to some of the default obfs2 bridges a while back, when they were affected by Heartbleed. The operator generated new keys, but had to keep the old bridges running with the old keys for a long time, because there was no way to update clients with the old fingerprint hardcoded. With meek we have an extra layer of virtualization because the bridge line is not tightly coupled to the backing bridge.
The first bridge hop (even for vanilla bridges) is really an untrusted, unauthenticated hop. That's the reason I think we should use four hops for bridge circuits. The first hop is a leap of faith, and then you choose and authenticate your next three hops. Check this old thread: https://lists.torproject.org/pipermail/tor-dev/2014-September/007511.html
It's an interesting point. Is there a ticket for this?
dcf - I have actually been meaning to ask you for fingerprints for the meek bridges. I really think this first hop should be authenticated, despite the inconvenience, due to the seriousness of the attacks involved. The fact that we have an updater should enable us to update fingerprints more rapidly without a long deprecation period. We can discuss this at the dev meeting, if you're there.
Trac:
Keywords: N/A deleted, tbb-4.5-alpha, TorBrowserTeam201503 addedReplying to mikeperry:
dcf - I have actually been meaning to ask you for fingerprints for the meek bridges. I really think this first hop should be authenticated, despite the inconvenience, due to the seriousness of the attacks involved. The fact that we have an updater should enable us to update fingerprints more rapidly without a long deprecation period. We can discuss this at the dev meeting, if you're there.
It would be cool to have the fingerprint included in the bridge configuration line. For example,
meek 0.0.2.0:1 fingerprint=0123456789ABCDEF url=https://meek-reflect.appspot.com/ front=www.google.comThat would also allow a clean solution for this ticket.
-
So I spoke with dcf, and explained that we want to include the node fingerprint due to tagging attacks - https://lists.torproject.org/pipermail/tor-dev/2012-March/003347.html. The node fingerprint is the only thing that currently authenticates the link to the first hop, and without it an adversary that can intercept the connection from the CDN to the bridge (or that can MITM TLS from the client to the domain front) is able to unwrap the Tor TLS and perform tagging. Due to the use of AES-CTR without a per-hop MAC, four hops would not mitigate this attack.
dcf seemed amenable to providing meek fingerprints because of this. We also discussed how we might update if there is a need to change. Basically, we would just spin up the meek front on a new IP+port (though this may become tricky for CDNs that only allow port 443).
Trac:
Status: needs_information to assigned
Owner: tbb-team to arthuredelstein Here's my current solution for this ticket. It's not ideal, because it would be nicer to directly match the meek fingerprint to the entry node in the circuit we are examining. But it works, so I would suggest using this patch until we include the meek fingerprints in TBB directly.
https://github.com/arthuredelstein/torbutton/commit/7653f8e44e7800915563b622c4a5ef6931db4d23
Trac:
Keywords: TorBrowserTeam201503 deleted, TorBrowserTeam201503R added
Status: assigned to needs_review
Cc: dcf, brade, mcs to dcf, brade, mcs, gk
