Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:46:25Zhttps://gitlab.torproject.org/legacy/trac/-/issues/30381Provide control port commands to ADD/REMOVE/VIEW v3 client-auth2020-06-13T15:46:25ZGeorge KadianakisProvide control port commands to ADD/REMOVE/VIEW v3 client-authWe need control port commands so that TB can add/remove/view client auth credentials.
Furthermore, the 'add' command should be able to decrypt any existing non-decryptable descriptors in the cache (see #30382).We need control port commands so that TB can add/remove/view client auth credentials.
Furthermore, the 'add' command should be able to decrypt any existing non-decryptable descriptors in the cache (see #30382).Tor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/30281Sponsor27 master ticket2020-06-13T15:40:57ZGeorge KadianakisSponsor27 master ticketThis is the master ticket for the whole Sponsor27 project.This is the master ticket for the whole Sponsor27 project.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30237Tor Browser: Improve TBB UI of hidden service client authorization2020-06-16T01:13:13ZGeorge KadianakisTor Browser: Improve TBB UI of hidden service client authorizationThis is the parent ticket for Sponsor27 Objective1 Activity1 about improving the UI of client authorization.
This used to be #14389, but it contained too many network-team-specific information so I repurposed #14389 to be about the net...This is the parent ticket for Sponsor27 Objective1 Activity1 about improving the UI of client authorization.
This used to be #14389, but it contained too many network-team-specific information so I repurposed #14389 to be about the network-team side of things, and please use this ticket for the Tor Browser side of things.
Resources about setting up client auth:
https://2019.www.torproject.org/docs/tor-onion-service.html.en#CookieAuthentication
https://lists.torproject.org/pipermail/tor-project/2019-January/002180.html
and https://github.com/torproject/tor/blob/7741b21d0e3afbfc6d60a852fce6992724c4ae71/doc/tor.1.txt#L3021
and https://github.com/torproject/tor/blob/7741b21d0e3afbfc6d60a852fce6992724c4ae71/doc/tor.1.txt#L1122Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/30200Potential circuit timeout issues on onion service circuits2020-06-13T15:44:29ZGeorge KadianakisPotential circuit timeout issues on onion service circuitsThis is a master ticket to track various kinds of timeout issues we have with onion service circuits causing reachability issues.This is a master ticket to track various kinds of timeout issues we have with onion service circuits causing reachability issues.Tor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/30090Make a list of potential .onion errors2020-06-16T01:10:51ZPili GuerraMake a list of potential .onion errorsLet's make a list of all potential errors that can happen when visiting .onion services to help us design the corresponding error pagesLet's make a list of all potential errors that can happen when visiting .onion services to help us design the corresponding error pagesAntonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/30029Objective 2, Activity 5: POC for Human-memorable addresses for .onion services2020-06-16T01:02:13ZPili GuerraObjective 2, Activity 5: POC for Human-memorable addresses for .onion servicesThis is the parent ticket to hold any tickets under this activity, including:
- Evaluating using HTTPS-Everywhere.
- Evaluating using HTTPS-Everywhere’s Update Channels feature to add custom onion rulesets that can be updated automatica...This is the parent ticket to hold any tickets under this activity, including:
- Evaluating using HTTPS-Everywhere.
- Evaluating using HTTPS-Everywhere’s Update Channels feature to add custom onion rulesets that can be updated automatically.
- Evaluating adding a designated file extension handler in Tor Browser to handle HTTPS-Everywhere rulesets.
- Evaluating enhancing the UI of HTTPS-Everywhere so that it educates users on how onion update channels work.https://gitlab.torproject.org/legacy/trac/-/issues/30025Objective 2, Activity 4: Better client-side errors2020-06-16T01:02:12ZPili GuerraObjective 2, Activity 4: Better client-side errorsThis is the parent ticket to hold any tickets under this activity, including:
- Improving Tor Browser behavior when an onion site supports HTTPS but the HTTPS is not from an approved certificate.
- Fixing inconsistent messages we are sho...This is the parent ticket to hold any tickets under this activity, including:
- Improving Tor Browser behavior when an onion site supports HTTPS but the HTTPS is not from an approved certificate.
- Fixing inconsistent messages we are showing to users accessing .onion sites with self-signed certificates-
- Improving Tor Browser’s user experience and error messages when a .onion link fails.
- Providing more informative error messages back to the user to better indicate whether the issue was on the service-side, on the client-side, or on the network-side.https://gitlab.torproject.org/legacy/trac/-/issues/30024Objective 2, Activity 3: Notify users if a current website they are visiting ...2020-06-16T01:02:11ZPili GuerraObjective 2, Activity 3: Notify users if a current website they are visiting on Tor Browser has an onion service versionThis is the parent ticket to hold any tickets under this activity, including:
- Investigate the ideal browser user experience for when such a redirection takes place, to minimize user confusion.
- Build the code necessary to optimally s...This is the parent ticket to hold any tickets under this activity, including:
- Investigate the ideal browser user experience for when such a redirection takes place, to minimize user confusion.
- Build the code necessary to optimally support this experience on Tor Browser such as prioritizing .onion addresses when Alt-Svc is used.
- Correctly display the .onion Alt-Svc circuit path on the circuit display.
- Educate the user on how the redirection takes place, so that users get more familiar with the concept of onion services. We will employ appropriate “stop-and-learn” techniques to inform our users of the benefits of onion services and how they should be used.
- Continue work on our Onion-Location proposal which gives the user the option to choose whether or not onion redirect should take place.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.https://gitlab.torproject.org/legacy/trac/-/issues/30019Write content for the onion services section in the community portal2020-06-13T17:27:54ZGeorge KadianakisWrite content for the onion services section in the community portalHere is a ticket to trac this item.Here is a ticket to trac this item.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/30000Objective 2, Activity 1: Integrating client-side authorization to onion servi...2020-06-16T01:02:07ZPili GuerraObjective 2, Activity 1: Integrating client-side authorization to onion services v3This is the parent ticket to hold any tickets under this activity, including:
- Rebuilding the client experience on the Tor Browser.
- Improving the end to end experience for onion service operators and their users.This is the parent ticket to hold any tickets under this activity, including:
- Rebuilding the client experience on the Tor Browser.
- Improving the end to end experience for onion service operators and their users.https://gitlab.torproject.org/legacy/trac/-/issues/29999Objective 1, Activity 2: Denial of service defences2020-06-13T15:40:11ZPili GuerraObjective 1, Activity 2: Denial of service defencesThis is the parent ticket to hold any tickets under this activity, including:
- Reducing the amount of circuits that they build over time on the Tor network
- Providing more ways for onion service administrators to control the influx of ...This is the parent ticket to hold any tickets under this activity, including:
- Reducing the amount of circuits that they build over time on the Tor network
- Providing more ways for onion service administrators to control the influx of incoming users in heavy traffic scenarios.
- Improving our defense mechanisms by:
- Decreasing onion service load on the Tor network, by slowing down Tor circuit creation on startup.
- Optimizing relevant onion service functions that are called multiple times therefore taking a lot of the CPU.
- Making it harder for adversaries to force services to rotate their introduction points.
- Writing a Tor software change proposal for a “rendezvous approver” API that can be useful for:
1. Rate limiting; allow at most N unauthenticated clients over a set time period
2. Extra-conservative logic like "stop accepting connections during potential guard discovery"
3. Limiting capacity to control server load; only allow N simultaneous clients.
4. Protocol-tuned rules for things like Ricochet
5. More advanced pre-rendezvous authorization
6. Load-balancing across multiple servers running Tor onion services
- Closing client circuit once the INTRO1/ACK dance has been completed, decreasing load on the Tor network.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29998Objective 1, Activity 1.2: Adopt OnionBalance features into onion services v32020-06-13T15:40:10ZPili GuerraObjective 1, Activity 1.2: Adopt OnionBalance features into onion services v3This is the parent ticket to hold any tickets under this activity, including:
- Improving scalability of onion services by adopting OnionBalance features into onion services v3This is the parent ticket to hold any tickets under this activity, including:
- Improving scalability of onion services by adopting OnionBalance features into onion services v3Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29995Objective 1, Activity 1.1: Make v3 the default on Core Tor stable2020-06-13T15:47:38ZPili GuerraObjective 1, Activity 1.1: Make v3 the default on Core Tor stableThis is the parent ticket to hold any tickets under this activity, including:
- Making onion services v3 the default option on Core Tor
- Implementing a set of fixes to issues we have documented at our issue tracker, in order to:
- R...This is the parent ticket to hold any tickets under this activity, including:
- Making onion services v3 the default option on Core Tor
- Implementing a set of fixes to issues we have documented at our issue tracker, in order to:
- Reduce onion service exposure to malicious relays
- Create faster and more reliable client connections
- Create more reliable client connections for bridge usersTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29669hs: ADD_ONION with NEW:BEST is still pinned on v22020-06-13T15:39:01ZDavid Gouletdgoulet@torproject.orghs: ADD_ONION with NEW:BEST is still pinned on v2Even though the control spec says:
```
(The "NEW:BEST" option obeys the HiddenServiceVersion torrc option default
value. Since 0.3.5.1-alpha, it is 3. For Tor versions before 0.3.5.1-alpha,
default HiddenServiceVersion is 2.)
```
...Even though the control spec says:
```
(The "NEW:BEST" option obeys the HiddenServiceVersion torrc option default
value. Since 0.3.5.1-alpha, it is 3. For Tor versions before 0.3.5.1-alpha,
default HiddenServiceVersion is 2.)
```
... in control.c, the `ADD_ONION` command has this condition that basically pins the `NEW:BEST` to v2:
```
if (!strcasecmp(key_type_rsa1024, key_blob) ||
!strcasecmp(key_type_best, key_blob)) {
/* "RSA1024", RSA 1024 bit, also currently "BEST" by default. */
```
Not good! `NEW:BEST` should obey the default version, not something hardcoded like so. This will need a spec update to mention the correct tor version.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/296072019 Q1: Denial of service on v2 and v3 onion service2022-03-22T13:12:44ZTrac2019 Q1: Denial of service on v2 and v3 onion serviceDear tor team,
We have setup a discussion board, on the tor network.
And there is someone that is exploiting within our servers, by taking it down it every time and the forums will respond with "Server not found".
We are pretty sure this...Dear tor team,
We have setup a discussion board, on the tor network.
And there is someone that is exploiting within our servers, by taking it down it every time and the forums will respond with "Server not found".
We are pretty sure this problem is on the side of the TOR browser, is there anything we could do to sort this?
With many thanks for taking time into reading this.
**Trac**:
**Username**: pidginTor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29338restore HiddenServiceAuthorizeClient in v32020-06-13T15:37:55ZTracrestore HiddenServiceAuthorizeClient in v3According to the manual, for v3 hidden services, if the contents of <HiddenServiceDir>/authorized_clients/ cannot be loaded, then the Hidden Service is enabled and is accessible to anyone with the onion address. This is a security hole....According to the manual, for v3 hidden services, if the contents of <HiddenServiceDir>/authorized_clients/ cannot be loaded, then the Hidden Service is enabled and is accessible to anyone with the onion address. This is a security hole. It opens the possibility that the user intended for the service to require authorization, but due to files being moved or deleted or inaccessible or other file system problem, the hidden service incorrectly becomes accessible to anyone.
Please restore the configuration option HiddenServiceAuthorizeClient for v3 services. If it is set to "basic", then authentication should be required for the service regardless of whether <HiddenServiceDir>/authorized_clients/ can be read, or alternately, if the authorized users cannot be read, tor should not start up or should not enable the hidden service.
**Trac**:
**Username**: AlanTor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29237Restore IPv6 intro points in the HS client tests2020-06-13T15:37:37ZteorRestore IPv6 intro points in the HS client testsIn #23576, I removed an IPv6-only intro point from the HS client tests. We should put it back in.In #23576, I removed an IPv6-only intro point from the HS client tests. We should put it back in.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29034circuit: Cleanup an HS circuit when it is being re-purposed2020-06-13T15:42:10ZDavid Gouletdgoulet@torproject.orgcircuit: Cleanup an HS circuit when it is being re-purposedMike found out that when an IP/RP circuit fails to build in the right amount of time (for instance through `circuit_expire_building()`), it is re-purposed to become a measurement circuit.
The issue is that those HS circuits are set in t...Mike found out that when an IP/RP circuit fails to build in the right amount of time (for instance through `circuit_expire_building()`), it is re-purposed to become a measurement circuit.
The issue is that those HS circuits are set in the HS circuitmap and have an `hs_ident` or `rend_data` set to them that should really not linger in the circuit object if the circuit is not an HS one anymore.
Offenders: `circuit_build_times_mark_circ_as_measurement_only()` and `pathbias_send_usable_probe()`.
Solution:
`circuit_change_purpose()` is probably the right place to make a callback within the HS subsystem specific to cleaning up a circuit for a purpose change. I think we need a new function that specifically does that and not use `hs_circ_cleanup()` since it won't remove the ident.
Lingering circuits in the HS circuitmap is bad and this bug could probably explain some of the issues we had with clients unable to establish connections because the IP auth key wouldn't match the one in the circuit ident.
I strongly believe this should be backported up to 0.3.5 at the very least.Tor: 0.3.5.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/28970tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_ke...2020-06-13T15:42:46ZTractor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-fatal assertionIf this is duplicate I'm sorry, but I found nothing similar in old tickets. `Sandbox` is 1 in `torrc`. Set priority and severity of this ticket to appropriate values if it is not so critical.
```
Jan 01 05:31:32.000 [notice] Received rel...If this is duplicate I'm sorry, but I found nothing similar in old tickets. `Sandbox` is 1 in `torrc`. Set priority and severity of this ticket to appropriate values if it is not so critical.
```
Jan 01 05:31:32.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jan 01 05:31:32.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jan 01 05:31:32.000 [notice] Read configuration file "/etc/tor/torrc".
Jan 01 05:31:32.000 [notice] Tor 0.3.4.9 (git-074ca2e0054fded1) opening log file.
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: Non-fatal assertion !(desc == NULL) failed in setup_intro_circ_auth_key at ../src/or/hs_client.c:624. Stack trace: (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x42) [0x56345cea26e2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb7) [0x56345cebd587] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_circuit_has_opened+0x2ca) [0x56345ce8027a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_send_next_onion_skin+0x372) [0x56345cdfd192] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x78fc3) [0x56345cd92fc3] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x311) [0x56345cd95211] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(command_process_cell+0x280) [0x56345ce126f0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x273) [0x56345cdf4493] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x11de1c) [0x56345ce37e1c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0x892) [0x56345ce2e822] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x53a61) [0x56345cd6da61] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f2c7be623dc] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x25f) [0x56345cd6fe3f] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1165) [0x56345cd72315] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x56345cd6a32a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x56345cd6a099] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f2c7a7e6b45] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x500e9) [0x56345cd6a0e9] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:443: intro_circ_is_ok: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in intro_circ_is_ok at ../src/or/hs_client.c:443. Stack trace: (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x42) [0x56345cea26e2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb7) [0x56345cebd587] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_send_introduce1+0x352) [0x56345ce7fda2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_ap_handshake_attach_circuit+0x33c) [0x56345ce1126c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_ap_attach_pending+0x1a0) [0x56345ce31cb0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_receive_rendezvous_acked+0x79) [0x56345ce803c9] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(rend_process_relay_cell+0x28b) [0x56345cd9c2cb] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x791f7) [0x56345cd931f7] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x311) [0x56345cd95211] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(command_process_cell+0x280) [0x56345ce126f0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x273) [0x56345cdf4493] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x11de1c) [0x56345ce37e1c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0x892) [0x56345ce2e822] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x53a61) [0x56345cd6da61] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f2c7be623dc] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x25f) [0x56345cd6fe3f] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1165) [0x56345cd72315] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x56345cd6a32a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x56345cd6a099] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f2c7a7e6b45] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x500e9) [0x56345cd6a0e9] (on Tor 0.3.4.9 )
```
Tor on Linux. Is it related to #27471 or #19926?
**Trac**:
**Username**: torcrashTor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org