[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #11999 [Ooni]: Deploy the ooni-backend bouncer on m-lab
#11999: Deploy the ooni-backend bouncer on m-lab
-----------------------------+---------------------
Reporter: cypherpunks | Owner: hellais
Type: defect | Status: closed
Priority: normal | Milestone:
Component: Ooni | Version:
Resolution: fixed | Keywords:
Actual Points: | Parent ID:
Points: |
-----------------------------+---------------------
Changes (by hellais):
* status: new => closed
* resolution: => fixed
Old description:
> This issue was automatically migrated from github issue
> https://github.com/TheTorProject/ooni-probe/issues/182.
>
> In order for ooni-probes to discover collectors and test helper addresses
> ooni-probe uses a bouncer.
>
> The protocol for such system is specified here:
> https://github.com/TheTorProject/ooni-
> spec/blob/master/oonib.md#40-bouncer.
>
> Our idea for deploying this on m-lab is to have one unique Tor Hidden
> Service private key that is shared by all the m-lab instances running
> ooni-backend. This will provide load balancing given by the Tor Hidden
> Service protocol.
>
> It also allows us to have one unique .onion address that we can bake into
> the ooni-probe that will allow it to securely discover new collector and
> test helper addresses.
>
> From speaking with @stephen-soltesz and @meredithmeredith it appears that
> the m-lab platform currently lacks the ability to provision the machines
> with some private key material.
>
> This is a problem for us since to securely bootstrap the system we need
> to have a persistent address. This means that even if we were to generate
> the tor hidden service private key on the machines we would then not be
> able to distribute this address to the probes (because it would be
> changing over time).
>
> The ideal solution to this problem is to have support for provisioning of
> private key material to the ooni-probes.
>
> A temporary fix to this would be running the bouncer on a different
> system that is not m-lab and have this system fetch the list of
> collectors and test helpers via m-lab NS.
New description:
This issue was automatically migrated from github issue
https://github.com/TheTorProject/ooni-probe/issues/182.
In order for ooni-probes to discover collectors and test helper addresses
ooni-probe uses a bouncer.
The protocol for such system is specified here:
https://github.com/TheTorProject/ooni-
spec/blob/master/oonib.md#40-bouncer.
Our idea for deploying this on m-lab is to have one unique Tor Hidden
Service private key that is shared by all the m-lab instances running
ooni-backend. This will provide load balancing given by the Tor Hidden
Service protocol.
It also allows us to have one unique .onion address that we can bake into
the ooni-probe that will allow it to securely discover new collector and
test helper addresses.
From speaking with @stephen-soltesz and @meredithmeredith it appears that
the m-lab platform currently lacks the ability to provision the machines
with some private key material.
This is a problem for us since to securely bootstrap the system we need to
have a persistent address. This means that even if we were to generate the
tor hidden service private key on the machines we would then not be able
to distribute this address to the probes (because it would be changing
over time).
The ideal solution to this problem is to have support for provisioning of
private key material to the ooni-probes.
A temporary fix to this would be running the bouncer on a different system
that is not m-lab and have this system fetch the list of collectors and
test helpers via m-lab NS.
--
Comment:
This is no longer needed as the bouncer will be deployed on a machine run
by ooni.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11999#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs