Example for obfs4 bridge usage

[slezercc]

I am using the gosling arti-client-provider crate (I don't remember the exact name) to setup a client-server scheme where the server is an onion service and the clients connect to it to receive data.

The thing is, I want my program to be useable in heavily censored countries like China. I have some private obfs4 bridges in hand which I have tested on chinese servers to connect to Tor (with success) and I can't explain how happy I'd be to add bridge support to my client program.

Can any of the contributors provide some examples / boilerplate for bridge usage in this? I have actually made a bunch of modifications to the crates in this repo (most of the modifications are completion of TODO's and other cool functionality / code safety stuff). If needed, I can most likely cook up a push request sometime soon with my upgrades.

But anyways, if anyone can help me / just provide a simple program which connects to a server over Tor using an obfs4 bridge, I would be very very thankful.

[morganava]

Pluggable Transport support is not yet supported in the ArtiClientTorClient. It is implemented in the LegacyTorClient. PT support in ArtiClientTorClient is a desired feature, but probably won't be a priority for some months.

See the test_legacy_pluggable_transport_bootstrap test for an example:

• https://github.com/blueprint-freespeech/gosling/blob/ffe1fb25f7ffd695090dcfba0f3979816b5b84fa/source/gosling/crates/tor-interface/tests/tor_provider.rs#L398-L402

And some notes!

• If you're not using the Gosling protocol itself, you should just use the tor-interface crate directly
• The ArtiClientTorClient TorProvider is hella experimental, and won't work at all in some circumstances until https://gitlab.torproject.org/tpo/core/arti/-/issues/1632 is fixed upstream (specifically, if the time crate and it's large-dates feature is enabled in the same binary as the arti-client (and friends) crates).
• client-auth/restricted-discovery is not yet implemented, but should be in the coming weeks once the 0.23.0 version of the various arti crates are integrated.
• the most up-to-date pluggable transport binaries and public 'built-in' bridge-lines can be found upstream as part of the tor-expert-bundle (the alpha distribution typically has extra experimental pluggable-transports, but I think there is currently parity between stable and alpha)

Finally some guidelines for submitting pull requests:

• please split up your commits into logical sequential steps to ensure each commit is reviewable on its own (i.e. please don't include cargo fmt fixes, comment typo corrections, new functionality, in one massive change)
• please follow the current standard commit message format:

  component-name: change summary
  - bulleted list of important things to note (if any)

• please include any test additions/edits in the same commit as the feature implementaiton

[slezercc]

Thank you for your response, I have actually already added client authentication, and I was wrong, I was actually using the tor-interface crate like you suggested, I just downloaded it and modified it locally.

Now, I'm wondering, does the legacy tor client feature / crate or whatever require to have the tor expert bundle bin (tor.exe)? Or is there a way to use it in a portable way - keeping everything in my own binary like with arti?

In term of sizes, is the legacy tor bigger or smaller than arti? Last concern, probably my most important - How hard would it be to implement bridges (atleast obfs4) in ArtiClientTorClient? I checked out the docs real quick for arti, and it seems like there's some methods for bridges if I'm not wrong.

Let me know, and if implementing bridges is do-able, I can most likely do it and push my changes for everyone to benefit from it :)

[morganava]

Now, I'm wondering, does the legacy tor client feature / crate or whatever require to have the tor expert bundle bin (tor.exe)? Or is there a way to use it in a portable way - keeping everything in my own binary like with arti?

The LegacyTorClient does require you to bring along your own tor binary. If you look in the tor_provider.rs test you should find an example of howto setup both a bundled c-tor (i.e. the c-tor process is launched and owned by the process using the LegacyTorClient) and a system c-tor (i.e. c-tor is running as a service/daemon, and you need to provide credentials for its control-port).

In term of sizes, is the legacy tor bigger or smaller than arti?

I don't know :woman_shrugging: . I would expect using LegacyTorClient and a bundled c-tor to be larger (since c-tor will also include unneeded relay functionality among other things). It is a bit of a moot point if your goal is to also use pluggable-transports, since they add many megabytes to any eventual package.

Last concern, probably my most important - How hard would it be to implement bridges (atleast obfs4) in ArtiClientTorClient? I checked out the docs real quick for arti, and it seems like there's some methods for bridges if I'm not wrong.

No idea, I know upstream arti-client has some support for pluggable-transports, but I have not looked into how to integrate them into the ArtiClientTorClient crate yet. It should be relatively easy to do, since onionmasq supports pluggable-transport usage but iirc it has some Android-specific thing going.

Let me know, and if implementing bridges is do-able, I can most likely do it and push my changes for everyone to benefit from it :)

Happy to review any merge requests :)