pluggable transports issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues2020-06-27T13:44:01Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10314Think of strategy for deprecating pluggable transports (e.g. obfs2)2020-06-27T13:44:01ZGeorge KadianakisThink of strategy for deprecating pluggable transports (e.g. obfs2)Currently, most bridges (the 70%) run obfs3+obfs2 and the rest run only obfs2.
China has an active probing module for obfs2 and not for obfs3, so using obfs2 in China is bad currently. It doesn't allow you to bypass censorship and it mi...Currently, most bridges (the 70%) run obfs3+obfs2 and the rest run only obfs2.
China has an active probing module for obfs2 and not for obfs3, so using obfs2 in China is bad currently. It doesn't allow you to bypass censorship and it might also burn the bridge (if they ever decide to do IP-based censorship and not IP/TCP-based censorship).
We should think of how to deprecate obfs2. A good starting point would be to completely remove it from obfsproxy (by removing the code) and also stop suggesting it via BridgeDB.
We should think if there are any problems with the above approach, and how we can improve it.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10006Build an obfs-flash PT bundle2020-06-27T13:44:02ZDavid Fifielddcf@torproject.orgBuild an obfs-flash PT bundleCreate a test pluggable transports bundle with the obfs3_flashproxy transport in place of the flashproxy transport.Create a test pluggable transports bundle with the obfs3_flashproxy transport in place of the flashproxy transport.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/9863Move websocket-transport to its own repo2020-06-27T13:44:03ZDavid Fifielddcf@torproject.orgMove websocket-transport to its own repolegacy/trac#9831 created /pluggable-transports/websocket.git. Let's move /flashproxy.git/websocket-transport there.
If I remember correctly, the procedure goes something like
1. Clone your local flashproxy repo and put it in a directo...legacy/trac#9831 created /pluggable-transports/websocket.git. Let's move /flashproxy.git/websocket-transport there.
If I remember correctly, the procedure goes something like
1. Clone your local flashproxy repo and put it in a directory called websocket.
2. In the new websocket directory, run
```
git filter-branch --subdirectory-filter websocket-transport -- --all
```
(Check the man page for git-filter-branch.)
3. Check the new history and make sure it looks right and makes sense. It might be worth doing `git log -C -M --stat websocket-transport` in the flashproxy repo to check if any files might have lived in another directory at some point.
4. Add a remote that points to the new /pluggable-transports/websocket.git.
5. Push to the new remote.
I think it makes sense to move doc/websocket-transport.txt into the new repo as well, and update references to it in the flashproxy source code.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/9742Give the Go pluggable transports library its own home2020-06-27T13:44:03ZDavid Fifielddcf@torproject.orgGive the Go pluggable transports library its own homeThe library that currently lives at https://gitweb.torproject.org/flashproxy.git/tree/HEAD:/websocket-transport/src/pt is nice, and is already being used by a separate program, the super-proxy server in legacy/trac#7167. It should have i...The library that currently lives at https://gitweb.torproject.org/flashproxy.git/tree/HEAD:/websocket-transport/src/pt is nice, and is already being used by a separate program, the super-proxy server in legacy/trac#7167. It should have its own home separate from the flashproxy tree, like pyptlib is separate from obfsproxy.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/9732Define SIGTERM behavior in pluggable transports spec2020-06-27T13:44:03ZDavid Fifielddcf@torproject.orgDefine SIGTERM behavior in pluggable transports spechttps://gitweb.torproject.org/torspec.git/blob/2f031167c120761fa2a3ef3e1dc62e630ab7372a:/proposals/180-pluggable-transport.txt says:
Proxies should respond to a single INT signal by closing their listener ports and not accepting any ne...https://gitweb.torproject.org/torspec.git/blob/2f031167c120761fa2a3ef3e1dc62e630ab7372a:/proposals/180-pluggable-transport.txt says:
Proxies should respond to a single INT signal by closing their listener ports and not accepting any new connections, but keeping all connections open, then terminating when connections are all closed. Proxies should respond to a second INT signal by shutting down cleanly.
But it's silent on SIGTERM. When I `/etc/init.d/tor stop` on Debian, `torctl` kills the tor process with SIGTERM. I noticed because the super-proxy from comment:32:ticket:7167 starts subprocesses. It was properly killing the subprocesses on SIGINT, but not on SIGTERM.
My proposed wording:
Proxies should respond to a single TERM signal by closing their listener ports, closing all existing connections, and terminating.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/9228Create an SSH pluggable transport2021-07-29T15:19:24ZGeorge KadianakisCreate an SSH pluggable transportYawning is writing an SSH pluggable transport.
It needs legacy/trac#9162 and legacy/trac#9163 to be deployed without ugly hotfixes.
This ticket tracks its progress.Yawning is writing an SSH pluggable transport.
It needs legacy/trac#9162 and legacy/trac#9163 to be deployed without ugly hotfixes.
This ticket tracks its progress.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/9192Create a git pluggable transport2021-07-29T15:15:23ZGeorge KadianakisCreate a git pluggable transportFor the past few weeks, some lads are working on a git pluggable transport as a module to obfsproxy.
This is a ticket to "trac" its progress.For the past few weeks, some lads are working on a git pluggable transport as a module to obfsproxy.
This is a ticket to "trac" its progress.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/9022Create an XMPP pluggable transport2021-07-29T15:18:46ZGeorge KadianakisCreate an XMPP pluggable transportWe should look into XMPP pluggable transports. There are many public XMPP services that see widespread use even from censored countries.We should look into XMPP pluggable transports. There are many public XMPP services that see widespread use even from censored countries.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/8942Update gnulinux pluggable transports bundle instructions for Debian 72020-06-27T13:44:05ZDavid Fifielddcf@torproject.orgUpdate gnulinux pluggable transports bundle instructions for Debian 7https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/doc/bundle-gnulinux.txthttps://gitweb.torproject.org/flashproxy.git/blob/HEAD:/doc/bundle-gnulinux.txtGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/7903Research ways of adding Extended ORPort support to pyptlib2021-11-08T19:53:48ZGeorge KadianakisResearch ways of adding Extended ORPort support to pyptlibA server-side pluggable transport, before proxying the deobfuscated data to the ORPort, it must do the Extended ORPort dance (during which it sends to Tor the IP address of its client, the name of the pluggable transport used, etc.).
It...A server-side pluggable transport, before proxying the deobfuscated data to the ORPort, it must do the Extended ORPort dance (during which it sends to Tor the IP address of its client, the name of the pluggable transport used, etc.).
It would be nice if developers that write pluggable transports (like flashproxy, stegotorus, etc.) didn't have to care about the Extended ORPort protocol, but still enjoy its benefits. Since these pluggable transports are supposed to be using pyptlib for their managed-proxy needs, it would make sense for pyptlib to also handle the Extended ORPort part.
We should research ways of implementing the Extended ORPort logic to pyptlib without dictating a certain way of thinking and programming to the pluggable transports developer. For example, pyptlib should not use twisted to do the Extended ORPort dance, since that would pretty-much force the developer to use twisted for his transport too.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/7323Create pluggable transports news-feed for bridge operators2020-06-27T13:44:06ZGeorge KadianakisCreate pluggable transports news-feed for bridge operatorsWhen censors get up to speed with pluggable transports, they will start blocking them.
We should develop an incident response procedure, to help deploy new transports when needed, and inform bridge operators and users about specific blo...When censors get up to speed with pluggable transports, they will start blocking them.
We should develop an incident response procedure, to help deploy new transports when needed, and inform bridge operators and users about specific blocks and how to circumvent them.
We should consider whether we want to do this in tor-relays, or in a new list, or just as an RSS feed in the website.
We should also ask bridge operators to put legit Contact addresses, so that we can contact them if we need some kind of rapid deployment.
In the future, when we have things like Thandy, keeping bridges up-to-date in response to censorship incidents will be easier.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/7322Educate bridge operators about pluggable transports2020-06-27T13:44:06ZGeorge KadianakisEducate bridge operators about pluggable transportsWe don't have enough obfsbridges at the moment.
We should write a blog post and/or mail tor-{talk,relays} to inform bridge operators about pluggable transports.
Things to mention:
We should inform them about the 0.2.4.x tree and how i...We don't have enough obfsbridges at the moment.
We should write a blog post and/or mail tor-{talk,relays} to inform bridge operators about pluggable transports.
Things to mention:
We should inform them about the 0.2.4.x tree and how it reports itself to BridgeDB.
We should tell them that they should keep their pluggable transport proxy upgraded to get all the new transports.
We should also explain them our deployment "plan" and how we plan to turn all bridges into obfsbridges.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/7321Update the bridge website documentation with pluggable transport information2020-06-27T13:44:06ZGeorge KadianakisUpdate the bridge website documentation with pluggable transport informationWe should update https://www.torproject.org/docs/bridges to include pluggable transport information.
We should also find other places where people are getting informed about bridges and add pluggable transport information there too.We should update https://www.torproject.org/docs/bridges to include pluggable transport information.
We should also find other places where people are getting informed about bridges and add pluggable transport information there too.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/7320Write blog post to educate users about pluggable transports2021-07-09T14:16:24ZGeorge KadianakisWrite blog post to educate users about pluggable transportsMost users don't know what pluggable transports are, how to use them, how to find obfsbridges, etc.
In the future where technologies like Thandy and BridgeFinder are deployed, maybe users shouldn't know what pluggable transports are.
F...Most users don't know what pluggable transports are, how to use them, how to find obfsbridges, etc.
In the future where technologies like Thandy and BridgeFinder are deployed, maybe users shouldn't know what pluggable transports are.
For now though, we should write a user-oriented blog post on how people should use them.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/7319Organise deployment of pluggable transports2020-06-27T13:44:06ZGeorge KadianakisOrganise deployment of pluggable transportsWe are currently in the process of deploying pluggable transports, and we are doing a half-assed job; especially at helping users use pluggable transports.
This is a parent ticket in an attempt to organize the deployment better.We are currently in the process of deploying pluggable transports, and we are doing a half-assed job; especially at helping users use pluggable transports.
This is a parent ticket in an attempt to organize the deployment better.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5148SIGHUP managed proxies when logs reopened2021-10-07T14:21:00ZtwildeSIGHUP managed proxies when logs reopenedWe use SIGHUP to cause Tor to reopen its logs after a rotation, but currently this SIGHUP is not passed along to a managed proxy (ie obfsproxy). The only way to automatically tell obfsproxy to reopen logs without finding its process and...We use SIGHUP to cause Tor to reopen its logs after a rotation, but currently this SIGHUP is not passed along to a managed proxy (ie obfsproxy). The only way to automatically tell obfsproxy to reopen logs without finding its process and sending a SIGHUP manually is to do a full tor restart, which will kill and restart the managed proxy as well. Perhaps all SIGHUPs to Tor should just be passed along to any (unchanged argument) managed proxies?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5059Organize an obfsproxy/PTTB test run2020-06-27T13:44:08ZGeorge KadianakisOrganize an obfsproxy/PTTB test runkarsten and arma were considering an obfsproxy testrun, where a
client-PTTB (legacy/trac#4927) would be deployed, configured with hardcoded
obfs2'ed bridges.
This should get us some bug reports on obfsproxy, some usability
comments from...karsten and arma were considering an obfsproxy testrun, where a
client-PTTB (legacy/trac#4927) would be deployed, configured with hardcoded
obfs2'ed bridges.
This should get us some bug reports on obfsproxy, some usability
comments from end-users, and help us figure out legacy/trac#5038 and other
performance-related questions.
The initial plan was to setup an obfsproxy in moria, but I believe
it's a better idea to setup obfsproxy in less sensitive boxes [0].
This is a ticket to coordinate this effort.
legacy/trac#5047 is also important, to gather statistics and see approximately
how many users used pluggable transports during the testing period.
We should also decide how many bridges to hardcode. Do we actually
need more than one? I know that gamambel, marlowe and ln5 are
interested in setting up obfsproxy. Still, I think that the original
idea of a single bridge is better, so that we can get better answers
for legacy/trac#5038. If too many users use the bundle, we can then add more
bridges. So, who gets to setup the PTTB obfsproxy?
[0]:
There are probably easier ways of compromising computers than
exploiting obfsproxy security bugs, but I will be feeling better if
obfsproxy-beta is not touching a directory authority.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5023Morpher pluggable transport: Select algorithm for packet size morphing2020-06-27T13:44:08ZGeorge KadianakisMorpher pluggable transport: Select algorithm for packet size morphingThis is a ticket to resolve a) of comment:1:ticket:4680 :
We should evaluate whether the final morpher transport should use 'random sampling', or 'morphing matrices' to select a packet's final packet size.
In 'random sampling', you hav...This is a ticket to resolve a) of comment:1:ticket:4680 :
We should evaluate whether the final morpher transport should use 'random sampling', or 'morphing matrices' to select a packet's final packet size.
In 'random sampling', you have a packet size probability distribution of a target protocol, and you pick a random variable, and then you shape your packet to be of that size.
By 'morphing matrices', I mean the technique described in the paper Traffic Morphing: An efficient defense against statistical traffic analysis which attempts to minimize the padding overhead imposed by packet size shaping.
Since our morpher transport will try to turn Tor traffic into HTTPS traffic, as far as packet sizes are concerned, we should evaluate whether the 'morphing matrices' method is worth it. We can build a tool that uses both methods on a couple thousand packets, and see which method is more effective. If 'morphing matrices' is indeed more effective, we should see whether it's effective enough to justify its troublesome implementation.
I stupidly attached all relevant files to legacy/trac#4680, but let's continue the discussion here to avoid flooding legacy/trac#4680 more.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5012Write proposals to allow an external program that discovers bridge addresses ...2020-06-27T13:44:08ZKarsten LoesingWrite proposals to allow an external program that discovers bridge addresses to tell Tor about them and start implementing the proposalsThis ticket is part of sponsor F deliverable 7. Once we have a recommended approach for an external program that discovers bridge addresses to tell Tor about them, we need to write proposals and start implementing them. The "and start ...This ticket is part of sponsor F deliverable 7. Once we have a recommended approach for an external program that discovers bridge addresses to tell Tor about them, we need to write proposals and start implementing them. The "and start implementation as needed" part of the deliverable text is vague enough to focus on the design discussion and proposals. If there's time left to implement something, great, but if not, that's fine, too. We can still implement proposals between March and November 2012.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5011Discuss possible designs for an external program that discovers bridge addres...2020-06-27T13:44:08ZKarsten LoesingDiscuss possible designs for an external program that discovers bridge addresses to tell Tor about themThis ticket is part of sponsor F deliverable 7. Before we can come up with a recommended approach for an external program that discovers bridge addresses to tell Tor about them, we need to discuss possible designs.
Mike said he's going...This ticket is part of sponsor F deliverable 7. Before we can come up with a recommended approach for an external program that discovers bridge addresses to tell Tor about them, we need to discuss possible designs.
Mike said he's going to take the lead on the discussion. Back in December we agreed on February 13 as the deadline for the discussion. Maybe we need a new deadline, but one that still leaves time for writing proposals and starting to implement them.Mike PerryMike Perry