Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2020-06-27T13:44:20Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12674Neuter meek-http-helper's default proxy setting2020-06-27T13:44:20ZDavid Fifielddcf@torproject.orgNeuter meek-http-helper's default proxy settingThe headless meek-http-helper browser undoes Tor Browser's proxy setting:
https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/5400da654020a34edb9edee70a0583a89231c4fe:/Bundle-Data/PTConfigs/meek-http-helper-user.js#l7
...The headless meek-http-helper browser undoes Tor Browser's proxy setting:
https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/5400da654020a34edb9edee70a0583a89231c4fe:/Bundle-Data/PTConfigs/meek-http-helper-user.js#l7
{{{
// 0 is "No proxy".
user_pref("network.proxy.type", 0);
}}}
This setting used to be necessary in order for the HTTPS requests to be made on the network without themselves trying to go through the local tor proxy. However, since legacy/trac#12120, we [set the proxy type individually for every request](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/firefox/components/main.js#l134) (including a "direct" non-proxy when TOR_PT_PROXY is unset), so it's no longer necessary to change the global setting.
A good reason to leave the proxy set is so if someone manages to start Firefox using the meek-http-helper profile as a normal non-headless browser, it should fail closed, and give "the proxy server is refusing connections" rather than acting as an unproxied browser.
Even better, we can set the proxy URL to 127.0.0.1:9, the discard port, so it will fail even closeder if tor happens to be running on the usual port set by Tor Browser.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40000Gitlab Migration Milestone2020-06-13T18:33:20ZTracGitlab Migration MilestoneWe're creating this ticket as a part of the Trac-to-Gitlab migration, so that each project's numbering for new tickets will start with 40001.We're creating this ticket as a part of the Trac-to-Gitlab migration, so that each project's numbering for new tickets will start with 40001.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5549Evaluate feasibility of a Python obfsproxy and possibly get it started2020-06-27T13:44:07ZKarsten LoesingEvaluate feasibility of a Python obfsproxy and possibly get it startedItem 19 from [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2) is: "evaluate feasibility of a python equivalent to obfsproxy, to make it easier for people to write transports in python. See also Brandon Wiley's "dust". If we dec...Item 19 from [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2) is: "evaluate feasibility of a python equivalent to obfsproxy, to make it easier for people to write transports in python. See also Brandon Wiley's "dust". If we decide it's smart, get it started."
There are a few substeps here: first, we should discuss feasibility of a Python obfsproxy; maybe we need some proof-of-concept implementation to further evaluate things we cannot solve by discussion; then we need to make a decision; and finally, if we decide that having a Python obfsproxy is a good idea, we'll have to get it started.
Creating a child ticket for the discussion part. Further substeps should get their own child tickets.
We need to decide whether this is a July or November deliverable (optimistically assigning to July), and we need somebody to lead the deliverable.
There are quite a few people who I've heard might be interested in this topic and who I'm cc'ing: nickm, asn, aagbsn, blanu, zwol, xmux. If more people are interested, please cc yourself.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/22874Standalone broker (independent of App Engine)2020-06-27T13:40:41ZDavid Fifielddcf@torproject.orgStandalone broker (independent of App Engine)[Currently](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/broker?id=bfea72b50e9277be0abae1b696431c28faef681c) the broker code is implemented only for App Engine; i.e. it doesn't have a `main` function and relies o...[Currently](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/broker?id=bfea72b50e9277be0abae1b696431c28faef681c) the broker code is implemented only for App Engine; i.e. it doesn't have a `main` function and relies on being invoked using the App Engine APIs.
Instead, the broker should run as a standalone HTTPS server somewhere, and App Engine should only be a dumb request/response forwarder (we can steal the [forwarder code from meek](https://gitweb.torproject.org/pluggable-transports/meek.git/tree/appengine?id=451320610020753ccaee2d533972a6ae5a1873c0)). That will make it possible to easily add domain fronts other than Google (legacy/trac#22782), and any secret data we handle on the broker won't have to be revealed to Google.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/2688BridgeDB re-assigns unallocated bridges from/to file buckets without need2021-07-09T18:27:09ZKarsten LoesingBridgeDB re-assigns unallocated bridges from/to file buckets without needIt looks like BridgeDB re-assigns unallocated bridges from/to file buckets without need. That is, a bridge that keeps running from one network status to the next might be removed from a file bucket and replaced with another bridge. Thi...It looks like BridgeDB re-assigns unallocated bridges from/to file buckets without need. That is, a bridge that keeps running from one network status to the next might be removed from a file bucket and replaced with another bridge. This leads to quick enumeration of all bridges in the unallocated pool when using file buckets.
A second bug seems to be that BridgeDB appends bridges to file buckets instead of overwriting these files. The result is that there are duplicate entries in files that external distributors use.
Here's how one can reproduce the problem using sanitized bridge descriptors. Yes, this description is lengthy and ugly, but it works for testing BridgeDB in general, even if one doesn't have the original bridge descriptors handy.
Download and extract the sanitized bridge descriptors from January 2009:
https://metrics.torproject.org/data/bridge-descriptors-2009-01.tar.bz2
Create a single bridge-descriptors file containing all bridge descriptors from that month.
$ cd bridge-descriptors-2009-01/
$ echo "@purpose bridge" > purpose
$ echo "router-signature" > routersignature
$ find server-descriptors/ -type f | xargs -I{} cat purpose {} routersignature > bridge-descriptors
Copy the new bridge-descriptors file to BridgeDB's working directory (here: `~/run/`).
$ cd ~/run/
$ cp bridge-descriptors-2009-01/bridge-descriptors .
Also copy the sanitized network status file from 2009-01-10 00:07:04 to BridgeDB's working directory and rename it to networkstatus-bridges.
$ cp bridge-descriptors-2009-01/statuses/10/20090110-000704-4A0CCD2DDC7995083D73F5D667100C8A5831F16D networkstatus-bridges
Configure BridgeDB to write 4 bridges to file bucket `twitter`, otherwise keep the default configuration. Start BridgeDB (note that it may take 30 seconds to digest the 8.5M bridge-descriptors file) and dump bridges to file buckets.
The result is a new file `twitter-2011-03-09.brdgs` with this content (may vary for you):
```
10.134.79.249:443
10.236.199.173:443
10.116.76.140:9001
10.51.76.151:18443
```
It also writes this `unallocated-2011-03-09.brdgs` file (again, content may vary):
```
10.126.198.237:443
10.251.69.61:9003
10.31.186.235:49001
10.81.88.5:9001
```
Replace the networkstatus-bridges with the one from roughly 30 minutes later:
$ cp bridge-descriptors-2009-01/statuses/10/20090110-030709-4A0CCD2DDC7995083D73F5D667100C8A5831F16D networkstatus-bridges
Give BridgeDB a HUP, wait at least 30 seconds, and tell it to dump bridges to file buckets again.
Here's my new `twitter-2011-03-09.brdgs` file:
```
10.134.79.249:443
10.236.199.173:443
10.116.76.140:9001
10.51.76.151:18443
10.51.76.151:18443
10.237.143.0:443
10.241.115.62:443
10.239.76.198:443
```
And my `unallocated-2011-03-09.brdgs` file:
```
10.126.198.237:443
10.251.69.61:9003
10.31.186.235:49001
10.81.88.5:9001
10.126.198.237:443
10.251.69.61:9003
10.31.186.235:49001
10.81.88.5:9001
10.134.79.249:443
10.236.199.173:443
10.116.76.140:9001
```
There are two bugs:
- Why was 10.236.199.173:443 (2nd line in `twitter-2011-03-09.brdgs`) removed from this file bucket and put back in the unallocated ring again (last but one line in `unallocated-2011-03-09.brdgs`)? I confirmed that this is the same bridge using the new pool assignments patch that is not merged yet. This is the first bug described above.
- Why are IP:port lines appended to these files? This is the second bug described above.Christian FrommeChristian Frommehttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/18285Etisalat (UAE ISP) requiring users to use certain routers (was: The Arab Gulf...2020-06-27T13:43:41ZcypherpunksEtisalat (UAE ISP) requiring users to use certain routers (was: The Arab Gulf Governments Surveillance Project)The ISP called Etisalat which is located in UAE (United Arab Emirates) , they are using new strategy of forcing their surveillance on ppl, and they have used trick to lie on ppl, which is:-
they are calling & sending messages to UAE ppl...The ISP called Etisalat which is located in UAE (United Arab Emirates) , they are using new strategy of forcing their surveillance on ppl, and they have used trick to lie on ppl, which is:-
they are calling & sending messages to UAE ppl , and telling them you can upgrade your internet speed from X megabits to 20 megabits with free router and wireless-telephone and Tv-satellite or receiver.
now is this problem? no , but here is the deception inside this:-
they will force you to use their router because there will be no internet connection from your own router. and their router is D-Link DIR 850L6 (some got another models but as i know all of them are from D-Link company) with Etisalat firmware (not the original D-Link firmware).
their firmware has a backdoor inside it , which give the ability to any Etisalat employee accessing the router and do/change whatever they like inside it. not to mention the firmware is closed source for sure, and MAYBE contain malicious programs inside it like e.g spyware or ..etc.or executable programs which can attack targeted OS for e.g Windows/Android/IOS...etc
but what is for sure now the firmware has a backdoor inside it.
and also you CANT go back to the original speed that you were using + your own router. and also adding fees about 200$ if will cancel the internet.and if you will use another firmware like the original firmware of from D-Link company or an open source firmware you will loose the internet connection, and you cant download Etisalat firmware and install it again (because the firmware is not available for users) so they will give you a new router & charge you the corrupted router price. (about 50$ to 100$)
and if you ask them why are you doing this? their answer is:-
"we want to serve our customers as we can give them full support when having a problem regarding connectivity with routers."
(as you see very cheap excuse (the perfect bad word for it = bullshit) in order to kill your freedom of choice on routers with high security levels and surfing the internet freely as you like.and)
so the good question would be:-
- can that effect Tor security/connectivity?
- how can someone help Tor community to understand the risk on Tor users from this privacy attack? (i know ooni project , but it seems complicated and not really much active)
Notes:-
1- i have sent this message to tor project emails the English and the Arabic one = sadly no response till now from over a month or so.
2- this surveillance project not just in UAE , even in Saudia Arabia and so one..
3- i didnt know which categories (Type,Priority,Severity...etc) i should choose for this topic , so i just put anything randomly
lastly i say , hope Tor community/developers/news warn the poor ppl inside these countries by spreading this article (or any similar to it if available) so that (i hope) those ppl will be aware from these attempts and look for themselves to have a good solution for this problem.
Thanks.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12716Make meek-client-torbrowser take the firefox command as a parameter2020-06-27T13:44:20ZDavid Fifielddcf@torproject.orgMake meek-client-torbrowser take the firefox command as a parametermeek-client-torbrowser hardcodes the firefox binary and profile paths: [linux](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/meek-client-torbrowser/linux.go) [mac](https://gitw...meek-client-torbrowser hardcodes the firefox binary and profile paths: [linux](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/meek-client-torbrowser/linux.go) [mac](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/meek-client-torbrowser/mac.go) [windows](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/meek-client-torbrowser/windows.go). The problem is that when Tor Browser is reorganized, as it was in legacy/trac#11641, you need to make the corresponding change in meek-client-torbrowser, for example [178572f5](https://gitweb.torproject.org/pluggable-transports/meek.git/commitdiff/178572f5f1bb52200fa4c45497298241a745d8af).
meek-client-torbrowser already takes the full meek-client command on the command line; it [looks like](https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/a2370de2b0b44a22f3f2591c2960cd6767940b8b:/Bundle-Data/PTConfigs/linux/torrc-defaults-appendix#l14):
```
ClientTransportPlugin meek exec ./TorBrowser/Tor/PluggableTransports/meek-client-torbrowser -- ./TorBrowser/Tor/PluggableTransports/meek-client --url=https://meek-reflect.appspot.com/ --front=www.google.com
```
I don't know of a good clear way to encode two separate command lines into the command line of another program, except maybe to do them both as long strings and then parse the strings before calling exec.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31878Make BridgeDB and bridge authority more resilient2020-11-20T18:46:03ZPhilipp Winterphw@torproject.orgMake BridgeDB and bridge authority more resilientWe should explore options to decentralise BridgeDB and/or our bridge authority.We should explore options to decentralise BridgeDB and/or our bridge authority.Sponsor 30 - Objective 2.4https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5614Develop an experimental Python pluggable transport library2020-06-27T13:44:07ZKarsten LoesingDevelop an experimental Python pluggable transport libraryIn sponsor F year 2 deliverable 19 (legacy/trac#5549) we concluded that writing a Python pluggable transport library is feasible. This ticket is about the actual development of an experimental Python library for pluggable transports. D...In sponsor F year 2 deliverable 19 (legacy/trac#5549) we concluded that writing a Python pluggable transport library is feasible. This ticket is about the actual development of an experimental Python library for pluggable transports. Deliverable 19 says "If we decide it's smart, get it started," but it doesn't make any promises how far we'll get. That's why this is a sponsor Z deliverable that isn't tied to the sponsor F milestone in November.
George outlined a few possible next steps (which should probably become child tickets soon):
- George knows a couple of people who are coding Python pluggable transports; one of them is wiretapped with banana phone, another one is the Portland university guys. He wants to prepare a pluggable transport library for them. Roger adds that flash proxy also has a Python part. In general, Roger thinks that looking at other Python pluggable transports and trying to help them all use our framework should be part of this deliverable.
- George thinks that most of the future transports we are thinking of can be handled (performance-wise) by a Python program. He wants to prepare an obfs2-like thing and benchmark it by feeding it with thousands of connections. George wants to see how many of them it will handle (he expects _many_).
- George also wants to prepare a very lite managed proxy library, which will read environment variables etc. He also wants to write a very simple pluggable transport in Python which will use that managed proxy library.
- George wants to evaluate py2exe (and the other similar things).
Here are a few more random notes which seem relevant:
- Nick suggests that we could do something minimalistic with twisted. George hopes to be able to use all the other web protocols baked in twisted for transports.
- George will try to learn the truth about bytearrays and cryptographic material overwriting. The idea is that by using bytearrays in Python one can actually overwrite cryptographic material "securely".George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/34Make available our censorship snapshot over a domain-fronted URL2021-10-20T12:13:04ZPhilipp Winterphw@torproject.orgMake available our censorship snapshot over a domain-fronted URLOver at tpo/community/outreach#28531, we're working on a [censorship snapshot](https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/) that summarises where and how Tor is blocked. The idea is that Tor Browser will use th...Over at tpo/community/outreach#28531, we're working on a [censorship snapshot](https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/) that summarises where and how Tor is blocked. The idea is that Tor Browser will use this snapshot to help the user figure out what circumvention method works. The question is: how does Tor Browser get this snapshot? It's not a good idea to hard-code it into Tor Browser because it will take a long time to update it. It's probably better for Tor Browser to fetch the snapshot each time it starts.
To guarantee that Tor Browser can always get the snapshot, even in the face of censorship, we should serve it over a domain-fronted endpoint, like we do for moat. There are several ways in which we could serve the snapshot:
* Polyanthum, the host that runs BridgeDB and rdsys, runs an Apache reverse proxy. We could serve the snapshot directly over Apache, which is probably the simplest solution.
* We could also teach rdsys how to serve the snapshot. Technically, the snapshot is a resource and rdsys is our resource distribution system.
Whatever solution we go with, we should make sure that we can easily and quickly update the snapshot if we learn of a new censorship event.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/2755Reconsider BridgeDB's pool assignment file implementation and deployment2020-06-27T13:43:33ZKarsten LoesingReconsider BridgeDB's pool assignment file implementation and deploymentWhile deploying the new BridgeDB feature that dumps bridge pool assignments to disk, I had two ideas for improving that feature. Neither of these ideas are critical, and I wanted to see how well the current implementation works before m...While deploying the new BridgeDB feature that dumps bridge pool assignments to disk, I had two ideas for improving that feature. Neither of these ideas are critical, and I wanted to see how well the current implementation works before making it even more perfect. Maybe we should revisit these ideas in a month or two from now.
- We only write to assignments.log after parsing a new network status file, but not after dumping unallocated bridges to file buckets. That means we might miss the fact that, say, Twitter distributes new bridges for up to 30 minutes between dumping to file buckets and reading the next network status. Does that matter? Should we also write to assignments.log after dumping to file buckets?
- Appending to a single assignments.log file and rsyncing that to the host that sanitizes it won't scale forever. We could run a monthly or weekly cronjob that runs `"mv assignments.log assignments.log.old"`. metrics-db can handle multiple input files and will read both files, as long as they are rsync'ed correctly.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/20216Iran blocking of direct users, 2016-08 and 2016-092021-07-09T18:29:19ZDavid Fifielddcf@torproject.orgIran blocking of direct users, 2016-08 and 2016-09
Direct users in Iran dropped from 8,000 to 2,000 between 2016-08-20 and 2016-08-23. The numbers recovered to 4,000, then crashed to 400 on 2016-09-03 and 2016-09-04.
![userstats-relay-country-ir-2016-06-24-2016-09-22-off.png](uploads/...
Direct users in Iran dropped from 8,000 to 2,000 between 2016-08-20 and 2016-08-23. The numbers recovered to 4,000, then crashed to 400 on 2016-09-03 and 2016-09-04.
![userstats-relay-country-ir-2016-06-24-2016-09-22-off.png](uploads/userstats-relay-country-ir-2016-06-24-2016-09-22-off.png) [link](https://metrics.torproject.org/userstats-relay-country.html?start=2016-06-24&end=2016-09-22&country=ir&events=off)
_Edit 2016-10-04: the bridge changes below, on further investigation, appear to be unrelated to anything done by Iran._
Looking at bridge users, there is an increase right around 2016-08-20, the time of the first blocking, then an abrupt return to previous levels around 2016-09-03, the time of the second blocking.
![userstats-bridge-country-ir-2016-06-24-2016-09-22.png](uploads/userstats-bridge-country-ir-2016-06-24-2016-09-22.png) [link](https://metrics.torproject.org/userstats-bridge-country.html?start=2016-06-24&end=2016-09-22&country=ir)
Looking at the graph of bridge users by transport, obfs4 continued working while obfs3 and vanilla were blocked.
![userstats-bridge-combined-ir-2016-06-24-2016-09-22.png](uploads/userstats-bridge-combined-ir-2016-06-24-2016-09-22.png) [link](https://metrics.torproject.org/userstats-bridge-combined.html?start=2016-06-24&end=2016-09-22&country=ir)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12766Disable TLSv1.1 and TLSv1.2 in the Firefox helper2020-06-27T13:44:20ZDavid Fifielddcf@torproject.orgDisable TLSv1.1 and TLSv1.2 in the Firefox helperWith legacy/trac#11253, Tor Browser's Firefox config has TLSv1.1 and TLSv1.2 turned on. If meek-http-helper (browser TLS camouflage) sends Firefox 24 ciphersuites but uses TLSv1.1 or TLSv1.2, then it will look weird, because as I underst...With legacy/trac#11253, Tor Browser's Firefox config has TLSv1.1 and TLSv1.2 turned on. If meek-http-helper (browser TLS camouflage) sends Firefox 24 ciphersuites but uses TLSv1.1 or TLSv1.2, then it will look weird, because as I understand it, mainline Firefox 24 has TLSv1.1 and TLSv1.2 disabled. ([[doc/meek#Sampleclienthellos]] corroborates that ordinary Firefox 24 uses TLSv1.0 when connecting to Google.)
We also need to remember to turn TLSv1.1 and TLSv1.2 back on when they get enabled in the next ESR...David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/29296Look into alternatives for distributing bridge info to clients2021-07-29T15:03:24ZCecylia BocovichLook into alternatives for distributing bridge info to clientsThe traditional way of distributing bridge information is to give bridge IP/connection information through BridgeDB and add that information to the Tor Browser configuration.
Snowflake and meek handle "bridge" information differently at...The traditional way of distributing bridge information is to give bridge IP/connection information through BridgeDB and add that information to the Tor Browser configuration.
Snowflake and meek handle "bridge" information differently at the client side, and we might like to consider a broader application of the Snowflake/broker style of distributing bridges. To do so, we should look into what changes we need to make at the client side to make this distribution easier.Sponsor 30 - Objective 2.3https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/7153Don't require pluggable transport proxies to be SOCKS proxies2021-06-17T14:30:51ZKarsten LoesingDon't require pluggable transport proxies to be SOCKS proxies(Re-using text from Zack Weinberg for this description.)
There are pluggable transport proxies that don't actually act as a SOCKS proxy. For example, StegoTorus has its own configuration; it ignores everything told it in the SOCKS dial...(Re-using text from Zack Weinberg for this description.)
There are pluggable transport proxies that don't actually act as a SOCKS proxy. For example, StegoTorus has its own configuration; it ignores everything told it in the SOCKS dialogue and always connects to the bridge that it knows about. If you want multiple StegoTorus bridges accessible to your Tor client, you need multiple `"ClientTransportPlugin ... exec"` specifications. This is only going to get worse when they move away from having everything set up on StegoTorus' command line, which has been direly needed for some time now.
Theoretically all of StegoTorus' configuration _could_ be encapsulated in the SOCKS key-value-pairs-in-the-password hack that's described in 180-pluggable-transport.txt, but they never implemented that and they don't want to. They want to rip out all of the SOCKS code, in fact. The way they want it to work is
```
Bridge storus1 direct [keyid=...]
ClientTransportPlugin storus1 direct 127.0.0.1:8888
```
In this case, `'storus1'` is *not* a "method", it's a human-readable identifier for the bridge that Tor will be connected to if it starts talking the OR protocol -- with no initial SOCKS exchange! -- on 127.0.0.1:8888.
`"direct"` should also be valid in CMETHOD/SMETHOD lines for the proxy-management protocol, with the same semantics. Zack says he hasn't really thought through how the server side of this stuff ought to work.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/23209When I opened Tor Launcher and changed my pluggable transport to snowflake a ...2022-07-09T04:20:15ZTracWhen I opened Tor Launcher and changed my pluggable transport to snowflake a message from my firewall popped upWhen I opened Tor Launcher and changed my pluggable transport to snowflake a message from my firewall popped up, it said "do you want to allow snowflake-client to allow incoming connections", some users may be concerned because this mess...When I opened Tor Launcher and changed my pluggable transport to snowflake a message from my firewall popped up, it said "do you want to allow snowflake-client to allow incoming connections", some users may be concerned because this message has never popped up when using Tor Browser Bundle.
TBB 7.5a4
**Trac**:
**Username**: Dbryrtfbcbhgfhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/2895BridgeDB assumes that cached-descriptors[.new] are in chronological order2021-07-09T18:27:09ZKarsten LoesingBridgeDB assumes that cached-descriptors[.new] are in chronological orderWhen parsing bridge descriptors, BridgeDB assumes that descriptors in the bridge descriptor files are in chronological order and that descriptors in cached-descriptors.new are newer than those in cached-descriptors. If this is not the c...When parsing bridge descriptors, BridgeDB assumes that descriptors in the bridge descriptor files are in chronological order and that descriptors in cached-descriptors.new are newer than those in cached-descriptors. If this is not the case, BridgeDB overwrites a bridge's IP address and OR port with those from an older descriptor.
I think that the current cached-descriptors* files that Tor produces always have descriptors in chronological order. But once we change that, e.g., when trying to limit the number of descriptors that Tor memorizes, BridgeDB will behave funny.
We should look at the bridge descriptor that is referenced from the bridge network status by its publication time and ignore all other bridge descriptors from the same bridge.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/7167Combine traffic obfuscation with address diversity of flash proxy2020-06-27T13:44:07ZKarsten LoesingCombine traffic obfuscation with address diversity of flash proxy(Quoting text written by David Fifield for this ticket description.)
Find out what current DPI capabilities are with respect to WebSocket, at least through product literature.
Find out what existing, popular, WebSocket applications are...(Quoting text written by David Fifield for this ticket description.)
Find out what current DPI capabilities are with respect to WebSocket, at least through product literature.
Find out what existing, popular, WebSocket applications are used (chat, video, games?) that will be collateral damage to block. Write a short report on 1) how common they are, and 2) what their traffic looks like.
Implement a transport with an obfs2 stream transported over WebSocket.
We can imagine a new "obfs2-in-websocket" transport, but it might be a better design to allow chaining of proxies that don't necessarily have to know about one another. So you might have something like this on the client:
```
ClientTransportPlugin websocket socks4 127.0.0.1:9001
ClientTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --managed
Bridge obfs2|websocket 0.0.1.0:1
```
On the server:
```
ServerTransportPlugin websocket proxy 127.0.0.1:9901
ServerTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --managed
# And then some new configuration to say that things received on
# port 9901 need to be forwarded to the local obfsproxy port.
# Port 9901 won't be able to be used for plain websocket
# connections, and I guess this will have to be reflected in the
# descriptor somewhere.
```
A client tor can probably managed these chained proxies using SOCKS-in-SOCKS. There's a brief note on chaining proxies here: https://trac.torproject.org/projects/tor/ticket/2841#comment:12
See what other obfuscation possibilities exist. I don't think that TLS-wrapped WebSockets work for us (http://archives.seul.org/or/talk/Oct-2012/msg00190.html), but I haven't thought about it exhaustively. Replacing WebSocket with HTTP requests (the flash proxy POSTs bodies to both the client and the relay, and receives response bodies) would likely work, and would allow fuller control of the payloads (whereas with WebSocket we cannot escape the WebSocket framing). We gave up on using Flash, but Flash sockets allow us to control exactly what goes on the wire, except for an initial cross-domain request.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/23257Snowflake doesn't connect on the CalVisitor network2022-07-09T04:20:15ZDavid Fifielddcf@torproject.orgSnowflake doesn't connect on the CalVisitor networkSnowflake doesn't work on [one of the wireless networks](https://telecom.berkeley.edu/calvisitor) at UC Berkeley. It sends an offer and receives an answer, but then hangs here:
```
2017/08/16 13:56:38 ---- Handler: snowflake assigned ---...Snowflake doesn't work on [one of the wireless networks](https://telecom.berkeley.edu/calvisitor) at UC Berkeley. It sends an offer and receives an answer, but then hangs here:
```
2017/08/16 13:56:38 ---- Handler: snowflake assigned ----
2017/08/16 13:56:38 Buffered 203 bytes --> WebRTC
2017/08/16 13:56:43 Traffic Bytes (in|out): 0 | 203 -- (0 OnMessages, 1 Sends)
```
I initially suspected that it had something to do with the network not assigning a public IPv4 address, only a public IPv6 address. I moved our existing proxy-go instances to a host with an IPv6 address, and that didn't help.
Here's the part of the log where client gathers its candidates. Notice the IPv6 address 2607:f140:6000:2:c53e:4d3e:19d5:d94c and the IPv4 address 10.105.136.190.
```
2017/08/16 13:55:58 WebRTC: DataChannel created.
2017/08/16 13:55:58 candidate:1109156821 1 udp 2122262783 2607:f140:6000:2:c53e:4d3e:19d5:d94c 56748 typ host generation 0 ufrag 3h4p network-id 2 network-cost 50
2017/08/16 13:55:58 candidate:2027054270 1 udp 2122194687 10.105.136.190 61395 typ host generation 0 ufrag 3h4p network-id 1 network-cost 50
2017/08/16 13:55:58 candidate:211787557 1 tcp 1518283007 2607:f140:6000:2:c53e:4d3e:19d5:d94c 49259 typ host tcptype passive generation 0 ufrag 3h4p network-id 2 network-cost 50
2017/08/16 13:55:58 candidate:911317070 1 tcp 1518214911 10.105.136.190 49260 typ host tcptype passive generation 0 ufrag 3h4p network-id 1 network-cost 50
2017/08/16 13:55:59 SOCKS accepted: {0.0.3.0:1 map[]}
```
Here's an abridged form of the answer. Notice how the candidates (`a=candidate:`) include both IPv6 2a00:c6c0:0:151:4:8f94:69f5:7c01 and IPv4 37.218.242.151. However, the connection address (`c=`) is the IPv4 address.
```
o=- 5000276783403536546 2 IN IP4 127.0.0.1
m=application 41242 DTLS/SCTP 5000
c=IN IP4 37.218.242.151
a=candidate:836092752 1 udp 2122262783 2a00:c6c0:0:151:4:8f94:69f5:7c01 40571 typ host generation 0 network-id 1 network-cost 50
a=candidate:404726760 1 udp 2122194687 37.218.242.151 41242 typ host generation 0 network-id 2 network-cost 50
a=candidate:2136358816 1 tcp 1518283007 2a00:c6c0:0:151:4:8f94:69f5:7c01 39103 typ host tcptype passive generation 0 network-id 1 network-cost 50
a=candidate:1453088536 1 tcp 1518214911 37.218.242.151 49703 typ host tcptype passive generation 0 network-id 2 network-cost 50
```
Is this one of those weird NAT cases where a TURN server is needed? Is that why it's not working? The CalVisitor does block some applications like IMAP.
I tested this with Tor Browser 7.5a4 for mac.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/3015Enhance bucket functionality2020-06-27T13:43:33ZChristian FrommeEnhance bucket functionalityThe bucket mechanism in BridgeDB currently lacks two important features:
a) Only give out bridges that are `fresh`, meaning those that have been seen recently enough to be considered worth giving out.
b) Give the user the opportunity to...The bucket mechanism in BridgeDB currently lacks two important features:
a) Only give out bridges that are `fresh`, meaning those that have been seen recently enough to be considered worth giving out.
b) Give the user the opportunity to add a number of fresh bridges to a certain bucket pool each time BridgeDB -d is run. This makes it much easier to only mail a delta to a given bridge distributor person plus gives that user a predictable number of new bridges each time.Isis LovecruftIsis Lovecruft