Good evening,
My name is Francisco Silva and, together with Professor Nuno Santos and Professor Diogo Barradas, am part of a research team [1] within the Distributed Systems Group at INESC-ID Lisbon [2]/IST [3]. Our research focuses on _systems security and privacy._
We are currently developing a new Tor Pluggable Transport called TorCloak. TorCloak's basic mechanism is to conceale Tor traffic on the video streams of WebRTC-based video conferencing services.
We are now coming to a stage on our project in which we are discussing solutions to disseminate our bridges. In the attached file we present a small draft of our proposed solution. This solution is geared towards leveraging the bridge distribution infrastructure already made available by the Tor project and make the process of establishing a bridge connection as simple as possible for the user.
We would appreciate your feedback on this solution and, if possible, work with us through the limitations and technicalities of such implementation.
Please let us know if you have any questions. You can reach us via email or Matrix. Looking forward to working with you.
On Fri, Aug 26, 2022 at 06:07:35PM +0100, Francisco Silva via anti-censorship-team wrote:
We are now coming to a stage on our project in which we are discussing solutions to disseminate our bridges. In the attached file we present a small draft of our proposed solution. This solution is geared towards leveraging the bridge distribution infrastructure already made available by the Tor project and make the process of establishing a bridge connection as simple as possible for the user.
You can make the bridge report extra arguments to tor, tor will publish those arguments in the bridge's extra-info descriptor, and then they will be made part of the bridge line when people get bridges from BridgeDB. In goptlib, you report such argument using the SmethodArgs function: https://pkg.go.dev/git.torproject.org/pluggable-transports/goptlib.git#Smeth... For example, obfs4proxy uses SmethodArgs to communicate the "cert" parameter of bridge lines: https://gitlab.com/yawning/obfs4/-/blob/77af0cba934d73c4baeb709560bcfc9a9fbc...
It will probably require some coordination to add TorClock to list of known transports (e.g. in the dropdown at https://bridges.torproject.org/options/, in the email responder), if that's how you imagine TorClock bridges being distributed.
BridgeDB is probably not agile enough to handle something like automatic rotation of chatroom IDs. It's more suited to long-term stable identifiers. FYI, BridgeDB is now based on a backend called rdsys: https://gitlab.torproject.org/tpo/anti-censorship/rdsys https://forum.torproject.net/t/tor-project-new-bridgedb-version-using-rdsys/... I believe one of the ideas behind rdsys was to enable not only long-term stable bridges like BridgeDB, but also fast-changing ones like the Snowflake proxy pool. But Snowflake proxies are currently still handled using a separate and unrelated system. meskio has more knowledge of rdsys.
Quoting David Fifield (2022-09-01 16:18:27)
On Fri, Aug 26, 2022 at 06:07:35PM +0100, Francisco Silva via anti-censorship-team wrote:
We are now coming to a stage on our project in which we are discussing solutions to disseminate our bridges. In the attached file we present a small draft of our proposed solution. This solution is geared towards leveraging the bridge distribution infrastructure already made available by the Tor project and make the process of establishing a bridge connection as simple as possible for the user.
You can make the bridge report extra arguments to tor, tor will publish those arguments in the bridge's extra-info descriptor, and then they will be made part of the bridge line when people get bridges from BridgeDB. In goptlib, you report such argument using the SmethodArgs function: https://pkg.go.dev/git.torproject.org/pluggable-transports/goptlib.git#Smeth... For example, obfs4proxy uses SmethodArgs to communicate the "cert" parameter of bridge lines: https://gitlab.com/yawning/obfs4/-/blob/77af0cba934d73c4baeb709560bcfc9a9fbc...
It will probably require some coordination to add TorClock to list of known transports (e.g. in the dropdown at https://bridges.torproject.org/options/, in the email responder), if that's how you imagine TorClock bridges being distributed.
BridgeDB is probably not agile enough to handle something like automatic rotation of chatroom IDs. It's more suited to long-term stable identifiers. FYI, BridgeDB is now based on a backend called rdsys: https://gitlab.torproject.org/tpo/anti-censorship/rdsys https://forum.torproject.net/t/tor-project-new-bridgedb-version-using-rdsys/... I believe one of the ideas behind rdsys was to enable not only long-term stable bridges like BridgeDB, but also fast-changing ones like the Snowflake proxy pool. But Snowflake proxies are currently still handled using a separate and unrelated system. meskio has more knowledge of rdsys.
Today in the anti-censorship meeting we have being discussing this. And thought it was better for TorCloak to have its own broker than extending BridgeDB to support it. Clients could send the room and password to the borker and the broker connect them to a bridge. The broker could use domain fronting to avoid being blocked.
Good luck with TorCloak, and keep us posted :)
Thank you again for all the details and suggestions!
We’ll keep you posted on our advances and work towards integrating TorCloak with Tor in the near future.
Best, Diogo
On Sep 1, 2022, at 18:18, meskio meskio@sindominio.net wrote:
Quoting David Fifield (2022-09-01 16:18:27)
On Fri, Aug 26, 2022 at 06:07:35PM +0100, Francisco Silva via anti-censorship-team wrote:
We are now coming to a stage on our project in which we are discussing solutions to disseminate our bridges. In the attached file we present a small draft of our proposed solution. This solution is geared towards leveraging the bridge distribution infrastructure already made available by the Tor project and make the process of establishing a bridge connection as simple as possible for the user.
You can make the bridge report extra arguments to tor, tor will publish those arguments in the bridge's extra-info descriptor, and then they will be made part of the bridge line when people get bridges from BridgeDB. In goptlib, you report such argument using the SmethodArgs function: https://pkg.go.dev/git.torproject.org/pluggable-transports/goptlib.git#Smeth... For example, obfs4proxy uses SmethodArgs to communicate the "cert" parameter of bridge lines: https://gitlab.com/yawning/obfs4/-/blob/77af0cba934d73c4baeb709560bcfc9a9fbc...
It will probably require some coordination to add TorClock to list of known transports (e.g. in the dropdown at https://bridges.torproject.org/options/, in the email responder), if that's how you imagine TorClock bridges being distributed.
BridgeDB is probably not agile enough to handle something like automatic rotation of chatroom IDs. It's more suited to long-term stable identifiers. FYI, BridgeDB is now based on a backend called rdsys: https://gitlab.torproject.org/tpo/anti-censorship/rdsys https://forum.torproject.net/t/tor-project-new-bridgedb-version-using-rdsys/... I believe one of the ideas behind rdsys was to enable not only long-term stable bridges like BridgeDB, but also fast-changing ones like the Snowflake proxy pool. But Snowflake proxies are currently still handled using a separate and unrelated system. meskio has more knowledge of rdsys.
Today in the anti-censorship meeting we have being discussing this. And thought it was better for TorCloak to have its own broker than extending BridgeDB to support it. Clients could send the room and password to the borker and the broker connect them to a bridge. The broker could use domain fronting to avoid being blocked.
Good luck with TorCloak, and keep us posted :)
-- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.
On Thu, Sep 01, 2022 at 05:30:23PM +0000, Diogo Barradas wrote:
Thank you again for all the details and suggestions!
We???ll keep you posted on our advances and work towards integrating TorCloak with Tor in the near future.
Hi Diogo!
Great to hear from you and great to hear that you're working in the "deploying pluggable transports" space.
(Wearing my Tor comms team hat) Hopefully this is the perfect time to bring up the name topic: everybody starts off by naming their thing TorSomething, but we try to discourage names of that form: in practice these names confuse users and the community about who made the thing, whether it's "official", where to turn for support, etc.
This is why the other Tor pluggable transports aren't named TorObfuscator, TorRTC, TorFront, TorTunnel, etc.
See more details about how we hope names will work here: https://www.torproject.org/about/trademark/#trademark-faq-4
In particular, we think it's fine to use TorFoo in a research paper title, because those don't confuse users about software; but once there is software for users (and it sounds like you're heading that way, which is great!) then usually there comes a point where you wish in retrospect you had picked a more unique name. :)
Thanks! --Roger
Hi Roger,
Thank you for the kind words and for your comments regarding the name of our project!
This makes total sense and we’ll work towards finding a new name for our pluggable transport before we get it deployed (hopefully soon!).
Best, Diogo (on behalf of our team)
On Sep 1, 2022, at 19:45, Roger Dingledine arma@torproject.org wrote:
On Thu, Sep 01, 2022 at 05:30:23PM +0000, Diogo Barradas wrote:
Thank you again for all the details and suggestions!
We???ll keep you posted on our advances and work towards integrating TorCloak with Tor in the near future.
Hi Diogo!
Great to hear from you and great to hear that you're working in the "deploying pluggable transports" space.
(Wearing my Tor comms team hat) Hopefully this is the perfect time to bring up the name topic: everybody starts off by naming their thing TorSomething, but we try to discourage names of that form: in practice these names confuse users and the community about who made the thing, whether it's "official", where to turn for support, etc.
This is why the other Tor pluggable transports aren't named TorObfuscator, TorRTC, TorFront, TorTunnel, etc.
See more details about how we hope names will work here: https://www.torproject.org/about/trademark/#trademark-faq-4
In particular, we think it's fine to use TorFoo in a research paper title, because those don't confuse users about software; but once there is software for users (and it sounds like you're heading that way, which is great!) then usually there comes a point where you wish in retrospect you had picked a more unique name. :)
Thanks! --Roger
On Sat, 3 Sep 2022 10:25:50 +0000, Diogo Barradas wrote:
Hi Roger,
Thank you for the kind words and for your comments regarding the name of our project!
This makes total sense and we’ll work towards finding a new name for our pluggable transport before we get it deployed (hopefully soon!).
Best, Diogo (on behalf of our team)
Random opinion: you could just drop the Tor prefix and simply keep it as Cloak, it's a nice name. And if you're going to write a dedicated broker for it, as Meskio suggested, you could name it Dagger (because it will enable users to pierce through network censorship) to make the entire thing Cloak&Dagger - compare [0].
[0] https://en.wikipedia.org/wiki/Cloak_and_dagger
anti-censorship-team@lists.torproject.org
-
David Fifield -
Diogo Barradas -
Francisco Silva -
meskio -
Roger Dingledine -
UM