Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:28:07Zhttps://gitlab.torproject.org/legacy/trac/-/issues/4014Iran filters Tor by ssl handshake, Sept 20112020-06-13T14:28:07ZRoger DingledineIran filters Tor by ssl handshake, Sept 2011Preliminary analysis is that something in the server's ssl hello is causing the connection to get sniped. Presumably another function of our server-side ssl cert.Preliminary analysis is that something in the server's ssl hello is causing the connection to get sniped. Presumably another function of our server-side ssl cert.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4036Tor relays/bridges can detect when they are being filtered by SSL cert2020-06-13T14:13:20ZRoger DingledineTor relays/bridges can detect when they are being filtered by SSL certThe blocking events from Iran in January 2011 and September 2011, and from Syria in mid/late 2011, share a common theme: the client establishes a TCP connection, sends an ssl client hello, and then goes silent.
In theory Tor relays coul...The blocking events from Iran in January 2011 and September 2011, and from Syria in mid/late 2011, share a common theme: the client establishes a TCP connection, sends an ssl client hello, and then goes silent.
In theory Tor relays could track if there's a sudden spike in connections like that from a given country, and report it.
I've put this ticket at 'minor' priority since I think the right plan for us (given all the actual dev tasks we need to do) is to hope that some nice volunteer does it.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4185Bridge easily detected by GFW2020-06-13T14:13:38ZTracBridge easily detected by GFWI tried to setup a bridge relay in USA and access it from China. But it seems their communication can be detected very soon and got filtered by the GFW.
At first I thought it's because the address of my bridge relay got published and l...I tried to setup a bridge relay in USA and access it from China. But it seems their communication can be detected very soon and got filtered by the GFW.
At first I thought it's because the address of my bridge relay got published and leaked to the GFW staffs. But even I set PublishServerDescriptor to 0 in the torrc of bridge the blockade still occurs.
Every bridge relay I setup can only live 1~10 minutes before they got blocked and were no longer accessible in China, used the telnet utility for confirming that.
When the blockade occurs, not only bridges but also normal relays were blocked.
If I change the bridge port (like from 443 to 444) then it can be connected again before the next blockade occurs after 1~10 minutes.
I tried the both stable 0.2.1.x and alpha (0.2.3.5-alpha) release of tor and they were all vulnerable.
Was it a new attack to block tor traffic?
**Trac**:
**Username**: hrimfaxiTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4744GFW probes based on Tor's SSL cipher list2020-06-13T18:30:46ZGeorge KadianakisGFW probes based on Tor's SSL cipher listTim's tests show that GFW is probing v2/v3 bridges based on the Tor cipher list. Tor is using 28 static ciphers (`src/common/ciphers.inc`) for the SSL ClientHello of the v2/v3 link handshakes, and GFW seems to get agitated by them.
The ...Tim's tests show that GFW is probing v2/v3 bridges based on the Tor cipher list. Tor is using 28 static ciphers (`src/common/ciphers.inc`) for the SSL ClientHello of the v2/v3 link handshakes, and GFW seems to get agitated by them.
The question mark in the ticket title reflects the fact that this is not 100% verified, even though Tim dodged probing by simply removing two ciphersuites from `ciphers.inc` [0], when the same ClientHello, but with full ciphers.inc, was always getting probed (IIRC).
Tim said he is gonna look into this soon-ish, so that the question mark can be removed from the title.
In any case, this ticket is to find a good tactic to remove this static fingerprint from Tor's SSL handshake. My patch in [0] might do it, but it doesn't seem very future-proof.
We should probably see what Firefox does, and hope that it doesn't interfere with v2 signalling.
[0]:
```
diff --git a/src/common/ciphers.inc b/src/common/ciphers.inc
index c84620d..99ec494 100644
--- a/src/common/ciphers.inc
+++ b/src/common/ciphers.inc
@@ -111,16 +111,6 @@
#else
XCIPHER(0xc012, TLS1_TXT_ECDHE_RSA_WITH_DES_192_CBC3_SHA)
#endif
-#ifdef SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA
- CIPHER(0x0016, SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA)
-#else
- XCIPHER(0x0016, SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA)
-#endif
-#ifdef SSL3_TXT_EDH_DSS_DES_192_CBC3_SHA
- CIPHER(0x0013, SSL3_TXT_EDH_DSS_DES_192_CBC3_SHA)
-#else
- XCIPHER(0x0013, SSL3_TXT_EDH_DSS_DES_192_CBC3_SHA)
-#endif
#ifdef TLS1_TXT_ECDH_RSA_WITH_DES_192_CBC3_SHA
CIPHER(0xc00d, TLS1_TXT_ECDH_RSA_WITH_DES_192_CBC3_SHA)
#else
```Tor: 0.2.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/6045Ethiopia blocks Tor based on ServerHello2020-06-13T18:30:46ZGeorge KadianakisEthiopia blocks Tor based on ServerHelloEthiopia is blocking Tor by DPIing the ServerHello TLS record. We
found out that changing the ciphersuite selected (from the default
TLS1_TXT_DHE_RSA_WITH_AES_256_SHA (0x0039)) bypasses the censorship.
This is a ticket to see how we can...Ethiopia is blocking Tor by DPIing the ServerHello TLS record. We
found out that changing the ciphersuite selected (from the default
TLS1_TXT_DHE_RSA_WITH_AES_256_SHA (0x0039)) bypasses the censorship.
This is a ticket to see how we can handle this issue. We should also
be think about how #4744 and proposal 198 influence this.
The patch we used during tests removes 0x0039 from `SERVER_CIPHER_LIST`:
https://gitorious.org/mytor/mytor/commit/087de5215cada3320c8494fdc97b87746b45e1cb
A good short-term plan would be to set-up a few patched bridges,
update the blog post, and distribute the patched bridges to anyone who
asks for them.https://gitlab.torproject.org/legacy/trac/-/issues/6140Kazakhstan uses DPI to block Tor2020-06-13T18:30:47ZRuna SandvikKazakhstan uses DPI to block TorTwo blog posts published in the beginning of March talks about Kazakhstan using DPI to block Tor. The posts say that Kazakhstan is identifying and blocking the SSL client key exchange during the setup of an SSL connection. It seems the K...Two blog posts published in the beginning of March talks about Kazakhstan using DPI to block Tor. The posts say that Kazakhstan is identifying and blocking the SSL client key exchange during the setup of an SSL connection. It seems the Kazakhstan firewall finds something unique in the TLS "Server Hello" message as sent by the Tor relay or bridge and therefore blocks subsequent communications. IP address and TCP port are irrelevant to the censorship.
From #6045 (where we discuss Ethiopia blocking Tor based on ServerHello), we know that:
* The normal Tor Browser Bundle with a special bridge works; the bridge with the patch that causes the final hello done TLS record to be sent in a separate packet.
* The three bridges in https://blog.torproject.org/blog/update-censorship-ethiopia are also working in Kazakhstan. These are bridges with a patch that removes 0x0039 from SERVER_CIPHER_LIST.https://gitlab.torproject.org/legacy/trac/-/issues/6149"Censorship-timeline" for Tor2022-07-20T21:00:54ZPhilipp Winterphw@torproject.org"Censorship-timeline" for TorIt was shortly discussed on #tor-dev that some sort of "censorship-timeline" for Tor would be helpful. In particular, this should provide:
* Detailed technical analyses of the censorship mechanisms in place (DPI fingerprints and manufa...It was shortly discussed on #tor-dev that some sort of "censorship-timeline" for Tor would be helpful. In particular, this should provide:
* Detailed technical analyses of the censorship mechanisms in place (DPI fingerprints and manufacturers, traceroutes, ...)
* Code and data to reproduce all experiments
* Tor patches and standalone tools to evade the censorship devices
After all, this timeline should serve as a comprehensive archive for all people interested in how Tor is getting blocked. It should make it easy to answer questions such as _"What happened to Tor in country X back in Y?"_.
There are also some open questions:
* How should the data be structured? In form of a timeline? Or country based? Something else?
* What data should be published and when? Full disclosure too early in the process helps the censors.
* How should it be presented? In a wiki page or a standalone web site?https://gitlab.torproject.org/legacy/trac/-/issues/6246UAE uses DPI to block Tor2020-06-13T18:30:49ZRuna SandvikUAE uses DPI to block TorThe Emirates Telecommunications Corporation, also known as Etisalat, started blocking Tor using DPI on June 25 2012. It seems they are doing something similar to Ethiopia (#6045) and Kazakhstan (#6140), but we should figure out how these...The Emirates Telecommunications Corporation, also known as Etisalat, started blocking Tor using DPI on June 25 2012. It seems they are doing something similar to Ethiopia (#6045) and Kazakhstan (#6140), but we should figure out how these cases are different.
We know that:
* The three bridges in https://blog.torproject.org/blog/update-censorship-ethiopia are working. These are bridges with a patch that removes 0x0039 from SERVER_CIPHER_LIST.https://gitlab.torproject.org/legacy/trac/-/issues/6258The Philippines are blocking Tor?2020-06-13T18:30:49ZPhilipp Winterphw@torproject.orgThe Philippines are blocking Tor?A user mentioned in the [ethiopian blog post](https://blog.torproject.org/blog/update-censorship-ethiopia):
_two of the biggest ISP's here in the philippines blocked tor recently! _
The [statistic for directly connecting users](https...A user mentioned in the [ethiopian blog post](https://blog.torproject.org/blog/update-censorship-ethiopia):
_two of the biggest ISP's here in the philippines blocked tor recently! _
The [statistic for directly connecting users](https://metrics.torproject.org/users.html?graph=direct-users&start=2012-03-31&end=2012-06-29&country=ph&dpi=72#direct-users) indeed shows a sudden drop in usage in the beginning of May. The [bridge usage statistic](https://metrics.torproject.org/users.html?graph=bridge-users&start=2012-03-31&end=2012-06-29&country=ph&dpi=72#bridge-users) shows a suspicious usage drop in the middle of June.
We should analyze the situation.https://gitlab.torproject.org/legacy/trac/-/issues/6651Someone's blocking Tor in Mexico?2020-06-13T18:30:50ZRuna SandvikSomeone's blocking Tor in Mexico?One user in Mexico reported that he is unable to connect to Tor, even with a private bridge. We have enough data to analyze the situation.One user in Mexico reported that he is unable to connect to Tor, even with a private bridge. We have enough data to analyze the situation.Runa SandvikRuna Sandvikhttps://gitlab.torproject.org/legacy/trac/-/issues/7141How is Iran blocking Tor?2020-06-13T18:30:51ZPhilipp Winterphw@torproject.orgHow is Iran blocking Tor?Note that currently it looks like there might be more than just one filtering technique in place. The following was the initial report describing one possible filtering technique and [this comment](https://trac.torproject.org/projects/to...Note that currently it looks like there might be more than just one filtering technique in place. The following was the initial report describing one possible filtering technique and [this comment](https://trac.torproject.org/projects/tor/ticket/7141#comment:8) describes another technique.
----
Some users reported that the Iranian ISP "[Pars Online](https://en.wikipedia.org/wiki/Pars_Online)" is (partially?) blocking Tor.
One user looked into it and believes that Tor is identified based on the server_name extension in the TLS client hello. It looks like DPI boxes extract the domain and do a DNS lookup for it. If the domain resolves and the relay/bridge is listening on port 443, the connection passes. Apparently, an omitted server_name or a server_name rewritten to `www.google.com` passed the filter.
Obfsproxy seems to work.
Some open questions:
* Can we reproduce and verify the existing hypothesis?
* Is this an attempt to only allow HTTPS and no other SSL/TLS-based protocols? Or is it targeting only Tor?
* Can we modify [brdgrd](https://gitweb.torproject.org/brdgrd.git) to evade the server_name extraction?
* Is this type of block limited to Pars Online?Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/7144Implement Bridge Guards and other anti-enumeration defenses2020-08-10T13:46:33ZKarsten LoesingImplement Bridge Guards and other anti-enumeration defenses[Proposal 188](https://gitweb.torproject.org/torspec.git/tree/proposals/188-bridge-guards.txt) specifies Bridge Guards and other anti-enumeration defenses. We should implement this proposal.[Proposal 188](https://gitweb.torproject.org/torspec.git/tree/proposals/188-bridge-guards.txt) specifies Bridge Guards and other anti-enumeration defenses. We should implement this proposal.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7349Obfsbridges should be able to "disable" their ORPort2021-07-29T15:06:00ZGeorge KadianakisObfsbridges should be able to "disable" their ORPortIn the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.
We should spec and implement a torrc option that hides the ORPo...In the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.
We should spec and implement a torrc option that hides the ORPort of obfsbridges.
Maybe it should make the ORPort bind on localhost. But what happens if the transport proxy is not on the same host as the ORPort?Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8097I think tor is blocked by my internet provider2020-06-13T18:30:52ZTracI think tor is blocked by my internet providerSorry, I'm really new to Tor, and proxies/etc. The other day, I downloaded the Tor Bundle for Mac OS X, and it would get stuck at "Establishing an encrypted directory connection".
I added bridges, tried the "Firewall only connects to cer...Sorry, I'm really new to Tor, and proxies/etc. The other day, I downloaded the Tor Bundle for Mac OS X, and it would get stuck at "Establishing an encrypted directory connection".
I added bridges, tried the "Firewall only connects to certain ports" option, and even redownloaded to the 64-bit version. I'm not sure if I'm doing something wrong or I am somehow blocked from Tor? Also, I live in Japan.
Here is an image of how my message log looks: http://i46.tinypic.com/23u8ole.png
**Trac**:
**Username**: 48ineGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/8591GFW actively probes obfs2 bridges2020-06-13T18:30:53ZPhilipp Winterphw@torproject.orgGFW actively probes obfs2 bridgesIt looks like the GFW is now actively probing obfs2. After hearing rumours yesterday, I wasn't able to reproduce this. Today, however, I got my private obfs2 bridge probed just milliseconds after my own connection from China. I got hit b...It looks like the GFW is now actively probing obfs2. After hearing rumours yesterday, I wasn't able to reproduce this. Today, however, I got my private obfs2 bridge probed just milliseconds after my own connection from China. I got hit by two random Chinese addresses as we already know it from the Tor probing. After the probing, my obfs2 connection timed out and the SYN/ACK segments from the bridge were dropped when trying to establish a new connection. I could reproduce all of this several times.
I haven't tested obfs3 yet and I suppose we can skip the old looking-for-the-fingerprint game. Depending on what protocols they are trying to detect, they might have to probe several times since it's not clear what's behind all that entropy. It might be obfs2, obfs3 or VPN PSK and perhaps even more protocols.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/9406Deploy ScrambleSuit2014-02-03T23:45:32ZPhilipp Winterphw@torproject.orgDeploy ScrambleSuitThis ticket should document what remains to be done to deploy the [ScrambleSuit](http://www.cs.kau.se/philwint/scramblesuit/) pluggable transport protocol.
* ~~Obtain the shared secret as the server~~ (#8979)
* ~~ScrambleSuit needs to...This ticket should document what remains to be done to deploy the [ScrambleSuit](http://www.cs.kau.se/philwint/scramblesuit/) pluggable transport protocol.
* ~~Obtain the shared secret as the server~~ (#8979)
* ~~ScrambleSuit needs to learn Tor's data directory since it writes persistent data to disk. This boils down to slightly modifying pyptlib and obfsproxy.~~ (#9815)
* ~~BridgeDB must support shared secrets~~ (#9013)
* ~~Somebody needs to have a look at the source code. So far, I'm the only one familiar with it.~~ (asn had a look at it)
* The implementation must be tested on Windows and Mac.
* If all of the above is done, we can create a pluggable TBB with a hard-coded ScrambleSuit bridge for testing.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/9498Allow bridge descriptors to contain no address if they are not being published2020-06-13T14:31:06ZTracAllow bridge descriptors to contain no address if they are not being publishedTo strengthen an "isolating proxy"-style approach to client security, I'd like to allow a Tor bridge node to not reveal its external address(es) in its bridge descriptor. The following patch leaves the address as 0.0.0.0 when it's not g...To strengthen an "isolating proxy"-style approach to client security, I'd like to allow a Tor bridge node to not reveal its external address(es) in its bridge descriptor. The following patch leaves the address as 0.0.0.0 when it's not going to be published:
```
diff --git a/src/or/router.c b/src/or/router.c
index 1063eda..30749b9 100644
--- a/src/or/router.c
+++ b/src/or/router.c
@@ -1772,7 +1772,7 @@ router_rebuild_descriptor(int force)
{
routerinfo_t *ri;
extrainfo_t *ei;
- uint32_t addr;
+ uint32_t addr = 0;
char platform[256];
int hibernating = we_are_hibernating();
const or_options_t *options = get_options();
@@ -1780,11 +1780,16 @@ router_rebuild_descriptor(int force)
if (desc_clean_since && !force)
return 0;
- if (router_pick_published_address(options, &addr) < 0 ||
- router_get_advertised_or_port(options) == 0) {
+ /* If we're not trying to publish our descriptor, it's OK to use 0.0.0.0
+ * as the address therein.
+ */
+ if ((options->PublishServerDescriptor_ != NO_DIRINFO) &&
+ (router_pick_published_address(options, &addr) < 0 ||
+ router_get_advertised_or_port(options) == 0)) {
/* Stop trying to rebuild our descriptor every second. We'll
* learn that it's time to try again when ip_address_changed()
* marks it dirty. */
```
**Trac**:
**Username**: nwfTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9729Make bridges publish additional ORPort addresses in their descriptor2020-06-13T14:31:56ZTracMake bridges publish additional ORPort addresses in their descriptorI run Tor 0.2.4.17-rc as a bridge configured with multiple IPv4 addresses and one ORPort line for each, like so:
ORPort <n1>:443
ORPort <n2>:443
...
ORPort <nN>:443
When starting tor, the log will show that only <n1> is self-tested and...I run Tor 0.2.4.17-rc as a bridge configured with multiple IPv4 addresses and one ORPort line for each, like so:
ORPort <n1>:443
ORPort <n2>:443
...
ORPort <nN>:443
When starting tor, the log will show that only <n1> is self-tested and a bridge descriptor is published:
[notice] Now checking whether ORPort <n1>:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Tor should publish bridge descriptors for all the available addresses and the bridge authorities should probably put them into pools of different confidentiality levels.
For clarity, the documentation should explain Tor's bandwidth allocation as configured with Relay(Bandwidth|Burst)Rate (per address or total).
**Trac**:
**Username**: sqrt2Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/12727Vanilla Tor Connectivity Issues In Iran -- Directory Authorities Blocked?2020-06-15T23:19:23ZTracVanilla Tor Connectivity Issues In Iran -- Directory Authorities Blocked?Social media users and @mttp report that vanilla Tor no longer works.
Confirmed that Tor v0.2.2.35 out of the box fails to progress beyond:
```
Bootstrapped 5%: Connecting to directory server.
```
Same behavior confirmed on v0.2.4.23 ...Social media users and @mttp report that vanilla Tor no longer works.
Confirmed that Tor v0.2.2.35 out of the box fails to progress beyond:
```
Bootstrapped 5%: Connecting to directory server.
```
Same behavior confirmed on v0.2.4.23 built from source.
Fetched random bridge from bridges.tpo and applied to torrc, quickly bootstrapped through bridge and successfully confirmed access through check.tpo.
With stem-listed DAs, wrote python script to check connectivity to DAs based on a simple TCP connect(). For OR port, if successful, the cert sha1 was retrieved.
Connect Test Results for directory authorities:
```
Tonga 82.94.251.203 (OR: 443 , 14:C7:A1:55:82:1C:D4:81:5C:55:8F:25:E5:7F:CF:F0:3E:BF:67:30 ), (Dir: 80 , successful )
turtles 76.73.17.194 (OR: 9090 , timeout ), (Dir: 9030 , timeout )
dizum 194.109.206.212 (OR: 443 , timeout ), (Dir: 80 , timeout )
gabelmoo 212.112.245.170 (OR: 443 , timeout ), (Dir: 80 , timeout )
urras 208.83.223.34 (OR: 80 , timeout ), (Dir: 443 , timeout )
tor26 86.59.21.38 (OR: 443 , timeout ), (Dir: 80 , timeout )
moria1 128.31.0.39 (OR: 9101 , 97:4B:DD:96:D3:21:1F:52:F9:8C:0A:BB:7C:27:3B:19:7F:02:5A:1D ), (Dir: 9131 , successful )
dannenberg 193.23.244.244 (OR: 443 , timeout ), (Dir: 80 , timeout )
Faravahar 154.35.32.5 (OR: 443 , timeout ), (Dir: 80 , timeout )
maatuska 171.25.193.9 (OR: 80 , timeout ), (Dir: 443 , timeout )
```
TCP traceroute to Faravahar dies at the Telecommunications Company of Iran for all TCP ports (ICMP is fine).
```
traceroute to 154.35.32.5 (154.35.32.5), 30 hops max, 60 byte packets
1 [hop-1, responsive]
2 [hop-2, unresponsive]
3 [hop-3, responsive]
4 [hop-4, responsive]
5 78.38.255.100 (78.38.255.100) 1.300 ms 1.127 ms 1.334 ms
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
[...]
```
Taken against the successful ICMP traceroute, the next hop hits 10.10.53.209 then exits Iran through PCCW Global. Based on the TCI's history in past disruptions, that this would occur at the international gateway is unsurprising and indicates that all users on unprivileged networks are likely blocked unless using a bridge.
For posterity, 10.10.53.209 only has one open port, HTTP on 80, which returns the "level 15 access" authentication message indicative that it is a Cisco router.
**Trac**:
**Username**: cdahttps://gitlab.torproject.org/legacy/trac/-/issues/14835Script to upload Tor Browser to Github2020-06-21T18:05:15ZIsrael LeivaScript to upload Tor Browser to GithubI have made a preliminary version of a script to upload Tor Browser to GitHub. This should be integrated with the work done in #14744, as it should be run after fetching the latest Tor Browser. After the Tor Browser files have been fetch...I have made a preliminary version of a script to upload Tor Browser to GitHub. This should be integrated with the work done in #14744, as it should be run after fetching the latest Tor Browser. After the Tor Browser files have been fetched, this script copy the files to a new directory called VERSION, where VERSION is the version of the latest Tor Browser. Then it commits and push the changes to GitHub, all of this done via system calls to git, and with the assumption that a GitHub repository has been previously created and synchronized in the machine that the script is executed. After that, the GitHub API is used to get the links of the files recently pushed and create a links file with that info.
You can check a sample links file [here](https://github.com/ilv/gettor/blob/master/providers/github.links) and the script bundles2github [here](https://github.com/ilv/gettor/blob/master/upload/bundles2github.py). Please note that the uploaded files are plain text, so if you open the links you will only see raw text. A sample link for a binary file can be found [here](https://github.com/ilv/gettor/raw/master/upload/tor-browser-linux32-4.0.2_en-US.tar.xz).
In order to make the git commits and push without problems or user interaction, one should previously create a SSH key and link that key to GitHub. Similarly, to interact with the GitHub API without using basic credentials (user/pass), one should previously create a token in GitHub. For the tests I did a personal access token was enough.
This was done for the purposes of #14114. Reviews welcome!Israel LeivaIsrael Leivahttps://gitlab.torproject.org/legacy/trac/-/issues/15198Cyberoam blocking connections to Tor2020-06-13T18:30:56ZJacob AppelbaumCyberoam blocking connections to TorI'm currently in Istanbul, Turkey at a local university. The network blocks connections to the Tor network (using Tails) with a layered approach to censorship, I suspect.
I've tried to configure regular bridges, obfs2,3,scramblesuit PT ...I'm currently in Istanbul, Turkey at a local university. The network blocks connections to the Tor network (using Tails) with a layered approach to censorship, I suspect.
I've tried to configure regular bridges, obfs2,3,scramblesuit PT and direct connections. None appear to function. I am able to ssh out - so I can connect to Tor by binding a local SOCKS proxy and configuring Tor to connect over a SOCKS proxy. That is how I've filed this bug report.
The Cyberoam device is clearly acting as a MITM - it is highly annoying. It is a captive portal, which is easy to bypass with a login/password (ironically, not deployed with https!), after the captive portal, it filters conections by protocol, ip address and port number - I haven't yet fingerprinted the device upstream but I'll add information as I find it.https://gitlab.torproject.org/legacy/trac/-/issues/20216Iran blocking of direct users, 2016-08 and 2016-092020-06-13T18:31:00ZDavid 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/legacy/trac/-/issues/20348Allot Communications blocking of vanilla Tor, obfs4, and meek in Kazakhstan, ...2021-03-27T04:55:11ZDavid Fifielddcf@torproject.orgAllot Communications blocking of vanilla Tor, obfs4, and meek in Kazakhstan, starting 2016-06At the beginning of June 2016, direct users in Kazakhstan fell, while bridge users simultaneously rose. Thereafter, bridge users slowly declined.
![userstats-relay-country-kz-2016-01-01-2016-10-12-off.png](uploads/userstats-relay-count...At the beginning of June 2016, direct users in Kazakhstan fell, while bridge users simultaneously rose. Thereafter, bridge users slowly declined.
![userstats-relay-country-kz-2016-01-01-2016-10-12-off.png](uploads/userstats-relay-country-kz-2016-01-01-2016-10-12-off.png) [link](https://metrics.torproject.org/userstats-relay-country.html?start=2016-01-01&end=2016-10-12&country=kz&events=off)
![userstats-bridge-country-kz-2016-01-01-2016-10-12.png](uploads/userstats-bridge-country-kz-2016-01-01-2016-10-12.png) [link](https://metrics.torproject.org/userstats-bridge-country.html?start=2016-01-01&end=2016-10-12&country=kz)
The mainly used transport was obfs4.
![userstats-bridge-combined-kz-2016-01-01-2016-10-12.png](uploads/userstats-bridge-combined-kz-2016-01-01-2016-10-12.png) [link](https://metrics.torproject.org/userstats-bridge-combined.html?start=2016-01-01&end=2016-10-12&country=kz)
The dip in bridge users during September was likely not related to anything happening in Kazakhstan, but is an artifact of the changeover of bridge authorities. See https://lists.torproject.org/pipermail/metrics-team/2016-September/000217.html.https://gitlab.torproject.org/legacy/trac/-/issues/20419iran has banned tor successfully2020-06-13T18:31:07ZTraciran has banned tor successfully
using tor in iran in these days is impossible.
look likes gov finally find the way to block all tor traffic in iran.
even bridges are not working.
**Trac**:
**Username**: ufd33
using tor in iran in these days is impossible.
look likes gov finally find the way to block all tor traffic in iran.
even bridges are not working.
**Trac**:
**Username**: ufd33https://gitlab.torproject.org/legacy/trac/-/issues/20785Block of some direct users in Saudi Arabia, 2016-11-202020-06-13T18:31:09ZDavid Fifielddcf@torproject.orgBlock of some direct users in Saudi Arabia, 2016-11-20On 2016-11-20, the number of direct users dropped from about 8000 to about 5500. There was a simultaneous increase in bridge users (mostly obfs4) from about 500 to over 1200.
One month later, on 2016-12-22, the number of bridge users dr...On 2016-11-20, the number of direct users dropped from about 8000 to about 5500. There was a simultaneous increase in bridge users (mostly obfs4) from about 500 to over 1200.
One month later, on 2016-12-22, the number of bridge users dropped again, almost back to where it was before.
![userstats-relay-country-sa-2016-08-28-2017-06-01-off.png](uploads/userstats-relay-country-sa-2016-08-28-2017-06-01-off.png) [link](https://metrics.torproject.org/userstats-relay-country.html?start=2016-08-28&end=2017-06-01&country=sa&events=off)
![userstats-bridge-country-sa-2016-08-28-2017-06-01.png](uploads/userstats-bridge-country-sa-2016-08-28-2017-06-01.png) [link](https://metrics.torproject.org/userstats-bridge-country.html?start=2016-08-28&end=2017-06-01&country=sa)
![userstats-bridge-combined-sa-2016-08-28-2017-06-01.png](uploads/userstats-bridge-combined-sa-2016-08-28-2017-06-01.png) [link](https://metrics.torproject.org/userstats-bridge-combined.html?start=2017-06-01&end=2016-11-26&country=sa)https://gitlab.torproject.org/legacy/trac/-/issues/20907Blocking of public relays in Belarus, 2016-12-012020-06-13T18:31:10ZDavid Fifielddcf@torproject.orgBlocking of public relays in Belarus, 2016-12-01Direct users decreased from 5,500 to 3,000 over a few days starting on November 30 or December 1. Bridge users simultaneously increased, from 250 to 2,000.
OONI blog post: [urandom.pcap: Belarus (finally) bans Tor](https://ooni.torproje...Direct users decreased from 5,500 to 3,000 over a few days starting on November 30 or December 1. Bridge users simultaneously increased, from 250 to 2,000.
OONI blog post: [urandom.pcap: Belarus (finally) bans Tor](https://ooni.torproject.org/post/belarus-fries-onion/):
> 1. Tor directory authorities are not blocked
> 2. Public onion routers have their ORPort blocked by TCP RST injection
> 3. The onion routers’ DirPort is not blocked
> 4. Plain-old non-obfuscated Tor Bridges from BridgeDB circumvent the interference
> 5. Beltelecom (or its upstream) has strange configuration of the networking gear injecting reset packets
![userstats-relay-country-by-2016-09-07-2016-12-11-off.png](uploads/userstats-relay-country-by-2016-09-07-2016-12-11-off.png) [link](https://metrics.torproject.org/userstats-relay-country.html?start=2016-09-07&end=2016-12-11&country=by&events=off)
![userstats-bridge-country-by-2016-09-07-2016-12-11.png](uploads/userstats-bridge-country-by-2016-09-07-2016-12-11.png) [link](https://metrics.torproject.org/userstats-bridge-country.html?start=2016-09-07&end=2016-12-11&country=by)
![userstats-bridge-combined-by-2016-09-07-2016-12-11.png](uploads/userstats-bridge-combined-by-2016-09-07-2016-12-11.png) [link](https://metrics.torproject.org/userstats-bridge-combined.html?start=2016-09-07&end=2016-12-11&country=by)https://gitlab.torproject.org/legacy/trac/-/issues/21014Turkey blocking of direct connections, 2016-12-122021-03-27T04:55:11ZNima FatemiTurkey blocking of direct connections, 2016-12-12Turkey Blocks article: https://turkeyblocks.org/2016/12/18/tor-blocked-in-turkey-vpn-ban/
After getting some reports on twitter about Tor being blocked in Turkey and some chat on IRC, <bypassemall> aka <trdpi> aka <kzdpi> ran some tests...Turkey Blocks article: https://turkeyblocks.org/2016/12/18/tor-blocked-in-turkey-vpn-ban/
After getting some reports on twitter about Tor being blocked in Turkey and some chat on IRC, <bypassemall> aka <trdpi> aka <kzdpi> ran some tests and found some interesting information about how Turkey is blocking vanilla Tor connections. I paste their findings here:
```
16:48 < trdpi> 10 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE
16:48 < trdpi> after less than 10 seconds
...
16:55 < trdpi> this isp injects rst it seems
16:56 < trdpi> to both side, as i got 2 rst one legit and 2 not
16:57 < mrphs> oh apparently today is an special day in turkey
...
17:00 < trdpi> telneting to or port, no rsts. it triggered by something more than ip:port connection
17:01 < trdpi> yay, window trick for split req works for tr
17:02 < trdpi> magic tool allows to bypass vanilla tor censorship
17:04 < trdpi> so it's about ciphersuits or something
17:07 < trdpi> it's like kz, but obfs4 works
17:07 < trdpi> and kz do not rsts
17:07 < trdpi> it controlls connection
17:07 < trdpi> and tr like do not controlls and to inject fraud only
```https://gitlab.torproject.org/legacy/trac/-/issues/22369Increase of users in Ukraine due to block of Russia-based services2020-06-13T18:31:15ZDavid Fifielddcf@torproject.orgIncrease of users in Ukraine due to block of Russia-based servicesThere was a large and sudden increase in users from Ukraine, both relay and bridge, on 2017-05-16.
It is probably related to a blockage by Ukraine of some Russia-based sites including VKontakte and Mail.ru:
* https://www.rt.com/busines...There was a large and sudden increase in users from Ukraine, both relay and bridge, on 2017-05-16.
It is probably related to a blockage by Ukraine of some Russia-based sites including VKontakte and Mail.ru:
* https://www.rt.com/business/388502-ukraine-bans-vk-yandex/ ([archive link](https://web.archive.org/web/20170524224004/https://www.rt.com/business/388502-ukraine-bans-vk-yandex/))
Other links:
* [reddit post](https://www.reddit.com/r/TOR/comments/6c9ig1)
* [tor-talk thread](https://lists.torproject.org/pipermail/tor-talk/2017-May/043205.html)
![userstats-relay-country-ua-2017-05-01-2017-07-06-off.png](uploads/userstats-relay-country-ua-2017-05-01-2017-07-06-off.png)[link](https://metrics.torproject.org/userstats-relay-country.html?start=2017-05-01&end=2017-07-06&country=ua&events=off)
![userstats-bridge-country-ua-2017-05-01-2017-07-06.png](uploads/userstats-bridge-country-ua-2017-05-01-2017-07-06.png) [link](https://metrics.torproject.org/userstats-bridge-country.html?start=2017-05-01&end=2017-07-06&country=ua&events=off)
![userstats-bridge-combined-ua-2017-05-01-2017-07-06.png](uploads/userstats-bridge-combined-ua-2017-05-01-2017-07-06.png) [link](https://metrics.torproject.org/userstats-bridge-combined.html?start=2017-05-01&end=2017-07-06&country=ua&events=off)
There was also a spike in Tor Browser downloads for the en-US and ru locales.
![webstats-tb-locale-2017-05-01-2017-07-06.png](uploads/webstats-tb-locale-2017-05-01-2017-07-06.png) [link](https://metrics.torproject.org/webstats-tb-locale.html?start=2017-05-01&end=2017-07-06)https://gitlab.torproject.org/legacy/trac/-/issues/23280Censorship resistant onion sites2020-06-13T15:12:51ZcypherpunksCensorship resistant onion sitesCurrently HSDir and Introduction Point are in position to block a onion
site if they want. HSDirs just see the site's address in plaintext and
Introduction Point can check the site in HSDirs to find records related
to the site and remove...Currently HSDir and Introduction Point are in position to block a onion
site if they want. HSDirs just see the site's address in plaintext and
Introduction Point can check the site in HSDirs to find records related
to the site and remove such records from themselves.
So, if all hsdirs OR all Introduction Points want to block the site X,
they can.
prop224 makes onion site names less discoverable, but once discovered,
they can be removed in exactly the same way.
I believe that a system that is resistant to censoring certain sites
must satisfy the following condition: nobody except the client and the
site can distinguish activities related to the site. Not hsdirs, not
Introduction Points, literally nobody.
Here is my proposal of a protocol which seems to satisfy this condition.
Participants:
Operator -- A person running a hidden service
Host, "Server" -- The Tor software run by the operator to provide
a hidden service.
User -- A person contacting a hidden service.
Client -- The Tor software running on the User's computer
Pubsub Point -- A Tor node that accepts anonymous subscription
requests and anonymous publishing requests and translated
all data sent in publishing requests to all subscribers.
Rendezvous Point -- A Tor node to which clients and servers
connect and which relays traffic between them.
Data involved:
Onion site name - a public key for Asymmetric Encryption.
Access Token - one time secret used by between Client Host when
contacting Rendezvous Point. It is used by Rendezvous Point
to match a connection from Client with the corresponding
connection from Host.
Access Key - cryptographic key used by between Client Host when
contacting Rendezvous Point. It is needed to protect data passed
through Rendezvous Point by authenticated encryption.
## What Pubsub Point
It has two "methods":
HOST - keep the connection open.
CLIENT - read a piece of data from the connection and send it to
all open HOST connections.
## What Rendezvous Point does
It has two "methods":
CLIENT - read Access Token from the connection and keep it open.
HOST - read Access Token from the connection, lookup the CLIENT
connection with this Access Token and connect them.
## Client-Host protocol
A hidden service is identified with a public key (not with a fingerprint
as now). A Client can encrypt a message with the public key. The
ciphertext can be decrypted only by the Host. All other parties can not
decrypt it and can't tell the Host (i.e. the public key) from the
ciphertext.
A shared random algorithm (similar to the existing one) is used to
derive a set of Tor nodes from a public key. These nodes are Pubsub
Points.
The Host establishes an anonymous connection to its Pubsub Points
and starts listening.
The Client generates random string to be Access Token.
The Client generates random string to be Access Key.
The Client chooses a random Tor node and connects to it as to
Rendezvous Point using the Access Token.
Then the Client makes tuple (Rendezvous Point pubkey, Access Token,
Access Key), encrypts it with the Host public key.
The Client connects to the Pubsub Points whose pubkeys are derived from
the Host pubkey (see above). The Client sends the ciphertext to the
Pubsub Points.
The Host reads all data from the Pubsub and tries to decrypt it.
If it succeeds, it connects to the Rendezvous Point specified in the
decrypted message with the Access Token specified in the decrypted
message. The Access Key specified in the decrypted message is used
by Host and Client to protect communications from the Rendezvous Point
with authenticated encryption.
## The attack on the protocol to censor a particular onion site
The malicious Pubsub Points wants to block a particular onion site.
It makes a Client connection to the site, but sends the ciphertext only
to itself (not to other Pubsub Points) and the Pubsub Point sends it
to only one of the listeners. If the Client succeeds connecting the Host
the Pubsub makes a conclusion that the connection belongs to the Host
and stops sending ciphertexts to that connection.
A Host can protect itself from this kind of attack by opening a new
connection to Pubsub Points from time to time. Also it can open two
connections to the same Pubsub Point and compare results it gets from
them. If some ciphertext is missing in one of connections, it opens
one more connection and so on.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23839Testing Framework for Censorship Circumvention2022-07-20T21:00:54ZArthur EdelsteinTesting Framework for Censorship Circumvention[[the Montreal meeting](https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Montreal/Notes/OONI-TorBrowserCollaboration|At)], we discussed the possibility of creating an opt-in, embedded testing/telemetry module for Tor Browse...[[the Montreal meeting](https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Montreal/Notes/OONI-TorBrowserCollaboration|At)], we discussed the possibility of creating an opt-in, embedded testing/telemetry module for Tor Browser that would allow collection of data on connectivity for Tor and for different bridges and pluggable transports. OONI could collate and analyze this data to give a better picture of the per-country bridge connectivity situation. That data could be used to improve Tor Launcher's connection UX, and also help compare different censorship circumvention tools.
This can be a parent ticket for designing and developing such a module.https://gitlab.torproject.org/legacy/trac/-/issues/25137Tor blocked in UAE2021-03-27T04:55:11ZTracTor blocked in UAEOn 1 Jan, I was unable to connect to a site I often use with Tor. It got 75% loaded and stopped. After 2 hours, I figured out the UAE had started blocking Tor, and switched to obfs4. This worked until today at midnight. So I switched to ...On 1 Jan, I was unable to connect to a site I often use with Tor. It got 75% loaded and stopped. After 2 hours, I figured out the UAE had started blocking Tor, and switched to obfs4. This worked until today at midnight. So I switched to meek, which worked. I connected to one yahoo mail account, finished, closed Tor before switching to my other yahoo mail account (I don't want yahoo to know they're both me). Tor only loaded 25%. It downloaded the network consensus, but could not load the network consensus. I closed Tor and tried meek-Amazon and meek-azure, but always, Tor could not load the network consensus. So I switched to Openvpn, and was able to use Tor in normal mode, without a bridge. (Of course, I had to reset my computer clock to match the VPN address). Does anyone know how the UAE is blocking Tor so that it cannot load the network status, and what I can do about it (in case they figure out how to block Openvpn).
**Trac**:
**Username**: mwolfeDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25430Turkey bridges.torproject.org cant access2020-06-13T18:29:10ZTracTurkey bridges.torproject.org cant accessGreetings,
In Turkey as you know there are lots of internet censorship and im fearing that this censorship could go way much worse just like russia and china.
About 2-3 years ago Turkey government blocked tor, by that i mean tor relays...Greetings,
In Turkey as you know there are lots of internet censorship and im fearing that this censorship could go way much worse just like russia and china.
About 2-3 years ago Turkey government blocked tor, by that i mean tor relays and torproject.org website.
So im trying to get along with it by using bridges.
The problem is, both torproject.org and its subdomain bridges.torproject.org is censored as well-in all Turkey's ISP's. Currently i can only access via vpn-but also in tails its really hard to access bridges as well.(one time i had to manually input bridges plus certs doh!)
My search on mirrors of bridges.torproject.org gave no results, and i cant find any problem solving answers here as well unfortunately.
And yes there are other ways to get bridges by mail, but those mail adresses-gmail,yahoo and riseup could be censored as well. So we need a solution about that too.
So my problem/ suggestion is to put a mirror site-other than torproject.org on your web page,and maybe put some sync'ing bridges in tails ( i mean with a script, bridges info could be pulled -from clearnet :( i know right-and put in torrc file)
Sorry i dont have enough tech info about this,im just throwing the ideas i have.
This censorship of ours could be gotten worse-in anytime so please help us!
**Trac**:
**Username**: fromturkeyhttps://gitlab.torproject.org/legacy/trac/-/issues/26087Growth in bridge users in Iran circa 2018-05-012020-06-13T18:31:19ZcypherpunksGrowth in bridge users in Iran circa 2018-05-01https://metrics.torproject.org/userstats-bridge-country.html?graph=userstats-bridge-country&country=ir
Seems worth investigating as there as well recent reports of Tor not working in Iran, e.g.: https://blog.torproject.org/comment/27526...https://metrics.torproject.org/userstats-bridge-country.html?graph=userstats-bridge-country&country=ir
Seems worth investigating as there as well recent reports of Tor not working in Iran, e.g.: https://blog.torproject.org/comment/275268#comment-275268David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/26646add support for multiple OutboundBindAddressExit IP(ranges)2020-06-13T15:27:37Znusenuadd support for multiple OutboundBindAddressExit IP(ranges)tor has support for dedicated outbound IP addresses
for on exit relays via OutboundBindAddressExit.
This parameter supports only a single IPv4 and a single IPv6 address.
I propose to add an extension of this feature to support IPv4 and ...tor has support for dedicated outbound IP addresses
for on exit relays via OutboundBindAddressExit.
This parameter supports only a single IPv4 and a single IPv6 address.
I propose to add an extension of this feature to support IPv4 and IPv6
ranges/prefixes.
The idea is to assign an IP address to each tor circuit. The exit IP
address must never change during the lifetime of the circuit.
Exit IP addresses would be randomly assigned to circuits. Once
the exit runs out of IPs it cycles through his pool of IPs again.
With IPv6 address space availability this can take a long time
with IPv4 it will be limited.
This aims to reduce the negative impact of few "bad" users on many "good"
users since they will not share the same IP address on the exit.
This might also have some negative? side effect since
it demultiplexes tor clients to multiple source IPs on the exit
and an external observer (not running the exit itself)
can tell clients apart by looking at source IPs.
Instead of doing it on the circuit level you could do it
based on time. Change the exit IP every 5 minutes (but
do _not_ change the exit IPs for _existing_ circuits even if they
live longer than 5 minutes).
https://lists.torproject.org/pipermail/tor-dev/2018-March/013036.htmlTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27723Obfs4 stopped working 16 Sept 182021-03-27T04:55:11ZTracObfs4 stopped working 16 Sept 18I was using obfs4 on 15 Sept 18, but shortly after midnight, it stopped working, and I'm using azure. I assume that's the only thing that works when obfs4 fails.
**Trac**:
**Username**: mwolfeI was using obfs4 on 15 Sept 18, but shortly after midnight, it stopped working, and I'm using azure. I assume that's the only thing that works when obfs4 fails.
**Trac**:
**Username**: mwolfeDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/28555Assess methodology for modern privcount Tor user counts2020-06-13T17:48:00ZRoger DingledineAssess methodology for modern privcount Tor user countsWith our traditional user count methods, based on extrapolating from consensus fetch counts -- and assuming each client is online all day -- we see approximately 2 million daily users.
The IMC 2018 paper estimates closer to 8 million da...With our traditional user count methods, based on extrapolating from consensus fetch counts -- and assuming each client is online all day -- we see approximately 2 million daily users.
The IMC 2018 paper estimates closer to 8 million daily users:
https://www.ohmygodel.com/publications/tor-usage-imc18.pdf
Understanding how many users we have is a critical building block for Isabela's "user retention" cycle. It also turns out to really impact how other large organizations view us: from Mozilla's perspective, 8 million daily users is wildly more attractive than 2 million daily users, and similarly with larger numbers we're in a position to negotiate funding for a spot in the search box. And third, understanding our user base helps us understand the capacity of the Tor network, by making us better able to predict how Tor would handle an influx of n million new users (from Brave, from Firefox private browsing mode, or from other apps that integrate Tor and then become popular).
We should figure out what we think about this paper's counting methodology, and either (1) identify follow-up research questions that we need to investigate to convince ourselves that this newer number is more right, or (2) decide that the methodology is solid, in which case we should (a) tell the world about it in a blog post or similar, (b) update our various documentation and metrics graphs, and (c) figure out a way to deploy ongoing user count measurements with this new approach.https://gitlab.torproject.org/legacy/trac/-/issues/28679Bridge connections on startup2020-06-13T15:35:01ZTracBridge connections on startupWhen custom list of bridges is used at startup tor connects to all of them and then selects a random bridge. I find this approach to be less secure than just randomly selecting a bridge and connecting to it, without pre-testing of all br...When custom list of bridges is used at startup tor connects to all of them and then selects a random bridge. I find this approach to be less secure than just randomly selecting a bridge and connecting to it, without pre-testing of all bridges, and then select another if previous is unreachable. It's better to have a config option to control this.
**Trac**:
**Username**: sveTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28898Huge drop of users in UAE2021-03-27T04:55:11ZanadahzHuge drop of users in UAEThere is a huge [decrease of directly connecting clients from the United Arab Emirates](https://metrics.torproject.org/userstats-relay-country.html?start=2018-09-19&end=2018-12-18&country=ae&events=off):
![userstats-relay-country-ae-20...There is a huge [decrease of directly connecting clients from the United Arab Emirates](https://metrics.torproject.org/userstats-relay-country.html?start=2018-09-19&end=2018-12-18&country=ae&events=off):
![userstats-relay-country-ae-2018-09-19-2018-12-18-off.png, 75%](uploads/userstats-relay-country-ae-2018-09-19-2018-12-18-off.png, 75%)
Is this in any way related to #21345?David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31539FAQ page (esp connection troubleshoooting) should be available offline in TB2020-06-16T01:06:49ZNima FatemiFAQ page (esp connection troubleshoooting) should be available offline in TBTor has been once again blocked as of few hours ago in Iran. And as per usual my DMs and Email have been flooded with questions from censored users not knowing how to get back on the network. This means people still don't know they can u...Tor has been once again blocked as of few hours ago in Iran. And as per usual my DMs and Email have been flooded with questions from censored users not knowing how to get back on the network. This means people still don't know they can use a bridge, or that there are default bridges provided, or that they can perform bridge discovery inside the Tor Browser.
One of the things I've always admired Tails for, is that all of their documentation is available offline inside Tails. We used to do a similar thing. In the old days, there was a short Tor Browser manual. A one page simple html that was served when someone would request TB via GetTor.
I think it wont hurt to load an offline HTML page in case connection fails, and users are confused on what to do next. In my experience, most users don't even know that there are other ways to connect to the Tor network when the direct connection fails.
Additionally, we should consider a scenario that I haven't seen covered by any of the help documents I've read so far and that is when a user has already been connecting to the Tor network directly, but after some time it fails and now they need a bridge.
I'm not sure which component would be the right one for this, considering it involves censorship circumvention, tor browser and tor support. Feel free to move it to the right bucket.