Been having a devil fo a time keeping my bridge up this week. One question: With the bridge up & running, & the map showing it connecting to circuits, why is onionoo reporting "running":false, ? Should I worry about this discrepancy? Thanks, eliaz
On 9/2/13 3:52 PM, eliaz wrote:
Been having a devil fo a time keeping my bridge up this week. One question: With the bridge up & running, & the map showing it connecting to circuits, why is onionoo reporting "running":false, ? Should I worry about this discrepancy? Thanks, eliaz
Can you post the hashed fingerprint here? Happy to take a look. Best, Karsten
On 9/2/2013 9:58 AM, Karsten Loesing wrote:
On 9/2/13 3:52 PM, eliaz wrote:
Been having a devil fo a time keeping my bridge up this week. One question: With the bridge up & running, & the map showing it connecting to circuits, why is onionoo reporting "running":false, ? Should I worry about this discrepancy? Thanks, eliaz
Can you post the hashed fingerprint here? Happy to take a look.
B68A205B1C4D8AACE4AE83CF15B31FCD140373F5 But don't knock yourself out tracking it. onionoo is showing true now. Usually it's quite fast, and part of the reason for the recent slowness may have been that I was having trouble with port forwarding (local issues, not worth recounting here) & was loading & unloading tor to fix it.
On 9/2/13 5:52 PM, eliaz wrote:
On 9/2/2013 9:58 AM, Karsten Loesing wrote:
On 9/2/13 3:52 PM, eliaz wrote:
Been having a devil fo a time keeping my bridge up this week. One question: With the bridge up & running, & the map showing it connecting to circuits, why is onionoo reporting "running":false, ? Should I worry about this discrepancy? Thanks, eliaz
Can you post the hashed fingerprint here? Happy to take a look.
B68A205B1C4D8AACE4AE83CF15B31FCD140373F5
But don't knock yourself out tracking it. onionoo is showing true now. Usually it's quite fast, and part of the reason for the recent slowness may have been that I was having trouble with port forwarding (local issues, not worth recounting here) & was loading & unloading tor to fix it.
I just looked at the descriptors from the last three days, and that bridge was first listed as running yesterday at 12:37 UTC. It may take up to two hours for Onionoo to update. So, it should have been listed as running after 14:30 UTC. Best, Karsten
The usual deal is to just wait a bit more, until your bridge gets voted into the last consensus. The "running: true/false" field in Onionoo simply indicates whether your bridge/relay descriptor is listed in the last consensus (which is published every hour, and includes a list of relays and bridges which the network authorities agreed on being valid / etc. for client usage.) It usually takes some time (e.g. more than an hour) even after your bridge/relay is successfully running. At least that's my (perhaps oversimplifying) take. Perhaps you're using it yourself, but one of the ways to probe Onionoo in a user-friendly way is the new Globe tool [1]. It includes bridges as well as relays. [1]: http://globe.rndm.de/ -- Kostas. 0x0e5dce45 @ pgp.mit.edu
On 09/02/2013 10:02 AM, Kostas Jakeliunas wrote: [snip]
Perhaps you're using it yourself, but one of the ways to probe Onionoo in a user-friendly way is the new Globe tool [1]. It includes bridges as well as relays.
Having this tool on an unencrypted HTTP site doesn't seem safe to me. Anybody can sniff the bridge IP addresses that users submit for reporting.
On 9/2/2013 11:59 AM, Steve Snyder wrote:
On 09/02/2013 10:02 AM, Kostas Jakeliunas wrote:
Having this tool on an unencrypted HTTP site doesn't seem safe to me. Anybody can sniff the bridge IP addresses that users submit for reporting.
It may be different if someone compiles the program locally, but AFAICT no secrets are being divulged from the globe web page. From the page the details of no bridge can be found without knowing the name of the bridge in the first place; and if someone knows that she also know the other details. One doesn't have to go to the page to do a brute force attack. At the same time globe is useful in helping lower-level bridge operators such as myself get a better sense of what the information windows in the browser bundle are actually telling us. If I'm wrong in any of the above, please do correct me. eliaz gpg: 0x63D01EC6
On 9/3/13 5:59 AM, eliaz wrote:
On 9/2/2013 11:59 AM, Steve Snyder wrote:
On 09/02/2013 10:02 AM, Kostas Jakeliunas wrote:
Having this tool on an unencrypted HTTP site doesn't seem safe to me. Anybody can sniff the bridge IP addresses that users submit for reporting.
It may be different if someone compiles the program locally, but AFAICT no secrets are being divulged from the globe web page. From the page the details of no bridge can be found without knowing the name of the bridge in the first place; and if someone knows that she also know the other details. One doesn't have to go to the page to do a brute force attack.
Agreed, Globe doesn't divulge any secrets, mostly because Onionoo doesn't contain any secrets. All bridge data that Onionoo has is sanitized and doesn't contain sensitive information anymore.
At the same time globe is useful in helping lower-level bridge operators such as myself get a better sense of what the information windows in the browser bundle are actually telling us.
I agree.
If I'm wrong in any of the above, please do correct me.
No need to. Thanks for running a bridge! Best, Karsten
On 9/2/13 5:59 PM, Steve Snyder wrote:
On 09/02/2013 10:02 AM, Kostas Jakeliunas wrote: [snip]
Perhaps you're using it yourself, but one of the ways to probe Onionoo in a user-friendly way is the new Globe tool [1]. It includes bridges as well as relays.
Having this tool on an unencrypted HTTP site doesn't seem safe to me. Anybody can sniff the bridge IP addresses that users submit for reporting.
In general, I agree that Globe should be provided on HTTPS. But regardless, you don't have to be concerned about IP addresses being sent over an unencrypted link. Globe is just the JavaScript thing that you load in your browser and that then makes all its data requests to Onionoo over HTTPS. Here's Firefox's console output of searching for gabelmoo by IP address: [10:14:41.726] GET https://onionoo.torproject.org/details?limit=50&search=212.112.245.170&field... [HTTP/1.1 200 OK 569ms] [10:14:46.040] GET https://onionoo.torproject.org/details?lookup=16EF359C2FBF50FC08CF9A95717BE3... [HTTP/1.1 200 OK 141ms] [10:14:46.041] GET http://globe.rndm.de/img/ajax-loader.gif [HTTP/1.1 200 OK 284ms] [10:14:46.283] GET https://onionoo.torproject.org/weights?lookup=16EF359C2FBF50FC08CF9A95717BE3... [HTTP/1.1 200 OK 284ms] [10:14:46.285] GET https://onionoo.torproject.org/bandwidth?lookup=16EF359C2FBF50FC08CF9A95717B... [HTTP/1.1 200 OK 399ms] Best, Karsten
On 9/2/2013 10:02 AM, Kostas Jakeliunas wrote:
The usual deal is to just wait a bit more, until your bridge gets voted into the last consensus. The "running: true/false" field in Onionoo simply indicates whether your bridge/relay descriptor is listed in the last consensus (which is published every hour, and includes a list of relays and bridges which the network authorities agreed on being valid / etc. for client usage.) It usually takes some time (e.g. more than an hour) even after your bridge/relay is successfully running. At least that's my (perhaps oversimplifying) take.
Thanks, you're right.
Perhaps you're using it yourself, but one of the ways to probe Onionoo in a user-friendly way is the new Globe tool [1]. It includes bridges as well as relays.
Thanks for the pointer, globe is interesting. What is the latency of globe (and the browser bundle map, for that matter)? I've assumed that the circuits shown on the map are high-consensus, but I haven't been able to correlate globe's top 10 with relays shown on the map. Maybe I'm being impatient here too? eliaz gpg: 0x63D01EC6
On 9/2/13 6:20 PM, eliaz wrote:
On 9/2/2013 10:02 AM, Kostas Jakeliunas wrote:
Perhaps you're using it yourself, but one of the ways to probe Onionoo in a user-friendly way is the new Globe tool [1]. It includes bridges as well as relays.
Thanks for the pointer, globe is interesting. What is the latency of globe (and the browser bundle map, for that matter)? I've assumed that the circuits shown on the map are high-consensus, but I haven't been able to correlate globe's top 10 with relays shown on the map. Maybe I'm being impatient here too?
Globe's latency is the same as Onionoo's, so up to two hours. The browser bundle map uses your local tor's network information which may be up to two hours out of date, too. So, similar latencies. So, why are the two lists different. Hmm... For one, I just found that Globe lists the top 10 relays in random order. I opened a ticket for that: https://github.com/makepanic/globe/issues/25 For another one, I found that non-running relays are listed by Globe, too. Opened another ticket for that: https://github.com/makepanic/globe/issues/26 But I can't currently say what criteria the browser bundle map uses to list top 10 relays. Is it really by consensus weight and not by advertised bandwidth? Best, Karsten
participants (4)
-
eliaz -
Karsten Loesing -
Kostas Jakeliunas -
Steve Snyder