Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-15T23:01:28Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34407Review all Fenix menu items2020-06-15T23:01:28ZMatthew FinkelReview all Fenix menu itemsReview all menu items. Can we hide/delete some? Can we repurpose any?Review all menu items. Can we hide/delete some? Can we repurpose any?https://gitlab.torproject.org/legacy/trac/-/issues/33264Prop 313: 5. Collect IPv6 Connection Stats on Relays2020-06-13T15:51:15ZteorProp 313: 5. Collect IPv6 Connection Stats on RelaysWe propose that relays (but not bridges) collect IPv6 connection statistics.
Bridges refuse to collect the existing ConnDirectionStatistics, so we do not
believe it is safe to collect the smaller IPv6 totals on bridges.
To minimise dev...We propose that relays (but not bridges) collect IPv6 connection statistics.
Bridges refuse to collect the existing ConnDirectionStatistics, so we do not
believe it is safe to collect the smaller IPv6 totals on bridges.
To minimise development and testing effort, we propose re-using the existing
"bidi" code in rephist.c. (This code may require some refactoring, because
the "bidi" totals are globals, rather than a struct.)
(We might also want to move this code into separate relay-only code and
header files, because it is relay-specific.)
In particular, tor currently counts these connection statistics:
* below threshold,
* mostly read,
* mostly written, and
* both read and written.
We propose adding IPv6 variants of all these statistics. (The IPv4
statistics can be calculated by subtracting the IPv6 statistics from the
existing total connection statistics.)
See proposal 313, section 5:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n144Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33259Store measurements in a local database to reduce plotting time2020-06-13T18:04:09ZKarsten LoesingStore measurements in a local database to reduce plotting timeWe want to add graphs to OnionPerf that compare larger numbers of measurements. We also plan to add more parameters to plot different subsets of measurements. Having a local database for storing measurements and decoupling the parsing st...We want to add graphs to OnionPerf that compare larger numbers of measurements. We also plan to add more parameters to plot different subsets of measurements. Having a local database for storing measurements and decoupling the parsing step from the plotting step might reduce overall plotting time. This will be particularly useful when we include graphs based on Tor descriptors like flags or bandwidth or consensus weight.
Part of this ticket will be to figure out which database to use. Maybe we need to experiment with SQLite to see if it's fast enough for this purpose or whether we need something like PostgreSQL here.https://gitlab.torproject.org/legacy/trac/-/issues/33178Figure out specific baselines we are interested in from a network health pers...2020-06-13T18:10:34ZGeorg KoppenFigure out specific baselines we are interested in from a network health perspectiveIn #33176 we checked what metrics/growth stats we currently have, which we need and whether all of the are collected properly.
In this ticket we should figure out specific baselines for our favorite stats. meejah came up with some thing...In #33176 we checked what metrics/growth stats we currently have, which we need and whether all of the are collected properly.
In this ticket we should figure out specific baselines for our favorite stats. meejah came up with some things that were worth collecting/investigating:
* expected failure rate for ciruits
* what % of exits are not expected to establish circuits
There might be more. This is likely a parent ticket and we should file child ones for more specific items.https://gitlab.torproject.org/legacy/trac/-/issues/32949Migrate dip from gitlab-01 to gitlab-022020-06-13T17:00:21ZHiroMigrate dip from gitlab-01 to gitlab-02Our current gitlab installation has been having an issue when creating merge requests from forked projects (see: #32197). It might be a simple misconfiguration issue but gitlab service-admins and the sysadmin team prefers to migrate this...Our current gitlab installation has been having an issue when creating merge requests from forked projects (see: #32197). It might be a simple misconfiguration issue but gitlab service-admins and the sysadmin team prefers to migrate this service to a different VM running the ombibus package instead of the custom debian ansible playbooks.HiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/32938Have a way to test throughput of snowflake proxy2020-06-13T18:21:25ZCecylia BocovichHave a way to test throughput of snowflake proxyA common question from snowflake proxy volunteers is whether or not their proxy is working (see comment 11 on #31109). It would be great to have some kind of bandwidth test for proxy owners to see whether or not their proxy is reachable ...A common question from snowflake proxy volunteers is whether or not their proxy is working (see comment 11 on #31109). It would be great to have some kind of bandwidth test for proxy owners to see whether or not their proxy is reachable from a remote probe point. This might also help us find and diagnose problems with existing proxies.
Some notes:
- we can't ask the broker to assign us a specific proxy at the moment so this test would likely be separate from the broker (unless we add an entirely new feature which I'm hesitant to do)
- we'll have to protect this service from abuse somehow, probably by rate-limiting. See some discussion on #31874. It would be best to engineer a way so that only a proxy owner can run the test on their proxy.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/32709hsv3: Support onionbalance keys when handling INTRO2 cells2020-06-13T15:49:02ZGeorge Kadianakishsv3: Support onionbalance keys when handling INTRO2 cellsWe have encountered a small issue with onionbalance viability for v3s.
While the descriptor cross-certificates are no longer an issue (#29583), there is an issue with the ntor handshake during the INTRODUCE1/INTRODUCE2 handshake between...We have encountered a small issue with onionbalance viability for v3s.
While the descriptor cross-certificates are no longer an issue (#29583), there is an issue with the ntor handshake during the INTRODUCE1/INTRODUCE2 handshake between the client and service.
In particular, as specified in rend-spec-v3.txt [NTOR-WITH-EXTRA-DATA] the subcredential (which includes the onion address) is used as part of the ntor key material to generate end-to-end encryption keys and MAC keys so that the service can communicate with the client:
```
To make an INTRODUCE1 cell, the client must know a public encryption
key B for the hidden service on this introduction circuit. The client
generates a single-use keypair:
x,X = KEYGEN()
and computes:
intro_secret_hs_input = EXP(B,x) | AUTH_KEY | X | B | PROTOID
info = m_hsexpand | subcredential
hs_keys = KDF(intro_secret_hs_input | t_hsenc | info, S_KEY_LEN+MAC_LEN)
ENC_KEY = hs_keys[0:S_KEY_LEN]
MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN]
```
The issue here is that when the client prepares the INTRO1 cell, it uses the subcredential of the frontend OBv3 service, but the INTRO2 cell actually goes to a backend OBv3 instance which has a different subcredential. This causes the backend instance to not be able to verify the MAC of the cell, and generally finish the ntor handshake....Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/32308Stop inner letterbox jiggling as border is dragged2020-06-16T01:09:04ZcypherpunksStop inner letterbox jiggling as border is draggedTBB 9.0
Linux 64
Cinnamon
The inner content area of the letterbox jiggles violently as the Tor Browser window border is dragged to resize. The effect is worse on horizontal (width) than vertical (height). Ideally, the content area wou...TBB 9.0
Linux 64
Cinnamon
The inner content area of the letterbox jiggles violently as the Tor Browser window border is dragged to resize. The effect is worse on horizontal (width) than vertical (height). Ideally, the content area would crisply snap as the border shrinks or grows.richardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/32274Bad screen-reader UX for Security Level/Shield button2020-06-16T01:08:56ZrichardBad screen-reader UX for Security Level/Shield buttonWe've received some feedback from JAWS screen reader users indicating that the Security Level button UX isn't quite working the same way as for seeing users. When using a screen reader, the button does not give any indication that the se...We've received some feedback from JAWS screen reader users indicating that the Security Level button UX isn't quite working the same way as for seeing users. When using a screen reader, the button does not give any indication that the security level can be changed, or how one would do so.
My hunch is that the fix may be as simple as changing the language of the tooltip to indicate the button can be activated, which opens the Security Level panel. I'm currently waiting for feedback from the affected JAWS user to confirm this hunch.
Currently, the Security Level panel gives a short description of the current settings, as well as a button to get to the 'Advanced Security Preferences...'. I suspect the JAWS UX here is also less than ideal. We may also need to provide a tooltip to said button indicating that the security level can be modified here.richardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/32095Analyse the "Carbon Reductor DPI X" DPI system2020-06-13T18:31:27ZPhilipp Winterphw@torproject.orgAnalyse the "Carbon Reductor DPI X" DPI systemSee https://github.com/net4people/bbs/issues/15
Let's take a look at the DPI system and see what we can learn from it. Hopefully, it will help us refine our threat models.See https://github.com/net4people/bbs/issues/15
Let's take a look at the DPI system and see what we can learn from it. Hopefully, it will help us refine our threat models.https://gitlab.torproject.org/legacy/trac/-/issues/31851Allow Tor to be compiled without support for relay mode2020-06-13T15:46:01ZteorAllow Tor to be compiled without support for relay modeLet's make some more optional modules.
Our target set of modules might include:
* dirauth - the code only used by directory authorities (including bridge authorities)
* dircache - the code only used by directory caches and directory aut...Let's make some more optional modules.
Our target set of modules might include:
* dirauth - the code only used by directory authorities (including bridge authorities)
* dircache - the code only used by directory caches and directory authorities
* relay - the code only used by relays and directory authorities
* common - the code used by all roles
I'll do a design, and a proposed CI build strategy, and then get it reviewed.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31823HSv3 descriptor support in stem [encoding]2020-06-13T10:53:10ZGeorge KadianakisHSv3 descriptor support in stem [encoding]This is a ticket for impementing HSv3 descriptor encoding in stem.
Some more details here: https://trac.torproject.org/projects/tor/ticket/31369#comment:12This is a ticket for impementing HSv3 descriptor encoding in stem.
Some more details here: https://trac.torproject.org/projects/tor/ticket/31369#comment:12Tor: unspecifiedDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31597Go over all closed bugs/bugs where patches landed between Firefox 61 and 68 (...2020-06-16T01:07:06ZGeorg KoppenGo over all closed bugs/bugs where patches landed between Firefox 61 and 68 (inclusive)We should double-check the thousands of bugs between Firefox 61 and 68 to make sure we don't miss anything important for us.We should double-check the thousands of bugs between Firefox 61 and 68 to make sure we don't miss anything important for us.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/31153Create a "tor-bridge" Debian meta package2020-06-13T18:33:11ZPhilipp Winterphw@torproject.orgCreate a "tor-bridge" Debian meta packageInstalling an obfs4 bridge on Debian currently requires installing tor, obfs4proxy, and then figuring out how to configure it. We could create a meta package, say tor-bridge, that simplifies this process. This package would:
* Ship with...Installing an obfs4 bridge on Debian currently requires installing tor, obfs4proxy, and then figuring out how to configure it. We could create a meta package, say tor-bridge, that simplifies this process. This package would:
* Ship with a script that automatically determines a free and random OR and obfs4 port.
* Help us retire a transport by replacing, say, obfs4 with obfs5.
* Ship with a tool that helps operators get their bridge line.
* Write its torrc to a different file than the tor package, to be compliant with Debian policy.
* After installation, ask the operator about their nickname, contact info, and if they want a vanilla or obfs4 bridge.
* Maybe ship with [nyx](https://nyx.torproject.org) so operators have a sense of how their bridge is doing.
I hear that infinity0 already thought about this problem a lot in the context of tor-bridge-helper.https://gitlab.torproject.org/legacy/trac/-/issues/30986Understand the "long tail" of unclassifiable network traffic2020-06-13T18:36:17ZPhilipp Winterphw@torproject.orgUnderstand the "long tail" of unclassifiable network trafficThe obfs family of obfuscation protocols strives to "look like nothing" and falls into the long tail of network traffic that is meant to be unclassifiable. That is, if an ISP is monitoring its uplink, it shouldn't be able to figure out t...The obfs family of obfuscation protocols strives to "look like nothing" and falls into the long tail of network traffic that is meant to be unclassifiable. That is, if an ISP is monitoring its uplink, it shouldn't be able to figure out that one of its users is talking obfs4 to a Tor bridge. Instead, the obfs4 connection should show up as "unknown" in the log files.
We know next to nothing about this long tail that the obfs family hides in. What fraction of flows does it constitute? What fraction of bytes? What kind of protocols and implementations are difficult to classify? How does the long tail differ across uplinks?
Over at #30716 we're brainstorming features for obfs4's successor but before moving forward with obfs5, we should get a better understanding of this long tail because it allows us to make informed design decisions. Packet traces from the [WIDE backbone](http://mawi.wide.ad.jp/mawi/) is one of the data sets that may be helpful here.
Let's use this ticket to track progress and collect insights.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/30984Make a key-value line abstraction to output control replies2020-06-13T15:42:59ZTaylor YuMake a key-value line abstraction to output control repliesA few controller commands still use `connection_buf_add()` or similar low-level functions after constructing a list of reply lines. Almost all of these are key-value pairs. Create a new abstraction to output these, including by automatic...A few controller commands still use `connection_buf_add()` or similar low-level functions after constructing a list of reply lines. Almost all of these are key-value pairs. Create a new abstraction to output these, including by automatically including the correct separator character between the numeric code and the rest of the line.Tor: 0.4.3.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/30798Develop and deploy tgen model resembling ping2020-06-13T18:04:04ZKarsten LoesingDevelop and deploy tgen model resembling pingAt last week's tor-scaling meeting we discussed developing a second tgen model that resembles a ping service and deploying an OnionPerf instance with that model.
The current default tgen model in OnionPerf makes a new download every fiv...At last week's tor-scaling meeting we discussed developing a second tgen model that resembles a ping service and deploying an OnionPerf instance with that model.
The current default tgen model in OnionPerf makes a new download every five minutes. That's a tiny request with a response of 50 KiB or 1 MiB or 5 MiB.
This new model would send a tiny request once per second for, say, five minutes, and receive a tiny response back to each of these requests.
We wouldn't have to write analysis code that produces something like a .tpf file right now but could start with analyzing the raw logs for this experiment and extract some hopefully useful visualizations.
I could deploy this new model on my local machine (if it uses an onion service).
Raising priority to high, because it would be great to ideally get this deployed before All Hands.
Thoughts?https://gitlab.torproject.org/legacy/trac/-/issues/30794Create lightweight censorship analyser for users2020-06-13T18:31:24ZPhilipp Winterphw@torproject.orgCreate lightweight censorship analyser for usersUsers occasionally show up on #tor and wonder why they are unable to connect to the network. We sometimes suspect censorship but it's often difficult to confirm this hypothesis. It would be useful to have a lightweight censorship analysi...Users occasionally show up on #tor and wonder why they are unable to connect to the network. We sometimes suspect censorship but it's often difficult to confirm this hypothesis. It would be useful to have a lightweight censorship analysis tool for users to run. Think of it as a small, specialised OONI: It should be a self-contained executable that tests if the user's computer can do the following:
* Connect to the TCP port of our directory authorities.
* Connect to the TCP port of a handful of relays.
* Connect to the TCP port of our default bridges.
* Resolve critical domains (e.g., bridges.tp.o) correctly.
* Fetch the index page of critical websites (e.g., bridges.tp.o) over HTTPS.
* Establish a TLS connection with a bridge authority and a relay.
* ...
The output of the tool can be a simple text file that the user can then email to us, or paste in a chat window. We originally had this idea several years ago and [documented it in a research paper](https://censorbib.nymity.ch/#Winter2013a) but nobody every followed up. Such a tool could also be useful as part of an anti-censorship rapid response process.
If this sounds like a good idea, then I suggest that we build the tool in Go because 1) we have several talented Go hackers, 2) Go binaries are self-contained, and 3) [since Go 1.5](https://github.com/golang/go/wiki/WindowsCrossCompiling), cross-compiling for Windows seems relatively simple.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/30247Understand GetTor usage2020-06-21T18:05:50ZPhilipp Winterphw@torproject.orgUnderstand GetTor usageWe should get an understanding of the usage that GetTor sees:
* How many users use GetTor per day/week/month, approximately?
* How does this break down by country? Is GetTor particularly popular in some countries?
* How does this break ...We should get an understanding of the usage that GetTor sees:
* How many users use GetTor per day/week/month, approximately?
* How does this break down by country? Is GetTor particularly popular in some countries?
* How does this break down by distribution channels? Is XMPP more popular than Email?
Naturally, we will have to figure out a way to answer these questions in a privacy-preserving way, e.g., by [binning data and only collecting what's safe to publish](https://research.torproject.org/safetyboard.html#guidelines).
Before we dive into answering these questions, we should get a better understanding of what statistics we already have. Hiro mentioned that there may be some data in Collector.https://gitlab.torproject.org/legacy/trac/-/issues/30022Objective 2, Activity 2: Notify users about typo errors when entering .onion ...2020-06-16T01:02:09ZPili GuerraObjective 2, Activity 2: Notify users about typo errors when entering .onion addressesThis is the parent ticket to hold any tickets under this activity, including:
- Using the address format of onion services v3 that allows us to detect typos.
- Experimenting with the optimal user experience for this error case, e.g. off...This is the parent ticket to hold any tickets under this activity, including:
- Using the address format of onion services v3 that allows us to detect typos.
- Experimenting with the optimal user experience for this error case, e.g. offering a retry-button after explaining what went wrong.
- Implementing a special error page that tells the user the problem is a typo in the address.