Re: [tor-dev] Default bridges that are not publishing statistics

2017-06-05 Thread Damian Johnson 
> You asked your bridge for its server descriptor and it gave it to you.
>
> Did you try:
>  print 
> controller.get_extrainfo_descriptors("8B5F0BD647B3C4AF2C57F148FF6A1FB8B695B0AE")
>
> https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.DescriptorDownloader.get_extrainfo_descriptors

Hi teor, minor correction: you link to the DescriptorDownloader's method
but cite it as being part of Controller. This is why David didn't find it
later. The Controller can fetch some descriptor types. For instance...

https://stem.torproject.org/api/control.html#stem.control.Controller.get_server_descriptor
https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html#can-i-get-descriptors-from-the-tor-process

However, the Controller doesn't provide extrainfo descriptors. This is
for a couple reasons...

1. The control protocol only allows it to be retrieved by the descriptor
   digest rather than relay fingerprint, which is a pita...

   https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n562

2. This isn't what you want anyway. Fetching decriptors from the tor
   process only gets you the cached descriptors which isn't what folks
   generally want. So you're right that the DescriptorDownloader is
   the way to go.

> I don't know how to find a server that caches *all* bridge extra infos.
> Maybe you should try running these queries against the bridge authority?

Bridge descriptors are not public like normal descriptors. To work of
course the tor client can retrieve it if you know the bridge address
but beyond that I think the only thing available is the sanitized
descriptors from CollecTor...

https://collector.torproject.org/recent/bridge-descriptors/

> I think the documentation at:
> https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.Query
> is out of date: as far as I know, newer stem versions try fallback
> directories rather than authorities.

Unfortunately it doesn't. I had to revert that because they lack
extrainfo docs...

https://gitweb.torproject.org/stem.git/commit/?id=758f632

> Thanks again for your suggestions. Passing endpoints= doesn't seem to do
> anything.
> >>> import stem.descriptor.remote
> >>> BIFROEST = ("37.218.247.217", 80)
> >>> print 
> list(stem.descriptor.remote.get_server_descriptors("C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4",
>  endpoints=(BIFROEST,)))
> []

For what it's worth stem has authority information so this can also be
done with...

>>> import stem.descriptor.remote
>>> bifroest = stem.descriptor.remote.get_authorities()['Bifroest']
>>> print 
>>> list(stem.descriptor.remote.get_server_descriptors("C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4",
>>>  endpoints=((bifroest.address, bifroest.dir_port),)))

> It also doesn't work when trying the fingerprint of another default
> bridge, or of one I just got from bridge.torproject.org.

Alas, this is getting into areas I'm not too familiar with. To prevent
enumaration
I'm sure bridges are handled specially.

> Atagar might be able to help with the stem side of things.

Happy to help if there's any other stem questions.

Cheers! -Damian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Default bridges that are not publishing statistics

2017-06-05 Thread David Fifield 
On Mon, Jun 05, 2017 at 11:51:04PM +1000, teor wrote:
> 
> Can you get logs (and torrcs) from those bridges to confirm whether
> they think they are producing extra info descriptors?

I've asked the operator but not gotten a reply yet.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Default bridges that are not publishing statistics

2017-06-05 Thread teor 

> On 5 Jun 2017, at 15:53, David Fifield  wrote:
> 
> On Mon, Jun 05, 2017 at 03:15:08PM +1000, teor wrote:
>> 
>>> On 5 Jun 2017, at 15:06, David Fifield  wrote:
>>> 
>>> Calling get_extrainfo_descriptors from stem.descriptor.remote returns an
>>> empty list. (499D92E08769BFC0B7941C74031335B9EC9E9BAE is the new
>>> extra-info-digest I got from running just now.)
>>> import stem.descriptor.remote
>>> print list(stem.descriptor.remote.get_authorities())
>>> print 
>>> list(stem.descriptor.remote.get_server_descriptors("C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4"))
>>> print 
>>> list(stem.descriptor.remote.get_extrainfo_descriptors("499D92E08769BFC0B7941C74031335B9EC9E9BAE"))
>>> This is the output. Bifroest is in the get_authorities list, so I assume
>>> it's querying the bridge authority somewhere in there.
>>> ['maatuska', 'tor26', 'Bifroest', 'longclaw', 'dizum', 'gabelmoo', 
>>> 'moria1', 'dannenberg', 'Faravahar']
>>> []
>>> []
>> 
>> I think the documentation at:
>> https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.Query
>> is out of date: as far as I know, newer stem versions try fallback
>> directories rather than authorities.
>> 
>> Even if that's not the case, stem will choose a random authority for
>> you, which will (8/9 times) tell you that it knows nothing about any
>> bridge extra infos. (I don't think authorities cache bridge extra
>> infos.)
>> 
>> Try passing Bifroest's address and DirPort to the endpoints= argument to
>> get_extrainfo_descriptors():
>> https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.Query
> 
> Thanks again for your suggestions. Passing endpoints= doesn't seem to do
> anything.
>   >>> import stem.descriptor.remote
>   >>> BIFROEST = ("37.218.247.217", 80)
>   >>> print 
> list(stem.descriptor.remote.get_server_descriptors("C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4",
>  endpoints=(BIFROEST,)))
>   []
> It also doesn't work when trying the fingerprint of another default
> bridge, or of one I just got from bridge.torproject.org.
> ...

At this point, you are deep in the internals of stem, the control spec,
the dir spec, and their various implementations in Tor.

Atagar might be able to help with the stem side of things.
I'd encourage you to open a ticket for the bridges that aren't
reporting, and we'll try to reproduce and diagnose.

Can you get logs (and torrcs) from those bridges to confirm whether
they think they are producing extra info descriptors?

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org






signature.asc
Description: Message signed with OpenPGP
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev