Opened 5 years ago

Closed 5 years ago

#14937 closed defect (fixed)

Get meek working in Tor Circuit Display

Reported by: arthuredelstein Owned by: arthuredelstein
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-circuit-display, tbb-usability, tbb-4.5-alpha, TorBrowserTeam201503R, GeorgKoppen201503R
Cc: dcf, brade, mcs, gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (32)

comment:1 Changed 5 years ago by mcs

Cc: brade mcs added

Is this a tor problem, a meek PT problem, or a Torbutton problem? What are the possible solutions?

comment:2 Changed 5 years ago by dcf

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"

comment:3 Changed 5 years ago by arma

Yeah, you can't look up bridge details with getinfo ns/id/. ns is only for relays -- the client doesn't have any stanza like that for bridges.

What are you trying to learn here? I wonder if 'getinfo desc/id/' would do it for you?

comment:4 Changed 5 years ago by arma

I opened #14948 to help the next user of control-spec.txt not get confused here.

comment:5 Changed 5 years ago by arthuredelstein

Status: newneeds_information

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:

  1. When a stream is created, get the ID for the circuit it is using.
  2. Read a circut-status and extract the IDs for the nodes in the circuit we want to display.
  3. Look up current bridges and if a node matches, then mark it as a bridge.
  4. Get the IP address for each node using ns/id/* or the bridge conf line, if available.
  5. Request the country code for each IP address.
  6. 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.)

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?

Last edited 5 years ago by arthuredelstein (previous) (diff)

comment:6 Changed 5 years ago by arthuredelstein

I see now that arma's suggestion, getinfo desc/id/, gets me the IP address. I still haven't found how to identify the node as a meek bridge.

comment:7 Changed 5 years ago by arma

I wonder if we should expand "getinfo entry-guards" to e.g. annotate them by whether they are a bridge and if so which transport you're using to reach it.

comment:8 in reply to:  5 ; Changed 5 years ago by 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:

  1. When a stream is created, get the ID for the circuit it is using.
  2. Read a circut-status and extract the IDs for the nodes in the circuit we want to display.
  3. Look up current bridges and if a node matches, then mark it as a bridge.
  4. Get the IP address for each node using ns/id/* or the bridge conf line, if available.
  5. Request the country code for each IP address.
  6. 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.)

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.

comment:9 in reply to:  8 ; Changed 5 years ago by arthuredelstein

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:

  1. When a stream is created, get the ID for the circuit it is using.
  2. Read a circut-status and extract the IDs for the nodes in the circuit we want to display.
  3. Look up current bridges and if a node matches, then mark it as a bridge.
  4. Get the IP address for each node using ns/id/* or the bridge conf line, if available.
  5. Request the country code for each IP address.
  6. 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.)

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 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!

comment:10 in reply to:  9 ; Changed 5 years ago by dcf

Replying to arthuredelstein:

As I mentioned, I think #13882 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.

comment:11 in reply to:  10 ; Changed 5 years ago by arthuredelstein

Replying to dcf:

Replying to arthuredelstein:

As I mentioned, I think #13882 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.

comment:12 in reply to:  11 ; Changed 5 years ago by 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?

comment:13 in reply to:  12 ; Changed 5 years ago by 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.

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

comment:14 in reply to:  13 Changed 5 years ago by arthuredelstein

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?

comment:15 Changed 5 years ago by mikeperry

Keywords: tbb-4.5-alpha TorBrowserTeam201503 added

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.

comment:16 in reply to:  15 Changed 5 years ago by arthuredelstein

Replying 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.com 

That would also allow a clean solution for this ticket.

comment:17 Changed 5 years ago by mikeperry

Owner: changed from tbb-team to arthuredelstein
Status: needs_informationassigned

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).

comment:18 Changed 5 years ago by arthuredelstein

Cc: gk added
Keywords: TorBrowserTeam201503R added; TorBrowserTeam201503 removed
Status: assignedneeds_review

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

comment:19 Changed 5 years ago by gk

Keywords: GeorgKoppen201503R added

comment:20 in reply to:  18 ; Changed 5 years ago by gk

Replying 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

Arthur: Looks good to me. I just have two nits:

1) &#x202C;" ); <- superfluous whitespace after the quotation mark
2) match(/^\"?(.*?)\"?$|(.*)/)[1]; <- Why are you escaping the quotation mark? It is no special RegEx character. Regular expression are already complex beasts, could you just omit the backslashes? Unless I am missing something here could you change that in trimQuotes() as well?

David: How should we proceed here? Should we take Arthur's patch as a stopgap?

Last edited 5 years ago by gk (previous) (diff)

comment:21 in reply to:  20 Changed 5 years ago by arthuredelstein

Replying to gk:

Replying 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

Arthur: Looks good to me. I just have two nits:

1) &#x202C;" ); <- superfluous whitespace after the quotation mark

I've moved the final ); to the next line, in an attempt to make the parens more readable.

2) match(/^\"?(.*?)\"?$|(.*)/)[1]; <- Why are you escaping the quotation mark? It is no special RegEx character. Regular expression are already complex beasts, could you just omit the backslashes? Unless I am missing something here could you change that in trimQuotes() as well?

Oops, my mistake. I've change \" to " in that line and trimQuotes as well.

https://github.com/arthuredelstein/torbutton/commit/e6c0c70e06573a2f8f0577a322a4045fb5b5fcb6

Last edited 5 years ago by arthuredelstein (previous) (diff)

comment:22 in reply to:  20 ; Changed 5 years ago by dcf

Replying to gk:

David: How should we proceed here? Should we take Arthur's patch as a stopgap?

You can pull the fingerprints from the Globe links in the most recent meek costs email: https://lists.torproject.org/pipermail/tor-dev/2015-March/008427.html. I was going to make a bridge_prefs.js patch and everything, but it got delayed, so you can just snarf those fingerprints if you want.

Last edited 5 years ago by dcf (previous) (diff)

comment:23 in reply to:  22 Changed 5 years ago by arthuredelstein

Replying to dcf:

Replying to gk:

David: How should we proceed here? Should we take Arthur's patch as a stopgap?

You can pull the fingerprints from the Globe links in the most recent meek costs email: https://lists.torproject.org/pipermail/tor-dev/2015-March/008427.html. I was going to make a bridge_prefs.js patch and everything, but it got delayed, so you can just snarf those fingerprints if you want.

This patch, with a slight modification (below), also fixes display of flashproxy bridges. So I would suggest using this patch for now, and whenever David is ready, we can easily change over to comparing meek fingerprints directly.

https://github.com/arthuredelstein/torbutton/commit/e905373fa84b9b46092cce3089ea4283bf86e36d

comment:24 Changed 5 years ago by mikeperry

Do we need any additional changes to these patches to start using the fingerprints for meek? Or can we merge them *and* use meek fingerprints right now?

comment:25 in reply to:  24 Changed 5 years ago by arthuredelstein

Replying to mikeperry:

Do we need any additional changes to these patches to start using the fingerprints for meek? Or can we merge them *and* use meek fingerprints right now?

A very minor additional change will be needed if we switch to using meek fingerprints. It just depends on how they appear in the bridge conf line.

comment:26 in reply to:  22 Changed 5 years ago by arthuredelstein

Replying to dcf:

Replying to gk:

David: How should we proceed here? Should we take Arthur's patch as a stopgap?

You can pull the fingerprints from the Globe links in the most recent meek costs email: https://lists.torproject.org/pipermail/tor-dev/2015-March/008427.html. I was going to make a bridge_prefs.js patch and everything, but it got delayed, so you can just snarf those fingerprints if you want.

I tried, naively, inserting fingerprints into the meek lines in bridge_prefs.js as follows:

pref("extensions.torlauncher.default_bridge.meek-google.1", "meek 0.0.2.0:1 88F745840F47CE0C6A4FE61D827950B06F9E4534 url=https://meek-reflect.appspot.com/ front=www.google.com");
pref("extensions.torlauncher.default_bridge.meek-amazon.1", "meek 0.0.2.0:2 3FD131B74D9A96190B1EE5D31E91757FADA1A4F3 url=https://d2zfqthxsdq309.cloudfront.net/ front=a0.awsstatic.com");
pref("extensions.torlauncher.default_bridge.meek-azure.1", "meek 0.0.2.0:3 AA033EEB61601B2B7312D89B62AAA23DC3ED8A34 url=https://az668014.vo.msecnd.net/ front=ajax.aspnetcdn.com");

But when I then tried setting the bridge to meek in Tor Browser, it displayed an error like "Identity mismatch." So either I'm using the wrong syntax, or meek is not yet setup to include the fingerprints in the bridge lines. Any advice, David? Thanks.

comment:27 Changed 5 years ago by dcf

Oh, hrm, the Globe fingerprints are hashed fingerprints because they are bridge relays.

meek-google: !46d4a71197b8fa515a826c6b017c522fe264655b
meek-amazon: !4ee0cc769eb4b15a872f742ede27d298a59dcade
meek-azure: !a2c13b7dfcab1cbf3a884b6eb99a98067ab6ef44

I didn't do anything special to get these, only watched the terminal as I connected to them (tor -f torrc in the meek-client directory):

Mar 21 14:28:18.000 [notice] Learned fingerprint 46D4A71197B8FA515A826C6B017C522FE264655B for bridge 0.0.2.0:1 (with transport 'meek').
Mar 21 14:28:16.000 [notice] Learned fingerprint 4EE0CC769EB4B15A872F742EDE27D298A59DCADE for bridge 0.0.2.0:2 (with transport 'meek').
Mar 21 14:28:13.000 [notice] Learned fingerprint A2C13B7DFCAB1CBF3A884B6EB99A98067AB6EF44 for bridge 0.0.2.0:3 (with transport 'meek').

Here's the fingerprint hashing algorithm if you want to check that they correspond to what was posted earlier.

>>> import hashlib
>>> hashlib.sha1("46D4A71197B8FA515A826C6B017C522FE264655B".decode("hex")).digest().encode("hex")
'88f745840f47ce0c6a4fe61d827950b06f9e4534'
>>> hashlib.sha1("4EE0CC769EB4B15A872F742EDE27D298A59DCADE".decode("hex")).digest().encode("hex")
'3fd131b74d9a96190b1ee5d31e91757fada1a4f3'
>>> hashlib.sha1("A2C13B7DFCAB1CBF3A884B6EB99A98067AB6EF44".decode("hex")).digest().encode("hex")
'aa033eeb61601b2b7312d89b62aaa23dc3ed8a34'

comment:28 in reply to:  27 ; Changed 5 years ago by arthuredelstein

Replying to dcf:

Oh, hrm, the Globe fingerprints are hashed fingerprints because they are bridge relays.

meek-google: !46d4a71197b8fa515a826c6b017c522fe264655b
meek-amazon: !4ee0cc769eb4b15a872f742ede27d298a59dcade
meek-azure: !a2c13b7dfcab1cbf3a884b6eb99a98067ab6ef44

I didn't do anything special to get these, only watched the terminal as I connected to them (tor -f torrc in the meek-client directory):

Mar 21 14:28:18.000 [notice] Learned fingerprint 46D4A71197B8FA515A826C6B017C522FE264655B for bridge 0.0.2.0:1 (with transport 'meek').
Mar 21 14:28:16.000 [notice] Learned fingerprint 4EE0CC769EB4B15A872F742EDE27D298A59DCADE for bridge 0.0.2.0:2 (with transport 'meek').
Mar 21 14:28:13.000 [notice] Learned fingerprint A2C13B7DFCAB1CBF3A884B6EB99A98067AB6EF44 for bridge 0.0.2.0:3 (with transport 'meek').

Here's the fingerprint hashing algorithm if you want to check that they correspond to what was posted earlier.

>>> import hashlib
>>> hashlib.sha1("46D4A71197B8FA515A826C6B017C522FE264655B".decode("hex")).digest().encode("hex")
'88f745840f47ce0c6a4fe61d827950b06f9e4534'
>>> hashlib.sha1("4EE0CC769EB4B15A872F742EDE27D298A59DCADE".decode("hex")).digest().encode("hex")
'3fd131b74d9a96190b1ee5d31e91757fada1a4f3'
>>> hashlib.sha1("A2C13B7DFCAB1CBF3A884B6EB99A98067AB6EF44".decode("hex")).digest().encode("hex")
'aa033eeb61601b2b7312d89b62aaa23dc3ed8a34'

Thanks, David! That fixes it. Are there a similar set of fingerprints we can use for flashproxy?

comment:30 in reply to:  28 ; Changed 5 years ago by dcf

Replying to arthuredelstein:

Thanks, David! That fixes it. Are there a similar set of fingerprints we can use for flashproxy?

You get get it from the sample torrc file.
https://gitweb.torproject.org/flashproxy.git/tree/torrc?id=1.7

Bridge flashproxy 0.0.1.0:1 4D6C0DF6DEC9398A4DEF07084F3CD395A96DD2AD
Bridge flashproxy 0.0.1.0:2 4D6C0DF6DEC9398A4DEF07084F3CD395A96DD2AD
Bridge flashproxy 0.0.1.0:3 4D6C0DF6DEC9398A4DEF07084F3CD395A96DD2AD
Bridge flashproxy 0.0.1.0:4 4D6C0DF6DEC9398A4DEF07084F3CD395A96DD2AD
Bridge flashproxy 0.0.1.0:5 4D6C0DF6DEC9398A4DEF07084F3CD395A96DD2AD

There are multiple virtual bridges in front of the actual bridge because of how flash proxy works.

comment:31 in reply to:  30 Changed 5 years ago by arthuredelstein

Replying to dcf:

Replying to arthuredelstein:

Thanks, David! That fixes it. Are there a similar set of fingerprints we can use for flashproxy?

You get get it from the sample torrc file.
https://gitweb.torproject.org/flashproxy.git/tree/torrc?id=1.7

Bridge flashproxy 0.0.1.0:1 4D6C0DF6DEC9398A4DEF07084F3CD395A96DD2AD
Bridge flashproxy 0.0.1.0:2 4D6C0DF6DEC9398A4DEF07084F3CD395A96DD2AD
Bridge flashproxy 0.0.1.0:3 4D6C0DF6DEC9398A4DEF07084F3CD395A96DD2AD
Bridge flashproxy 0.0.1.0:4 4D6C0DF6DEC9398A4DEF07084F3CD395A96DD2AD
Bridge flashproxy 0.0.1.0:5 4D6C0DF6DEC9398A4DEF07084F3CD395A96DD2AD

There are multiple virtual bridges in front of the actual bridge because of how flash proxy works.

Thanks again!

OK, here are my latest patches for this ticket, for review:
https://github.com/arthuredelstein/tor-browser-bundle/commit/bb029bff85d1973a08340404be50f7ceee83f59e
https://github.com/arthuredelstein/torbutton/commit/c6321626cf04db74a8c08af19331c686757adc85

The torbutton patch only works if we also apply the tor-browser-bundle patch.

comment:32 Changed 5 years ago by gk

Resolution: fixed
Status: needs_reviewclosed

Thanks, this looks good now. Merged with commit 5ac0bb12aaceb954d124e1e65cd47c37e28fcaa7 into torbutton and commit 5a9179b065e3015381fc6ea5bf4dccb0b04d3dd6 into tor-browser-bunde.

Note: See TracTickets for help on using tickets.