Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2020-06-27T13:43:29Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5470Bridge descriptors on ponticum.torproject.org are out of date2020-06-27T13:43:29ZAaron GibsonBridge descriptors on ponticum.torproject.org are out of dateThe timestamp on the bridge descriptors indicates that it hasn't updated since Mar 7:
```
ls -lstra /srv/bridges.torproject.org/from-authority/bridge-descriptors
6392 -rw-r--r-- 1 bridgedb bridgedb 6542607 Mar 7 20:37 /srv/bridges.torp...The timestamp on the bridge descriptors indicates that it hasn't updated since Mar 7:
```
ls -lstra /srv/bridges.torproject.org/from-authority/bridge-descriptors
6392 -rw-r--r-- 1 bridgedb bridgedb 6542607 Mar 7 20:37 /srv/bridges.torproject.org/from-authority/bridge-descriptors
```
I sent Lucky Green an email and will update this ticket with the response.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5481Deploy recaptcha support for https distribution strategy2020-06-27T13:43:29ZKarsten LoesingDeploy recaptcha support for https distribution strategyFrom [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2): "13. bridgedb: Deploy recaptcha support for https distribution strategy. Right now our bridgedb service is getting bombarded by automated bridge requests, which look an awf...From [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2): "13. bridgedb: Deploy recaptcha support for https distribution strategy. Right now our bridgedb service is getting bombarded by automated bridge requests, which look an awful lot like an adversary trying to enumerate all the bridges. If we stick a manual captcha step in, we force them to move forward at the arms race."
From talking to Aaron in December:
1. We have recaptcha support merged into BridgeDB, but it is currently not enabled. (legacy/trac#1836)
2. Two subtasks of this deliverable should be "Move bridges.tp.o to a Tor VM" and "Get aagbsn access to bridges.tp.o." (legacy/trac#2301)
3. There is some question as to how Google will react to the recaptcha implementation. We should talk to Google people before enabling it. Aaron is going to talk to them, possibly after an introduction by Mike or Jake.
AFAIK, 2 is in progress and 3 and 1 have not been started.
Can we agree on some schedule when these substeps and the overall deliverable are expected to be done?
Optimistically assigning to the July milestone.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5482Annotate and sort the social-network bridge pools by stability and reachability2020-06-27T13:43:29ZKarsten LoesingAnnotate and sort the social-network bridge pools by stability and reachabilityFrom [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2): "15. bridgedb: Annotate and sort the social-network bridge pools by stability and, once we have it, reachability. Right now we send a daily list of 50--100 bridges out, and...From [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2): "15. bridgedb: Annotate and sort the social-network bridge pools by stability and, once we have it, reachability. Right now we send a daily list of 50--100 bridges out, and half or more of the bridges are down the next day. We should track which bridges are up day after day and make them clearer in the list."
From talking to Aaron in December:
1. I think that my [tech report on bridge stability](https://metrics.torproject.org/papers/bridge-stability-2011-10-31.pdf) may be useful for the "stability" part of this deliverable. We'll want to include some bridge stability information in the bridge lists and maybe rank bridges by their stability value. (legacy/trac#3223)
2. The "reachability" part could be the same blocking information that we use for deliverable 17. We can probably just copy this information from the given file to the bridge lists. (legacy/trac#3224)
Can we agree on some schedule when these substeps and the overall deliverable are expected to be done?
Optimistically assigning to the July milestone.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5483managed pluggable transports should be able to pause Tor's circuit-building?2021-06-17T14:27:44ZRoger Dingledinemanaged pluggable transports should be able to pause Tor's circuit-building?Hooman with his Skypemorph transport (http://archives.seul.org/tor/dev/Mar-2012/msg00093.html) notes that when Tor first starts, and starts his transport, it takes his transport a minute or two to become ready. During that time, Tor trie...Hooman with his Skypemorph transport (http://archives.seul.org/tor/dev/Mar-2012/msg00093.html) notes that when Tor first starts, and starts his transport, it takes his transport a minute or two to become ready. During that time, Tor tries to start a circuit to his configured bridges, times out the circuit, and marks his bridges down.
He can work around the problem in his experiments by starting Tor with "DisableNetwork 1" in the torrc, and when he's ready, remove the line and hup tor. That's not a good solution for real users though.
The problem would be less pronounced for him if Tor had better handling of when to mark a bridge down. There are a variety of tickets about that. But I think those issues are different from this ticket.
Perhaps the various proposals we've been writing recently have some opportunity to fit this in? Which ones are the best ones to look at?https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5484Make BridgeDB leave out blocked bridges2020-06-27T13:43:29ZKarsten LoesingMake BridgeDB leave out blocked bridgesFrom [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2): "17. bridgedb: learn to take in a list of bridges blocked in a set of countries, and learn what country a user is asking for bridges in, and leave the blocked bridges out o...From [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2): "17. bridgedb: learn to take in a list of bridges blocked in a set of countries, and learn what country a user is asking for bridges in, and leave the blocked bridges out of the answer we provide. We'll want this building block once we have bridge reachability testing working."
From talking to Aaron in December:
1. The current BridgeDB code contains a function to accept a list of blocked bridges by country to give out non-blocked bridges to users (legacy/trac#1837). This code needs testing. Also, there is a bug with how BridgeDB learns which country a user is interested in getting un-blocked bridges for, which currently conflicts with the language selection.
2. There are at least three approaches for giving out non-blocked bridges to users: a) exclude blocked bridges from results, b) replace blocked bridges with non-blocked once, or c) include blocked bridges in results and write "maybe blocked" next to them. We're currently doing a), but we should do c) to improve usability. There are variants of b), e.g., b1) Christian suggests to give out exactly one non-blocked bridge if otherwise we’d give out zero bridges and b2) Roger suggests to give out the first three non-blocked bridges in a fixed set of five bridges. One part of this deliverable should be to discuss these alternatives and agree on one of them that shall be implemented.
Can we agree on some schedule when these substeps and the overall deliverable are expected to be done?
Optimistically assigning to the July milestone.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5485Think about ways to give out non-blocked bridges without making it too easy t...2020-06-27T13:43:29ZKarsten LoesingThink about ways to give out non-blocked bridges without making it too easy to enumerate all bridgesThere are at least three approaches for giving out non-blocked bridges to users: a) exclude blocked bridges from results, b) replace blocked bridges with non-blocked once, or c) include blocked bridges in results and write "maybe blocked...There are at least three approaches for giving out non-blocked bridges to users: a) exclude blocked bridges from results, b) replace blocked bridges with non-blocked once, or c) include blocked bridges in results and write "maybe blocked" next to them. We're currently doing a), but we should do c) to improve usability. There are variants of b), e.g., b1) Christian suggests to give out exactly one non-blocked bridge if otherwise we’d give out zero bridges and b2) Roger suggests to give out the first three non-blocked bridges in a fixed set of five bridges. One part of sponsor F deliverable 17 should be to discuss these alternatives and agree on one of them that shall be implemented.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5492Talk to Google recaptcha team about BridgeDB's recaptcha-proxying strategy2020-06-27T13:43:28ZAaron GibsonTalk to Google recaptcha team about BridgeDB's recaptcha-proxying strategyBridgeDB proxies recaptcha requests for our users so that we don't leak their infos to Google.
We don't know how happy Google will be about this. It's possible that bridges.torproject.org could get blocked from the recaptcha API.
We co...BridgeDB proxies recaptcha requests for our users so that we don't leak their infos to Google.
We don't know how happy Google will be about this. It's possible that bridges.torproject.org could get blocked from the recaptcha API.
We could proxy the captcha requests through Tor, it would make bridges.tpo load slightly slower, but then the requests would just look like a Tor user had landed on bridges.torproject.org (from Google's perspective). That could be considered rude, and we don't want Google to start treating Tor users differently. Although this may already be the case, because some google searches over Tor are denied without even a captcha.
We could use a different captcha implementation.
As I already implemented recaptcha support and Google is responsible for making sure they keep working, we should talk to them first and see if the current implementation is acceptable before exploring other options.
It was suggested that Mike or Jake could provide an introduction.
This is the ticket to track the progress of this discussion.Aaron GibsonAaron Gibsonhttps://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/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/bridgedb/-/issues/5620bridgedb apparently leaking2020-06-27T13:43:28Zweasel (Peter Palfrader)bridgedb apparently leakingon ponticum:
```
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1007 bridgedb 20 0 1599m 256m 1464 S 0.0 51.6 91:05.69 python
```
bridgedb is using unreasonable amounts of memory.on ponticum:
```
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1007 bridgedb 20 0 1599m 256m 1464 S 0.0 51.6 91:05.69 python
```
bridgedb is using unreasonable amounts of memory.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5631Tor won't connect2020-06-27T13:43:28ZTracTor won't connectAfter not using Tor in a while, I decided to load it up again. However, it would not connect for some reason. I uninstalled it and downloaded the new Vidalia bundle. However, I am still getting the same error.
This is what it says in th...After not using Tor in a while, I decided to load it up again. However, it would not connect for some reason. I uninstalled it and downloaded the new Vidalia bundle. However, I am still getting the same error.
This is what it says in the log:
Apr 16 17:47:46.918 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 375; recommendation warn)
Apr 16 17:47:46.923 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 376; recommendation warn)
Apr 16 17:47:46.928 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 377; recommendation warn)
Apr 16 17:47:46.928 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 378; recommendation warn)
Apr 16 17:47:46.938 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 379; recommendation warn)
Apr 16 17:47:46.943 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 380; recommendation warn)
Apr 16 17:47:46.943 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 381; recommendation warn)
Apr 16 17:47:46.948 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 382; recommendation warn)
Apr 16 17:47:46.953 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 383; recommendation warn)
Apr 16 17:47:46.953 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 384; recommendation warn)
Apr 16 17:47:46.958 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 385; recommendation warn)
Apr 16 17:47:46.958 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 386; recommendation warn)
Apr 16 17:47:46.963 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 387; recommendation warn)
Apr 16 17:47:46.968 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 388; recommendation warn)
Apr 16 17:47:47.815 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 389; recommendation warn)
Apr 16 17:47:47.820 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 390; recommendation warn)
Apr 16 17:47:52.635 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 391; recommendation warn)
Apr 16 17:47:53.752 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 392; recommendation warn)
Apr 16 17:47:57.782 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 393; recommendation warn)
Apr 16 17:47:57.787 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 394; recommendation warn)
Apr 16 17:47:57.787 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 395; recommendation warn)
Apr 16 17:47:58.987 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (IOERROR; IOERROR; count 396; recommendation warn)
Apr 16 17:47:59.762 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 397; recommendation warn)
Apr 16 17:48:10.233 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 398; recommendation warn)
Apr 16 17:48:10.328 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 399; recommendation warn)
Apr 16 17:48:12.323 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 400; recommendation warn)
Apr 16 17:48:13.718 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 401; recommendation warn)
Apr 16 17:48:15.068 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 402; recommendation warn)
Apr 16 17:48:15.568 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 403; recommendation warn)
Apr 16 17:48:19.763 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 404; recommendation warn)
Apr 16 17:48:19.853 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 405; recommendation warn)
Apr 16 17:48:19.858 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 406; recommendation warn)
Apr 16 17:48:27.832 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 407; recommendation warn)
Apr 16 17:48:32.964 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (IOERROR; IOERROR; count 408; recommendation warn)
Apr 16 17:48:34.868 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (IOERROR; IOERROR; count 409; recommendation warn)
Apr 16 17:48:35.055 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (IOERROR; IOERROR; count 410; recommendation warn)
Apr 16 17:48:35.148 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (IOERROR; IOERROR; count 411; recommendation warn)
Apr 16 17:48:35.616 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 412; recommendation warn)
Apr 16 17:48:36.818 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 413; recommendation warn)
Apr 16 17:48:37.800 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 414; recommendation warn)
Apr 16 17:48:37.800 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 415; recommendation warn)
Apr 16 17:48:37.800 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 416; recommendation warn)
Apr 16 17:48:37.800 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 417; recommendation warn)
Apr 16 17:48:37.800 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 418; recommendation warn)
Apr 16 17:48:37.800 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 419; recommendation warn)
Apr 16 17:48:37.800 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 420; recommendation warn)
Apr 16 17:48:37.800 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 421; recommendation warn)
Apr 16 17:48:38.783 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 422; recommendation warn)
Apr 16 17:48:38.783 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (DONE; DONE; count 423; recommendation warn)
Apr 16 17:48:41.810 [Warning] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 424; recommendation warn)
I've turned off my firewall and nothing seems like it could be blocking it, what's wrong?
**Trac**:
**Username**: okawaruhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5655Request to add gatech.edu to bridge email whitelist2020-06-27T13:43:28ZTracRequest to add gatech.edu to bridge email whitelistWhen requesting bridge addresses via the email system, it only accepts emails from gmail.com, yahoo.com, and mit.edu.
I would like to request that `gatech.edu` be added to the white list. We have a large number of international students...When requesting bridge addresses via the email system, it only accepts emails from gmail.com, yahoo.com, and mit.edu.
I would like to request that `gatech.edu` be added to the white list. We have a large number of international students, and many of them are from countries that disallow access to US media networks. Having an easy way to get bridge relays would benefit these students, who may otherwise not be able to access U.S. media, and other web services (Twitter, gmail, etc.) from their home countries.
(Ticket opened after discussion on `tor-talk` mailing list, RE "Tor Public Bridge Email")
**Trac**:
**Username**: SamWhitedhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5851Make BridgeDB's output compatible with both Vidalia & TorLauncher2020-06-27T13:43:28ZRuna SandvikMake BridgeDB's output compatible with both Vidalia & TorLauncherA user reports that the text on bridges.torproject.org is confusing for blind users, and users with slow connections / users who block images.
On bridges.torproject.org, blind users will be hearing a couple of references in their scree...A user reports that the text on bridges.torproject.org is confusing for blind users, and users with slow connections / users who block images.
On bridges.torproject.org, blind users will be hearing a couple of references in their screen-readers to _bridge entries_ and _bridge addresses_:
* _As an example, you'll get a bridge entry that looks like the following: bridge 141.[etc.]_
* _Here are your bridge relays: bridge 60.[etc.]_
On bridges.html.en, we have an image illustrating how to add a bridge to Vidalia:
* _Add each bridge address one at a time in the Vidalia Network settings page, by pasting it into the 'Add a Bridge' window and then clicking the '+' sign. Adding a bridge is pictured below:_
... but users will not see the picture and will not know whether to include _bridge_ or not.
Updating bridges.html.en is easy to do, but can we please do something about bridges.tpo as well? Is there a good reason for printing the bridge lines with the word _bridge_ in front of each one?Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5852WebResource.getBridgeRequestAnswer() is unhappy about IPv6 addresses2020-06-27T13:43:28ZLinus Nordberglinus@torproject.orgWebResource.getBridgeRequestAnswer() is unhappy about IPv6 addressesLogs on ponticum fill up with warnings about badly formed
X-Forwarded-For headers. Most (all?) of them appear to be IPv6
addresses.
Bridges.is_valid_ip() recognizes IPv4 addresses only.
I don't know if extending is_valid_ip() is the r...Logs on ponticum fill up with warnings about badly formed
X-Forwarded-For headers. Most (all?) of them appear to be IPv6
addresses.
Bridges.is_valid_ip() recognizes IPv4 addresses only.
I don't know if extending is_valid_ip() is the right thing to do but
it might. I haven't looked into other usage of it.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5935Determine how bridge-pool assignments should work with BridgeDB's IPv6 and pl...2020-06-27T13:43:27ZAaron GibsonDetermine how bridge-pool assignments should work with BridgeDB's IPv6 and pluggable-transport extensionsExtensions legacy/trac#4097, legacy/trac#5027 sort bridges into sub-rings determined by a set of filters. legacy/trac#4568 (pluggable transports) will function similarly.
e.g. A bridge request that specifies ipv6 address, or bridges not...Extensions legacy/trac#4097, legacy/trac#5027 sort bridges into sub-rings determined by a set of filters. legacy/trac#4568 (pluggable transports) will function similarly.
e.g. A bridge request that specifies ipv6 address, or bridges not blocked in a given country, or bridges with a specified pluggable transport type, or even some combination of the above.
The changes in legacy/trac#4097 (and legacy/trac#5027) cause BridgeDB to write all the assignments including subrings -- which are named by the set of applied filters -- into the assignments.log. This seems to confuse the bridge-assignments script(s) that Karsten runs.
A bridge may be present in several different sub-rings, because it matches several filters (i.e. a bridge may be in a ring of ipv6 bridges as well as another ring of bridges not blocked in iran, and another ring of bridges with ipv6 addresses and not blocked in iran)
We need to figure out what the bridge assignments.log should look like, and whether/how the scripts that parse this file should be updated.
Karsten, what are your thoughts/questions?https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5943Get ReCaptcha API keys for bridges.torproject.org2020-06-27T13:43:27ZAaron GibsonGet ReCaptcha API keys for bridges.torproject.orgBridgeDB needs ReCaptcha API keys (for address: bridges.torproject.org)BridgeDB needs ReCaptcha API keys (for address: bridges.torproject.org)Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5947BridgeDB should parse "a lines" from networkstatus-bridges2020-06-27T13:43:27ZAaron GibsonBridgeDB should parse "a lines" from networkstatus-bridgesBridgeDB reads or-addresses from the bridge-descriptors, but should read them from the networkstatus-bridges instead.
The format of an "a" line in networkstatus-bridges is the same as the or-address line in bridge-descriptor, but has be...BridgeDB reads or-addresses from the bridge-descriptors, but should read them from the networkstatus-bridges instead.
The format of an "a" line in networkstatus-bridges is the same as the or-address line in bridge-descriptor, but has been verified as reachable by the bridge-authority.
I'm not sure what the status of ipv6 reachability testing is, or when "a" lines will appear in networkstatus-bridges.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5948BridgeDB should respond with the same address:port to each request2020-06-27T13:43:27ZAaron GibsonBridgeDB should respond with the same address:port to each requestWhen a Bridge has multiple listening addresses/ports, a valid bridge line is selected and returned to the client. No effort is made to make sure that the same address:port is returned for each request. This is a design flaw, as a single ...When a Bridge has multiple listening addresses/ports, a valid bridge line is selected and returned to the client. No effort is made to make sure that the same address:port is returned for each request. This is a design flaw, as a single client could expose all listening addresses and ports of a given bridge.
BridgeDB should respond with the same address:port per bridge for repeat requests.
This can be implemented in a pretty straightforward way, by mapping the requesting {ip, email} to one of the address lines and one valid port.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5949BridgeDB reachability/blocking should be per address:port2020-06-27T13:43:27ZAaron GibsonBridgeDB reachability/blocking should be per address:portAs censors will block bridges by ip:port or ip, BridgeDB should support tracking reachability at this granularity. Presently it is per-bridge, but as bridges will now support multiple listening ports and addresses, so should reachability...As censors will block bridges by ip:port or ip, BridgeDB should support tracking reachability at this granularity. Presently it is per-bridge, but as bridges will now support multiple listening ports and addresses, so should reachability information.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/6045Ethiopia blocks Tor based on ServerHello2020-06-27T13:43:43ZGeorge 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 legacy/trac#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.