The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-05-01T12:53:10Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41085Refactor the UI to remove all bridges2023-05-01T12:53:10ZdonutsRefactor the UI to remove all bridgesIn #40782 we introduced the concept of bridge cards. As part of that work, we provided a means to remove all bridge cards using a red button positioned below the bridge stack:
- [remove-all-bridges](/uploads/3c9cf520633386ed07bc35ee6341...In #40782 we introduced the concept of bridge cards. As part of that work, we provided a means to remove all bridge cards using a red button positioned below the bridge stack:
- [remove-all-bridges](/uploads/3c9cf520633386ed07bc35ee63418704/remove-all-bridges.png)
However it shares the same position as the "Show all bridges" button, which was terrible UX on my part. We should consider improving this.Sponsor 30 - Objective 3.5Dan BallardDan Ballard2023-04-17https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41080Some users are choosing an adjacent country for circumvention settings2023-05-01T12:49:53ZdonutsSome users are choosing an adjacent country for circumvention settingsDuring usability testing of Connection Assist conducted in https://gitlab.torproject.org/tpo/ux/research/-/issues/52 & https://gitlab.torproject.org/tpo/ux/research/-/issues/78, several participants decided to choose a different country ...During usability testing of Connection Assist conducted in https://gitlab.torproject.org/tpo/ux/research/-/issues/52 & https://gitlab.torproject.org/tpo/ux/research/-/issues/78, several participants decided to choose a different country to the one they were located in after reaching this screen:
- [location-check-light](/uploads/59a5f701eb983f4541f97863a8e661cc/location-check-light.png)
Each of these participants opted to choose a country adjacent to theirs instead – for example, a participant located in Brazil selected Bolivia. OnionShare reported the same behavior when testing their implementation of circumvention settings, whereby a participant in Mexico selected the United States instead. This suggests the behavior is not a quirk of Tor Browser's UX, but a deeper issue.
Participants seem to be selecting an adjacent country in the hope that the Internet is not blocked there, and/or are mistaking the location settings selector for a list of VPN-style server locations.
The same behavior wasn't observed on the initial Connection Assist screen due to the presence of the "Automatic" option, which users favored instead of selecting a location manually.Sponsor 30 - Objective 3.5Dan BallardDan Ballardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41038Update "Click to Copy" button label in circuit display2023-04-04T15:29:45ZdonutsUpdate "Click to Copy" button label in circuit displayApparently the circuit display has a button to click to copy the URL, that appears when you hover over it (which is news to me!):
<img src="/uploads/fe519f445175dba65088b0cfa3430ba4/circuit-display-nyt.png" alt="circuit-display-nyt" wid...Apparently the circuit display has a button to click to copy the URL, that appears when you hover over it (which is news to me!):
<img src="/uploads/fe519f445175dba65088b0cfa3430ba4/circuit-display-nyt.png" alt="circuit-display-nyt" width="50%">
I'm guessing this is a legacy feature carried across from torbutton, since it's trivial enough to copy the URL from the address bar itself? In any case, we should avoid "Click..." commands in our microcopy and update the label to something like `Copy Address` instead.Sponsor 30 - Objective 3.5henryhenry2023-04-17https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41714“Show Fewer Bridges” button missing from refactored remove all bridges UI2023-05-01T12:53:10Zdonuts“Show Fewer Bridges” button missing from refactored remove all bridges UIWhen the full list of bridges has been revealed, “Show All Bridges” should now be replaced with a button labeled “Show Fewer Bridges” that collapses the list again.
See the [Figma file](https://www.figma.com/file/RS584DcR4emXrw1F8g3l5x/...When the full list of bridges has been revealed, “Show All Bridges” should now be replaced with a button labeled “Show Fewer Bridges” that collapses the list again.
See the [Figma file](https://www.figma.com/file/RS584DcR4emXrw1F8g3l5x/Tor-Browser-12.5?node-id=1%3A2&t=i8S80oGAMzN828LD-1) for ref. Thanks!Sponsor 30 - Objective 3.7Dan BallardDan Ballard2023-04-17https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41713“Remove All Bridges” button only appears after hitting “Show All Bridges"2023-05-01T12:53:10Zdonuts“Remove All Bridges” button only appears after hitting “Show All Bridges"In https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41085 we updated the “Remove All Bridges” UI so that the button is permanently visible, rather than being revealed after hitting the “Show All Bridges” button.
Howev...In https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41085 we updated the “Remove All Bridges” UI so that the button is permanently visible, rather than being revealed after hitting the “Show All Bridges” button.
However it looks like the button is still hidden until all bridges are revealed. Can we get that updated please?Sponsor 30 - Objective 3.7Dan BallardDan Ballard2023-04-17https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41617Improve the UX of the built-in bridges dialog2023-06-05T13:56:18ZdonutsImprove the UX of the built-in bridges dialogWe've observed that users often find it difficult to differentiate between Tor Browser's various bridge options, tend to choose a built-in bridge option at random (see: https://gitlab.torproject.org/tpo/ux/research/-/issues/100), and hav...We've observed that users often find it difficult to differentiate between Tor Browser's various bridge options, tend to choose a built-in bridge option at random (see: https://gitlab.torproject.org/tpo/ux/research/-/issues/100), and have trouble figuring out how to connect afterwards (see: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41060).
In response, we're proposing:
- [x] Updating the “Bridges” section description on `about:preferences#connection` to include the word “securely”.
- [x] Updating the title and description of the built-in bridges dialog
- [x] Updating the individual descriptions that accompany each of the built-in bridge options
- [ ] Fixing the size and styling of the dialog and its constituent elements to make it more consistent with Firefox
- [x] Replacing the `OK` button with a `Connect` button when not connected
- [ ] Adding a `✔ Connected` flag to indicate with built-in bridge option Tor Browser is currently using
The Figma file is ready for dev handoff here: [Figma link](https://www.figma.com/file/RS584DcR4emXrw1F8g3l5x/Tor-Browser-12.5?node-id=62%3A10116&t=41hhHGHnJTkIHnmo-1)
These fixes will be ran through additional usability testing in March/April as part of ~"Sponsor 30" before they reach stable in 12.5.Sponsor 30 - Objective 3.7Dan BallardDan Ballard2023-04-17https://gitlab.torproject.org/tpo/ux/research/-/issues/107Return to Ecuador to re-test Tor Browser in moderated sessions2023-05-01T12:49:52ZNahReturn to Ecuador to re-test Tor Browser in moderated sessionsThis is a major ticket to user research activities in Ecuador, in which we will test improvements made based on previous usability testings results in the region.
* [x] User Research Plan: https://gitlab.torproject.org/tpo/ux/research/-...This is a major ticket to user research activities in Ecuador, in which we will test improvements made based on previous usability testings results in the region.
* [x] User Research Plan: https://gitlab.torproject.org/tpo/ux/research/-/issues/107#note_2874635
* [x] Pilot Study
* [x] Run (5) usability testing combined with interviews
* [x] Analyze and reportSponsor 30 - Objective 3.6NahNahhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40734Add lost comments about decay playing a role in guaranteed Stable flag assign...2022-12-21T13:37:39ZGeorg KoppenAdd lost comments about decay playing a role in guaranteed Stable flag assignment guaranteed familiarityIn 8bf1a86ae1f3f71fa4b8b13f6d8eef5ad5eff8ca we removed comments related to potential decay rates when e.g. `Stable` guarantees. The problem now is that in that case the spec has a different number ("7") than the code ("5") without explan...In 8bf1a86ae1f3f71fa4b8b13f6d8eef5ad5eff8ca we removed comments related to potential decay rates when e.g. `Stable` guarantees. The problem now is that in that case the spec has a different number ("7") than the code ("5") without explanation whatsoever. Let's get those comments back and then at some point think about how to get the decay concept into our specs as well.Tor: 0.4.8.x-freezeGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40730TROVE-2022-002: The SafeSocks option for SOCKS4(a) is inverted leading to SOC...2023-11-02T18:55:30ZDavid Gouletdgoulet@torproject.orgTROVE-2022-002: The SafeSocks option for SOCKS4(a) is inverted leading to SOCKS4 going throughThis is a report from hackerone: https://hackerone.com/bugs?subject=torproject&report_id=1784589
Below is the content of the report which has detailed information.
We have classified this as `medium` considering that tor was not defend...This is a report from hackerone: https://hackerone.com/bugs?subject=torproject&report_id=1784589
Below is the content of the report which has detailed information.
We have classified this as `medium` considering that tor was not defending in-depth for dangerous SOCKS request and so any user relying on `SafeSocks 1` to make sure they don't link DNS leak and their Tor traffic wasn't safe afterall for `SOCKS4(a)`.
Tor Browser doesn't use `SafeSocks 1` and SOCKS4 so at least the likely vast majority of users are not affected.
# H1 Report
## Summary:
This bug appears to be a typo; [src/core/proto/proto_socks.c, process_socks4_request()](https://gitweb.torproject.org/tor.git/tree/src/core/proto/proto_socks.c?h=tor-0.4.7.11#n236) contains the line:
` if (is_socks4a && !addressmap_have_mapping(req->address, 0)) {`
Which presumably should be `!is_socks4a`. The following logic appears correct only if that change is made; as it exists now, the check is inverted and only warns on and rejects safe SOCKS4a requests.
## Steps To Reproduce:
1. Configure Tor with SafeSocks set to 1 (listening on localhost, with default port 9050)
1. Perform an unsafe SOCKS4 request; e.g., with socat: `echo -en "HEAD / HTTP/1.1\r\nHost: duckduckgo.com\r\n\r\n" | socat -v STDIO SOCKS4:127.0.0.1:duckduckgo.com:80,socksport=9050,shut-none`
Note that the locally-performed DNS request is leaked, and only the server IP is sent to Tor, but Tor does not block the request as it should have. The request reaches the server, and Tor does not log that a DNS leak may have occurred.
1. Perform a safe SOCKS4a request: `echo -en "HEAD / HTTP/1.1\r\nHost: duckduckgo.com\r\n\r\n" | socat -v STDIO SOCKS4a:127.0.0.1:duckduckgo.com:80,socksport=9050,shut-none`
Note that the domain is being sent to Tor, but Tor incorrectly blocks the request, and logs an incorrect "Your application (using socks4 to port 80) is giving Tor only an IP address." error.
The check is inverted; when using SOCKS4/SOCKS4a, SafeSocks 1 does the exact opposite of what it should, ensuring the user is making only unsafe requests. I have not tested SOCKS5, though it presumably works correctly given TorBrowser uses it.
## Additional info:
I tested this on Tor versions 0.4.7.10 and 0.4.5.10; git history suggests this has been broken all the way back to 0.3.5, seems to have been introduced in a rewrite, merge commit 7556933537b5777a9bef21230bb91a08aa70d60e, see https://gitweb.torproject.org/user/nickm/tor.git/commit/src/or/proto_socks.c?h=socks_trunnel4_squashed_merged&id=9155e08450fe7a609f8223202e8aa7dfbca20a6d
The commands above were run using Bash and socat, and this bug had been discovered while using a custom SOCKS4a application.
## Impact
Impact is a DNS leak that occurs under a configuration intended to guard against such a possibility. That configuration is not under attacker control, but users who believe they need this protection may be more likely to turn on the broken config option.
2 scenarios are plausible, that impact user anonymity by leaking DNS traffic with SafeSocks 1:
1. Users configuring SOCKS4 apps that don't support SOCKS4a will be led to believe their traffic is fully secured, when in fact DNS requests are still being leaked.
1. Users configuring apps that do support SOCKS4a could be misled into selecting SOCKS4 instead, as Tor will error out if they try to use the safe configuration; this could conceivably create a DNS leak where one need not exist.
It should also be noted that the incorrect warning does still get printed even with SafeSocks 0, but it does not cause any otherwise-visible problems.
Note that users will only be impacted if they connect using SOCKS4, and rely on SafeSocks to protect against DNS leaks. SafeSocks 1 is recommended in a number of online guides to securing Tor. The application I was working on when I discovered this also relied on it as a defense-in-depth measure. I nevertheless suspect SOCKS4a may be a rare configuration, given this bug seems to have existed for about 4 years without detection.Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40723conflux: Cell parsing and handling2023-01-11T16:53:09ZDavid Gouletdgoulet@torproject.orgconflux: Cell parsing and handlingTicket to implement the prop329 cell parsing and handling (trunnel work in part).Ticket to implement the prop329 cell parsing and handling (trunnel work in part).Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40721conflux: New protocol version to support2023-01-11T16:52:36ZDavid Gouletdgoulet@torproject.orgconflux: New protocol version to supportThis is the ticket for the Conflux (prop329) part of the protocol version advertisement and handling for relays.This is the ticket for the Conflux (prop329) part of the protocol version advertisement and handling for relays.Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40713calculate n_threads as "num-cpus +1" instead "num-cpus -1"2022-11-28T14:34:32Ztoralfcalculate n_threads as "num-cpus +1" instead "num-cpus -1"This
```c
/*
In our threadpool implementation, half the threads are permissive and
half are strict (when it comes to running lower-priority tasks). So we
always make sure we have at least two threads, so that there...This
```c
/*
In our threadpool implementation, half the threads are permissive and
half are strict (when it comes to running lower-priority tasks). So we
always make sure we have at least two threads, so that there will be at
least one thread of each kind.
*/
const int n_threads = get_num_cpus(get_options()) + 1;
```
could be for multi-cpu systems
```c
const int n_threads = get_num_cpus(get_options()) - 1;
```
nowadays ?Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40709Update default congestion control params2023-06-27T21:21:15ZMike PerryUpdate default congestion control paramsTo aid in unit test vectors, we should update the default congestion control params in the source to match our consensus. That way the test vectors can be based on our current live param set.
I am currently running sims to decide params...To aid in unit test vectors, we should update the default congestion control params in the source to match our consensus. That way the test vectors can be based on our current live param set.
I am currently running sims to decide params for https://gitlab.torproject.org/tpo/core/tor/-/issues/40680, and I have some new candidate CC params as a result of those. I should finish this tuning in another day or so.
Cc: @dgouletTor: 0.4.8.x-freezeMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40678Crash on Windows after DNSPort request2024-01-08T13:31:05ZcypherpunksCrash on Windows after DNSPort requestTor 4.7.7, on Windows, crashes after receiving the following request on DNSPort.
`000201000001000000000000076578616d706c6503636f6d0000010001`
Full pcap:
<pre>
1MOyoQIABAAAAAAAAAAAAAAABAAAAAAAIq6cYnvfCQAiAAAAIgAAAAIAAABFAAAe
hk0AAIARAAB/...Tor 4.7.7, on Windows, crashes after receiving the following request on DNSPort.
`000201000001000000000000076578616d706c6503636f6d0000010001`
Full pcap:
<pre>
1MOyoQIABAAAAAAAAAAAAAAABAAAAAAAIq6cYnvfCQAiAAAAIgAAAAIAAABFAAAe
hk0AAIARAAB/AAABfwAAAfLIADYACg68AB0irpxiFeAJAD0AAAA9AAAAAgAAAEUA
ADmGTgAAgBEAAH8AAAF/AAAB8sgANgAlPzMAAgEAAAEAAAAAAAAHZXhhbXBsZQNj
b20AAAEAAQ==
</pre>Tor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40664Reject relays running Tor 0.4.6.x2023-12-03T18:23:06ZGeorg KoppenReject relays running Tor 0.4.6.xSimilar to previous tickets (e.g. #40480 and #40559) we should reject EOL versions at the directory authority level. This time the 0.4.6 series is concerned.
We started the whole process this week and are about to contact all relay oper...Similar to previous tickets (e.g. #40480 and #40559) we should reject EOL versions at the directory authority level. This time the 0.4.6 series is concerned.
We started the whole process this week and are about to contact all relay operators with a valid contact information. Additionally, we sent an announcement to [tor-relays@](https://lists.torproject.org/pipermail/tor-relays/2022-August/020765.html).Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40643Parameterize Fast+Guard cutoffs2022-10-28T19:15:21ZMike PerryParameterize Fast+Guard cutoffsWith https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/17, https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/41, and https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/18, we can determine new ...With https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/17, https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/41, and https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/18, we can determine new threshholds for Fast+Guard relays, and see if this improves performance and reduces queue overload.
Basically, we want to make consensus parameters for the fast+guard percentile cutoffs, and determine new values for them.
This should be done in tandem with https://gitlab.torproject.org/tpo/core/tor/-/issues/40642, and https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/16.Tor: 0.4.8.x-freezeMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40638metricsport query returns duplicated / redundant ntor and ntor_v3 values2023-11-25T08:14:41Zqprimedmetricsport query returns duplicated / redundant ntor and ntor_v3 values### Summary
### Steps to reproduce:
1. Query relay node metrics
### What is the current bug behavior?
```
tor_relay_load_onionskins_total{type="tap",action="processed"} 124
tor_relay_load_onionskins_total{type="tap",action="dropped"...### Summary
### Steps to reproduce:
1. Query relay node metrics
### What is the current bug behavior?
```
tor_relay_load_onionskins_total{type="tap",action="processed"} 124
tor_relay_load_onionskins_total{type="tap",action="dropped"} 0
tor_relay_load_onionskins_total{type="fast",action="processed"} 0
tor_relay_load_onionskins_total{type="fast",action="dropped"} 0
tor_relay_load_onionskins_total{type="ntor",action="processed"} 193734
tor_relay_load_onionskins_total{type="ntor",action="dropped"} 0
tor_relay_load_onionskins_total{type="ntor_v3",action="processed"} 193734
tor_relay_load_onionskins_total{type="ntor_v3",action="dropped"} 0
```
values for ntor and ntor_v3 appear to be duplicates of each other. summed aggregate value of tor_relay_load_onionskins_total will be incorrect unless either ntor or ntor_v3 are manually filtered out.
### Environment
- Tor 0.4.7.8
- Debian 11
- Package install from torproject.org debian reposTor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40634prop327: Implement PoW over Introduction Circuits2024-03-28T18:02:50ZDavid Gouletdgoulet@torproject.orgprop327: Implement PoW over Introduction CircuitsThis is the implementation ticket for prop327This is the implementation ticket for prop327Tor: 0.4.8.x-freezeMicah Elizabeth ScottMicah Elizabeth Scotthttps://gitlab.torproject.org/tpo/core/tor/-/issues/40631Confidential: From cypherpunks: DNSPort crash on Windows2023-05-25T13:16:36ZNick MathewsonConfidential: From cypherpunks: DNSPort crash on WindowsWe've received this apport on anonticket. Out of caution, I'm sticking it in a confidential ticket manually, since it *might* be some kind of memory safety issue.
> Tor 4.7.7, on Windows, crashes after receiving the following request o...We've received this apport on anonticket. Out of caution, I'm sticking it in a confidential ticket manually, since it *might* be some kind of memory safety issue.
> Tor 4.7.7, on Windows, crashes after receiving the following request on DNSPort. `000201000001000000000000076578616d706c6503636f6d0000010001` Full pcap:
>
> <pre> 1MOyoQIABAAAAAAAAAAAAAAABAAAAAAAIq6cYnvfCQAiAAAAIgAAAAIAAABFAAAe hk0AAIARAAB/AAABfwAAAfLIADYACg68AB0irpxiFeAJAD0AAAA9AAAAAgAAAEUA ADmGTgAAgBEAAH8AAAF/AAAB8sgANgAlPzMAAgEAAAEAAAAAAAAHZXhhbXBsZQNj b20AAAEAAQ==</pre>
Let's see what's up here.
cc @dgoulet @ahfTor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40569Consider reducing the range of sendme_inc negotiation2023-06-27T21:21:23ZMike PerryConsider reducing the range of sendme_inc negotiationIn congestion control, because endpoints *must* agree on sendme_inc, and because the consensus may not be in sync between endpoints, we have the exit or onion service control the sendme_inc, which the client validates by ensuring it is w...In congestion control, because endpoints *must* agree on sendme_inc, and because the consensus may not be in sync between endpoints, we have the exit or onion service control the sendme_inc, which the client validates by ensuring it is within a factor of 2X of the consensus value it sees.
It may be the case that a traffic analysis side channel could be built from this 2X range that allows Exits or onion services to segment clients into buckets using this 2X range, and then Guard relays could detect this rate of sendme by guessing it due to the rate of packets in the return direction during a download. It is debatable how serious this side channel is, because without padding and drop cell protection, there are *many many* more traffic analysis side channels in Tor are far more severe.
The good news is that it trivial to reduce this range of validation at any point, in a future release. We simply change `congestion_control_validate_sendme_increment()` to only allow +/- 1 instead of 2X. This does not impact negotiation ability, because all it changes is the dirauth policy with respect to updating sendme_inc to only change it by +/-1 every 3-4 hours.
From extensive Shadow simulation, we have fairly high confidence that sendme_inc needs to be 31-32 cells. The only reason to keep this range at 2X is in case Shadow is mis-calibrated from live in some way, and we may discover that due to this, we need a larger range over which to change sendme_inc. Otherwise the validation could be +/- 1 or 2, instead of 2X.
Still, given that there are worse side channels currently in Tor, at least for now, we should retain the flexibility to alter sendme_inc by wider margins, until we have more confidence in Shadow simulation (by observing that live behaves as Shadow has predicted it will).Tor: 0.4.8.x-freezeMike PerryMike Perry