pluggable transports issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues2020-09-03T18:56:29Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/29288Look into Salmon2020-09-03T18:56:29ZAlexander Færøyahf@torproject.orgLook into SalmonWe should look into the Salmon paper from PETS in 2016. It would allow us to build a different bridge distribution mechanism than what we have today with BridgeDB where reputation and social contacts gives you access to "better" bridges ...We should look into the Salmon paper from PETS in 2016. It would allow us to build a different bridge distribution mechanism than what we have today with BridgeDB where reputation and social contacts gives you access to "better" bridges and adds a penalty for when a bridge is censored.
The paper can be found here: https://www.freehaven.net/anonbib/cache/salmon-pets2016.pdf
The source code can be found here: https://github.com/SalmonProjecthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/29284Deploy Marionette as a PT2020-06-27T13:43:51ZCecylia BocovichDeploy Marionette as a PTActually get Marionette integrated with Tor. This depends on first assessing it (legacy/trac#29272)Actually get Marionette integrated with Tor. This depends on first assessing it (legacy/trac#29272)George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/29283Make PTs go dormant2020-07-06T23:49:52ZCecylia BocovichMake PTs go dormantThis is to make PTs more friendly in mobile environments. Right now the PT process(es) keep running in the background when they are not being used, possibly making network connections.
We need to first figure out how to do this, by poss...This is to make PTs more friendly in mobile environments. Right now the PT process(es) keep running in the background when they are not being used, possibly making network connections.
We need to first figure out how to do this, by possibly doing something creative with the PT protocolSponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/29278Assess HTTP proxy2020-06-27T13:43:51ZCecylia BocovichAssess HTTP proxyLook at the status of HTTP proxy and see what it will take to integrate it with Tor.Look at the status of HTTP proxy and see what it will take to integrate it with Tor.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/29277Look into getting default Tor bridges scanned by external reachability tests2021-06-10T14:32:24ZCecylia BocovichLook into getting default Tor bridges scanned by external reachability testsTalk to Roya or Paul about tests available for checking the blocking of default bridges.
First determine where development/research is at with Spooky Scan or possibly Censored planet (https://censoredplanet.org/).
These systems check f...Talk to Roya or Paul about tests available for checking the blocking of default bridges.
First determine where development/research is at with Spooky Scan or possibly Censored planet (https://censoredplanet.org/).
These systems check for blocking remotely and so might tell us something different from OONI.Sponsor 30 - Objective 2.3https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/29275Get default bridges checked for reachability by OONI2020-07-10T16:53:31ZCecylia BocovichGet default bridges checked for reachability by OONITalk to OONI about getting our default bridges scanned. This should be done for new PTs once they are deployed.Talk to OONI about getting our default bridges scanned. This should be done for new PTs once they are deployed.Sponsor 30 - Objective 2.3https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/24271Move all the pluggable transports repos inside Tor Project main repo2021-07-29T15:07:53ZcypherpunksMove all the pluggable transports repos inside Tor Project main repoThere are lot of pluggable transports on the page PluggableTransports/list. They have own websites with docs and source code repositories. It's hard to make sure that those services are secure, benign and trustworthy for all the visitors...There are lot of pluggable transports on the page PluggableTransports/list. They have own websites with docs and source code repositories. It's hard to make sure that those services are secure, benign and trustworthy for all the visitors. We need to create accounts in the TPO git for all the developers of pluggable transports, and move their external repositories to the TPO git.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/17523PT Spec v1 should document the ExtORPort2021-11-15T19:01:57ZYawning AngelPT Spec v1 should document the ExtORPortFollow up from legacy/trac#16754.
The newly generic PT spec is still lacking the non-tor specific parts of proposals 196 and 217 pertaining to the Extended OR Port. The information conveyed via that protocol is useful to non-tor people...Follow up from legacy/trac#16754.
The newly generic PT spec is still lacking the non-tor specific parts of proposals 196 and 217 pertaining to the Extended OR Port. The information conveyed via that protocol is useful to non-tor people so the spec should one day incorporate such.Yawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/17501Design/implement obfsNG.2020-06-27T13:43:53ZYawning AngelDesign/implement obfsNG.Name subject to change, but for now I'm following the shining example set by the IETF and calling it `obfsNG`. I will likely rename it to `obfs6` come deployment time (`obfs5` if skipping a version will confuse users.
Current planned c...Name subject to change, but for now I'm following the shining example set by the IETF and calling it `obfsNG`. I will likely rename it to `obfs6` come deployment time (`obfs5` if skipping a version will confuse users.
Current planned changes:
* Key exchange/handshake will use Ring-LWE + Ed25519 (authentication), instead of Curve25519/Elligator2 + ntor.
* Link crypto to likely use Poly1305 + ChaCha20 in a better designed framing format than the SipHash-2-4 + Poly1305/XSalsa20 abomination used by obfs4.
* Inline padding negotiation to simplify bridge line formatting.
Benefits:
* Slightly easier to use, with a slightly shorter Bridge line.
* Indistinguishability of the key exchange is a property of the key exchange primitive used, rather than something separate that needs care when using a la Elligator2.
* More future-proofing by adding flexibility to padding.
Downsides:
* Ring-LWE is really new, and the implementation was ported to Go by some random sketchoid.Yawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/16756Formalize and document what it takes for a PT to get deployed.2021-11-15T18:57:13ZYawning AngelFormalize and document what it takes for a PT to get deployed.It would be good to formalize what it takes to get a PT to be considered for deployment beyond the rough guidelines we have as part of our Sponsor S/T draft. I have some ideas here about things that should be considered that aren't, tha...It would be good to formalize what it takes to get a PT to be considered for deployment beyond the rough guidelines we have as part of our Sponsor S/T draft. I have some ideas here about things that should be considered that aren't, that other people are likely to disagree about, so discussion is needed.
The last 3 PTs that got deployed were FTE, ScrambleSuit and obfs4.
* What did we do?
* Out of what we did, what was right?
* Out of what we did, what was wrong?
* What did we consider that we should ignore in the future?
* What did we not consider that we should in the future?
* Who's going to do all the evaluation work?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/16755Design a version 2 Pluggable Transport spec.2020-06-27T13:43:55ZYawning AngelDesign a version 2 Pluggable Transport spec.The current PT spec works, but has a few design flaws that require breaking compatibility to fix. While doing this process further thought should (maybe?) be given to making it even easier for other applications to adopt.
In addition t...The current PT spec works, but has a few design flaws that require breaking compatibility to fix. While doing this process further thought should (maybe?) be given to making it even easier for other applications to adopt.
In addition to the existing issues that will be re-parented to this ticket the new spec should:
* Maybe not prefix env vars with `TOR_`, since "Pluggable Transports aren't just a Tor thing". No strong opinion on this. If that's all that's kept people from using the spec, it's kind of silly.
* Your idea here.Yawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/16754Clean up the exisiting Pluggable Transport spec2020-06-27T13:43:55ZYawning AngelClean up the exisiting Pluggable Transport specThe current Pluggable Transport spec has gotten more and more Tor specific, which is bad for people that aren't Tor that wish to use the managed PT API. The current spec should be cleaned up to address:
* Why managed mode is a good id...The current Pluggable Transport spec has gotten more and more Tor specific, which is bad for people that aren't Tor that wish to use the managed PT API. The current spec should be cleaned up to address:
* Why managed mode is a good idea.
* Include the ExtORPort stuff.
* Make it abundantly clear that not just Tor can/should use this and managed mode.
* Other misc. spec clarifications as needed.
Note: This is entirely separate from writing a v2 of the Pluggable Transport spec that fixes the warts in the existing one (which will involve code).Yawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/15545Document TOR_PT_EXIT_ON_STDIN_CLOSE in the pt-spec.2020-06-27T13:43:56ZYawning AngelDocument TOR_PT_EXIT_ON_STDIN_CLOSE in the pt-spec.This is the ticket for the documentation side of the `TOR_PT_EXIT_ON_STDIN_CLOSE` and associated behavior that was implemented as part of legacy/trac#15435.
`pt-spec.txt` needs to document that if the env var is set to `1`, then PTs sho...This is the ticket for the documentation side of the `TOR_PT_EXIT_ON_STDIN_CLOSE` and associated behavior that was implemented as part of legacy/trac#15435.
`pt-spec.txt` needs to document that if the env var is set to `1`, then PTs should assume that tor will keep stdin open, and to treat stdin being closed as the same as a `SIGTERM` (graceful shutdown immediately).Tor: 0.2.8.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/12910Create packages for obfs4proxy for bridge administrators.2020-06-27T13:43:57ZYawning AngelCreate packages for obfs4proxy for bridge administrators.Once I complete legacy/trac#12606 and tag a release, it would probably ease deployment if there were binary packages of obfs4proxy so that bridge administrators could easily deploy obfs4 bridges (or obfs3 for that matter).
As it stands ...Once I complete legacy/trac#12606 and tag a release, it would probably ease deployment if there were binary packages of obfs4proxy so that bridge administrators could easily deploy obfs4 bridges (or obfs3 for that matter).
As it stands right now, the only OS I can easily make packages for is Arch Linux, but I assume "it's in AUR" won't be helpful to the vast majority of bridges out there (which I assume run some flavor of Debian).
The "correct" Debian way to package go binaries apparently involves having packages for all the dependencies.
* go.net: https://packages.debian.org/sid/devel/golang-go.net-dev
* go.crypto: https://packages.debian.org/sid/golang-go.crypto-dev
* goptlib: https://packages.debian.org/sid/golang-goptlib-dev
* siphash: NEEDS PACKAGING
* ed25519: NEEDS PACKAGING
For reference: https://wiki.debian.org/MichaelStapelberg/GoPackagingLunarLunarhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/12903Integrate obfs4proxy into the TBB bundle.2020-06-27T13:43:57ZYawning AngelIntegrate obfs4proxy into the TBB bundle.I did some of the preliminary work based off dcf's meek branch a while ago, now that meek has been merged into TBB, and obfs4proxy is approaching what I consider deployable, it is the time to change my patch into a real branch.
Open que...I did some of the preliminary work based off dcf's meek branch a while ago, now that meek has been merged into TBB, and obfs4proxy is approaching what I consider deployable, it is the time to change my patch into a real branch.
Open questions that I need to figure out:
* Is it ok to just mirror dependencies at `people.tp.o/~yawning/mirrors/source`?
* My patch only edited `versions.nightly` since I wasn't (and still am not quite) at the point where I was comfortable tagging obfs4proxy. Is there a way to say "use this commit" for the other files?
* The LICENSE file needs to be copied.Yawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/12130Figure out deployment strategy for obfs42020-06-27T13:43:59ZGeorge KadianakisFigure out deployment strategy for obfs4While we were busy doing other things, Yawning created his own PT which supercedes scramblesuit. obfs4 (this is a temporary name), aims to have all the features of scramblesuit and a bit more (for example, it has better performance becau...While we were busy doing other things, Yawning created his own PT which supercedes scramblesuit. obfs4 (this is a temporary name), aims to have all the features of scramblesuit and a bit more (for example, it has better performance because of Elligator instead of UniformDH).
The code can be found at `https://github.com/Yawning/obfs4` and apparently it already has feature parity with scramblesuit.
We should decide whether we should deploy obfs4 and when.
Some possible avenues:
- Deploy **both** scramblesuit and obfs4. This is a bit pointless since obfs4 does not have any real threat model differences over scramblesuit. And deploying another transport means that we have to ask bridge operators to upgrade, and users to learn another transport name (crying wolf paradigm applies here too). Also, maintaining two similar codebases is a bit stupid.
- Deploy obfs4 **instead of** scramblesuit. This makes more sense since obfs4 is supposedly _strictly better_ than scramblesuit. However:
1. scramblesuit is already a bit deployed. We have a few bridges already running it, and it was also recently added in the TBB `https://gitweb.torproject.org/builders/tor-browser-bundle.git/commitdiff/ef80bcdfd15ba873de6c7a88382176b893770638`.
2. obfs4 is untested and will probably need some time to pass quality control and review.
3. obfs4 is a go application, so it needs an extra patch to the TBB build process.
- Continue scramblesuit deployment, and hold on to obfs4. Maybe we can use obfs4 as an emergency transport in the future. Unfortunately, this is suboptimal. since it means that we will have to write TBB build patches to deploy the emergency transport. It would make more sense to hold on scramblesuit as the emergency transport (since it's already in obfsproxy).George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10878push obfs-flash Twisted improvements upstream2021-11-08T19:58:32ZXimin Luopush obfs-flash Twisted improvements upstreamIn the process of building obfs-flash we added some improvements to Twisted that are currently implemented as monkeypatches. We should push this upstream.In the process of building obfs-flash we added some improvements to Twisted that are currently implemented as monkeypatches. We should push this upstream.Ximin LuoXimin Luohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10873review liballium2021-11-08T19:58:17ZXimin Luoreview liballiumhttps://gitweb.torproject.org/user/yawning/liballium.githttps://gitweb.torproject.org/user/yawning/liballium.githttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10672Send mail to bridge operators and inform them of pluggable transports2020-06-27T13:44:00ZGeorge KadianakisSend mail to bridge operators and inform them of pluggable transportsAs part of the efforts to increase the number of obfsbridges, we should gather the Contact addresses of bridge operators that don't do pluggable transports and drop them an email asking them to start using obfsproxy etc.
I think sysrqb ...As part of the efforts to increase the number of obfsbridges, we should gather the Contact addresses of bridge operators that don't do pluggable transports and drop them an email asking them to start using obfsproxy etc.
I think sysrqb is collecting the spam list. The list will contain around 300 to 400 addresses. My plan is to send them an email, set the Reply-To field to tor-assistants (or should this be tor-relays?) and inform them that replies will be sent to a mailing list. Please raise your voice if you think this is nuts.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10362Deploy FTE as a pluggable transport in PTTBBs2020-06-27T13:44:01ZGeorge KadianakisDeploy FTE as a pluggable transport in PTTBBsThis is the ticket to organize the deployment of FTE as a new pluggable transport in PTTBBs.
Kevin posted a release announcement here:
https://lists.torproject.org/pipermail/tor-dev/2013-December/005929.html
We need to review and audit...This is the ticket to organize the deployment of FTE as a new pluggable transport in PTTBBs.
Kevin posted a release announcement here:
https://lists.torproject.org/pipermail/tor-dev/2013-December/005929.html
We need to review and audit the code before we deploy this. Then we need to include it in our next PTTBBs.kpdyerkpdyer